LINUX.ORG.RU

И ещё раз про «recvfrom(10, „REJECTED EXTERNAL“

 , ,


0

2

Во избежание некропостинга создаю новую тему. Как подсказывают Гугл и поиск по ЛОРу, многие уже наступали на сабжевые грабли, которых не существует при запуске через dbus-launch. Однако, проявление их разное и лечится оно по-разному.

Как это вообще так происходит?

Многие жалуются на то, что наступая на эти грабли, GTK софт ждёт по 25-30 секунд перед запуском. А у меня, например, на эти грабли наступила Qt софтина. Spectacle. В её отношении это вылечилось удалением директории ~/.config/qt5ct/ и созданием новых настроек. Вот какое отношение имеют эти настройки к dbus'у?

GTK3 софт у меня сейчас на эти грабли не наступает, а GTK2 софт наступает. Пока что не понял что тут можно сделать.

И, да, хорошо знакомый многим выхлоп strace:

connect(10, {sa_family=AF_UNIX, sun_path="/run/user/1000/bus"}, 110) = 0
getpid()                                = 32123
geteuid()                               = 1000
getegid()                               = 100
getpid()                                = 32123
geteuid()                               = 1000
getegid()                               = 100
sendmsg(10, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\0", iov_len=1}], msg_iovlen=1, msg_control=[{cmsg_len=28, cmsg_level=SOL_SOCKET, cmsg_type=SCM_CREDENTIALS, cmsg_data={pid=32123, uid=1000, gid=100}}], msg_controllen=32, msg_flags=0}, MSG_NOSIGNAL) = 1
sendto(10, "AUTH\r\n", 6, MSG_NOSIGNAL, NULL, 0) = 6
recvfrom(10, "REJECTED EXTERNAL\r\n", 4096, 0, NULL, NULL) = 19
sendto(10, "AUTH EXTERNAL 31303030\r\n", 24, MSG_NOSIGNAL, NULL, 0) = 24
recvfrom(10, "OK 1c6d7eb14b4c0ee96ec9a14e5f801"..., 4096, 0, NULL, NULL) = 37
sendto(10, "NEGOTIATE_UNIX_FD\r\n", 19, MSG_NOSIGNAL, NULL, 0) = 19
recvfrom(10, "AGREE_UNIX_FD\r\n", 4096, 0, NULL, NULL) = 15
sendto(10, "BEGIN\r\n", 7, MSG_NOSIGNAL, NULL, 0) = 7
write(13, "\1\0\0\0\0\0\0\0", 8)        = 8
eventfd2(0, EFD_CLOEXEC|EFD_NONBLOCK)   = 12
write(12, "\1\0\0\0\0\0\0\0", 8)        = 8
write(13, "\1\0\0\0\0\0\0\0", 8)        = 8
poll([{fd=12, events=POLLIN}], 1, 25000) = 1 ([{fd=12, revents=POLLIN}])
read(12, "\1\0\0\0\0\0\0\0", 16)        = 8
poll([{fd=12, events=POLLIN}], 1, 25000

★★★★★

Ответ на: комментарий от anonymous

Останавливается, но из-за граблей, а не потому, что так задумано.

Если не допускать появления граблей (поломок системы), то и остановок никаких не будет.

В моём случае мне, вот, не надо было устанавливать IBUS.

saahriktu ★★★★★ ()
Последнее исправление: saahriktu (всего исправлений: 2)
Ответ на: комментарий от saahriktu

из-за граблей, а не потому, что так задумано

откуда ты знаешь, что это не намеренное вредительство? если бы хотели сделать нормально, то делали бы всё что возможно асинхронно или в другом потоке. ну или вообще не прикручивали всякое дерьмо куда не нужно

anonymous ()
Ответ на: комментарий от anonymous

Иногда так не положено делать.

Например, если перед запуском софтины она должна что-то инициализировать, то не получится так, чтобы открыть её окно, а те действия, которые должны были быть выполнены перед открытием её окна, ещё не завершены.

Другая иллюстрация: в ряде игр, например, отображается заставка пока идёт загрузка или идёт заполнение тех массивов данных, которые нужны для игры. И здесь не получится так, чтобы сразу войти в игру, а загрузка или процесс инициализации ещё не завершёны.

Так что, всему своё время.

Главное, что без поломок системы на современных машинах софт стартует мгновенно.

saahriktu ★★★★★ ()
Ответ на: комментарий от saahriktu

перед запуском софтины она должна что-то инициализировать

кто сказал что должна и именно перед? вон ты там вообще удалил, значит не должна. а перед не обязательно, это просто говнокод

в ряде игр

кури стриминг ассетов, остальное это опять говнокод

anonymous ()
Ответ на: комментарий от anonymous

Я удалил стороннюю шину данных, которая вставляла палки в колёса первой. А софт на GTK юзает именно первую шину данных, а та вторая ему не нужна.

Тулкит реализован таким образом, что ему жизненно важно уведомить по шине данных о запуске софтины до её запуска. Чтобы DE, если ему нужно, успело подготовиться и принять соответствующие меры. А когда уведомить по шине данных не удаётся тулкит и начинает пытаться повторить эту операцию, но с задержкой во времени. Мало ли ему отказали в передаче сообщения потому, что шина данных слишком занята.

saahriktu ★★★★★ ()
Ответ на: комментарий от saahriktu

Тулкит реализован таким образом, что ему жизненно важно уведомить … DE

чё-то не сходится, тк тулкиты прекрасно работают вообще безо всяких de установленных на компе

шина данных слишком занята

локальная? офигительные истории. это просто говнокод

anonymous ()
Ответ на: комментарий от anonymous

тулкиты прекрасно работают вообще безо всяких de

Но это не значит, что они не могут работать в DE. И чаще всего у юзера именно DE. И это функционал именно на этот наиболее распространённый случай.

локальная? офигительные истории

Вы просто не учитываете того, что может передаваться через DBUS. У юзера, может быть, например, включены уведомления в Телеграме. И все уведомления о всех новых сообщениях со всех чатов и от всех собеседников будут передаваться через DBUS. А если у юзера при этом ещё и другой софт, который юзает DBUS, открыт?

saahriktu ★★★★★ ()
Последнее исправление: saahriktu (всего исправлений: 3)
Ответ на: комментарий от saahriktu

Но это не значит, что они не могут

зато это значит, что это не «жизненно важно»

не учитываете того, что может передаваться … уведомления в Телеграме

лол что? сколько гигабайт в секунду это, чтобы хоть сколько-то нагрузить современный комп?

anonymous ()
Ответ на: комментарий от anonymous

Тулкиты делают для работы в DE, и потому для тулкитов жиненно важно то, что нужно для работы в DE. То, что они могут работать и в просто WM'ах, это просто дополнительная возможность.

сколько гигабайт в секунду это, чтобы хоть сколько-то нагрузить современный комп?

А кто говорит про нагрузку на комп? Мы говорим про шину данных, которая в системе представлена сокетом. А сколько сокет может обработать подключений одновременно? Вот то-то и оно. Значит, при активности софта, который его использует, используемый сокет вполне может быть занят. Даже если нагрузки на комп это не создаёт. Нагрузка сокета и нагрузка компа - это разные вещи.

saahriktu ★★★★★ ()
Ответ на: комментарий от saahriktu

тулкиты нужны для упрощения написания графически программ. всё остальное это вредительство

для работы в de программам не нужно висеть, это софистика с твоей стороны

А сколько сокет может обработать подключений одновременно

это неважно, если не хватает реализуйте шину через другие механизмы, ресурсов достаточно. очередная тухлая софистика с твоей стороны

anonymous ()
Ответ на: комментарий от anonymous

Тем не менее, тулкиты разрабатывают так, чтобы они полноценно взаимодействовали с DE.

реализуйте шину через другие механизмы

Это всё теории. На практике же наиболее используемой шиной данных является именно DBUS.

Можно долго рассуждать об архитектуре софта, но это всё теории, оторванные от практики.

А на практике есть уже имеющиеся конкретные реализации со своими особенностями. И их можно критиковать, а можно и не критиковать. Ибо в целом всё и так работает. Если раскачивать лодку, то работает медленно. А если её не раскачивать, то работает быстро.

saahriktu ★★★★★ ()
Последнее исправление: saahriktu (всего исправлений: 3)
Ответ на: комментарий от saahriktu

тем не менее, висеть программам никакого резона нет

На практике же наиболее используемой шиной данных является именно DBUS

офигительные истории. эта поделка кроме de требухи считай нигде не используется

Можно долго рассуждать …

читаю это как то, что ты сдаёшься защищать говнокод

anonymous ()
Ответ на: комментарий от anonymous

Если не ломать систему, то ничего и не висит.

эта поделка кроме de требухи считай нигде не используется

RLY? Те же уведомления юзеру юзерский софт отправляет именно через DBUS. Не говоря уже о взаимодействии софтин между собой. Поэтому DBUS нужно запускать даже при сидении в WM'е без DE.

saahriktu ★★★★★ ()
Ответ на: комментарий от saahriktu

Если не ломать систему

это не система, а de требуха, без которой софт прекрасно может работать, те она опциональна

уведомления

это de требуха

взаимодействии софтин между собой

прекрасно взаимодействуют безо всяких dbus

DBUS нужно запускать

не запускаю, всё нужное работает

anonymous ()
Ответ на: комментарий от anonymous

Как ни крутите, GTK разрабатывают как часть GNOME, а Qt разрабатывают как часть KDE. И софт на них тоже пишут зачастую как части GNOME и KDE соответственно.

И софт на GTK часто требует сервисы GNOME, а софт на Qt часто требует сервисы KDE.

Поэтому и в других DE есть опции совместимости с галочками «запускать сервисы GNOME» и «запускать сервисы KDE».

Нейтральными по отношению к DE являются такие тулкиты как Motif, Tk, FLTK,... и т.д.

saahriktu ★★★★★ ()