35844 2019-01-03 15:30:14 +0300 Не запускается на i586 2019-01-20 15:36:43 +0300 1 1 4 Development Sisyphus lightdm unstable x86 Linux CLOSED FIXED P3 critical --- 33000 1 antohami manowar golubevan grenka iv manowar mike vladimir.didenko qa-sisyphus oldest_to_newest 177142 0 antohami 2019-01-03 15:30:14 +0300 Проблема воспроизводится на регулярках i586: cinnamon, enlightenment, lxde, mate, xfce. http://nightly.altlinux.org/sisyphus/snapshots/20190102/ При этом автологин отрабатывает нормально. Чтобы воспроизвести проблему можно даже не устанавливать систему. Достаточно отключить автологин в центре управления и завершить сеанс. Экран три раза моргнёт и всё. systemctl status lightdm показывает failed. 177152 1 vladimir.didenko 2019-01-04 08:56:02 +0300 Я посмотрю, но только после праздников. Как быстрый фикс, можно на i586 использовать gtk greeter - я, так понимаю, он работает? 177153 2 antohami 2019-01-04 10:18:30 +0300 Поторопился с выводами. Проблема у lightdm, так как lightdm-gtk-greeter тоже не работает. Проблема запуска службы lightdm.service, ориентировочно, так как от root: lightdm работает. В логе /var/log/lightdm/lightdm.log есть строчка после которой служба начинает завершаться: Critical: session_get_login1_session_id:assertion 'session !=NULL' failed На sysv служба стартует нормально. Может связано с обновлением systemd? 177162 3 antohami 2019-01-05 19:15:23 +0300 А слона я не приметил, сообщение в журнале: kernel: traps: lightdm-gtk-gre[1749] trap int3 ip:b717e834 sp;bfba6af90 error:0 in libglib-2.0.so.0.5800.2[b7145000+80000] Пробую сделать ребилд lightdm. 177163 4 antohami 2019-01-05 20:23:44 +0300 (В ответ на комментарий №3) > А слона я не приметил, сообщение в журнале: > kernel: traps: lightdm-gtk-gre[1749] trap int3 ip:b717e834 sp;bfba6af90 error:0 > in libglib-2.0.so.0.5800.2[b7145000+80000] > > Пробую сделать ребилд lightdm. Установил пересобранный lightdm. Не помогло. Но похоже дело в другом. Продолжаю примечать слонов. Лог /var/log/lightdm/x-0-greeter.log заканчивается строкой: ERROR: gmem.c:135 failed to allocate 256 bytes lightdm 177164 5 antohami 2019-01-05 20:35:00 +0300 (В ответ на комментарий №4) > (В ответ на комментарий №3) > > А слона я не приметил, сообщение в журнале: > > kernel: traps: lightdm-gtk-gre[1749] trap int3 ip:b717e834 sp;bfba6af90 error:0 > > in libglib-2.0.so.0.5800.2[b7145000+80000] > > > > Пробую сделать ребилд lightdm. > > Установил пересобранный lightdm. Не помогло. Но похоже дело в другом. Продолжаю > примечать слонов. > Лог /var/log/lightdm/x-0-greeter.log заканчивается строкой: > > ERROR: gmem.c:135 failed to allocate 256 bytes lightdm Это, когда используется slick-greeter. Когда используется lightdm-gtk-greeter, в том же логе: OpenGL Error: Out of memory trying to allocate 640 bytes! 177167 6 grenka 2019-01-06 04:48:27 +0300 (In reply to comment #5) Я использую 586ую машинку, вчера как раз захотел переехать со слима на лайтдм и был ужасно расстроен, когда комп превратился в тыкву. Спасибо за багу, если бы не она, совсем бы не знал, что делать. Пока использую гдм, но для моего железа он тяжеловат. Жду с нетерпением починки lightdm. 177179 7 antohami 2019-01-08 18:32:18 +0300 Похоже проблема ещё и на aarch64. Сборки со slick-greeter не могут загрузить dm, но переключиться в другой tty никак там не получается, сразу же перебрасывает обратно. Подтверждаю, что проблема только на systemd, по крайней мере для i586. 177180 8 antohami 2019-01-08 19:18:03 +0300 На mipsel тоже воспроизводится. 177188 9 iv 2019-01-09 12:43:35 +0300 (In reply to comment #2) > На sysv служба стартует нормально. Может связано с обновлением systemd? Взял рабочую машину на mipsel и обновил на ней systemd 239 -> 240-alt2. Сломалось именно так. Так что это точно связанно с обновлением systemd. > В логе /var/log/lightdm/lightdm.log есть строчка после которой служба начинает > завершаться: > Critical: session_get_login1_session_id:assertion 'session !=NULL' failed Это похоже на самую интересную ниточку. Вот stacktrace того, где это происходит: (gdb) bt #0 session_get_login1_session_id (session=0x0) at session.c:677 #1 0x0040ffa8 in login1_active_session_changed_cb (login1_seat=<optimized out>, login1_session_id=0x47c470 "") at lightdm.c:1105 #2 0x772ff1ac in g_cclosure_marshal_VOID__STRINGv (closure=0x461a58, return_value=<optimized out>, instance=<optimized out>, args=<optimized out>, marshal_data=0x0, n_params=1, param_types=0x47a818) at gmarshal.c:1794 #3 0x772fbd20 in _g_closure_invoke_va (closure=0x461a58, return_value=0x0, instance=0x467618, args=0x7fd5916c, n_params=1, param_types=0x47a818) at gclosure.c:873 #4 0x7731e23c in g_signal_emit_valist (instance=0x47a350, signal_id=<optimized out>, detail=2144702948, var_args=0x7fd5916c) at gsignal.c:3300 #5 0x7731e62c in g_signal_emit (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>) at gsignal.c:3447 #6 0x004138a4 in update_property (name=<optimized out>, value=0x74e0ca40, seat=0x467618) at login1.c:97 #7 update_property (seat=0x467618, name=0x47b760 "ActiveSession", value=0x74e0ca40) at login1.c:86 #8 0x00413934 in seat_properties_changed_cb (connection=0x476818, sender_name=<optimized out>, object_path=<optimized out>, interface_name=<optimized out>, signal_name=0x482800 "PropertiesChanged", parameters=0x46a060, user_data=0x467618) at login1.c:117 #9 0x7743e0f0 in emit_signal_instance_in_idle_cb (data=0x74e0feb0) at gdbusconnection.c:3711 #10 0x77212588 in g_main_dispatch (context=0x461ab8) at gmain.c:3182 #11 g_main_context_dispatch (context=0x461ab8) at gmain.c:3847 #12 0x77212a24 in g_main_context_iterate (context=0x461ab8, block=<optimized out>, dispatch=1, self=<optimized out>) at gmain.c:3920 #13 0x77212f48 in g_main_loop_run (loop=0x463c78) at gmain.c:4116 #14 0x00408ce4 in main (argc=<optimized out>, argv=<optimized out>) at lightdm.c:1543 177190 10 iv 2019-01-09 13:27:09 +0300 >Это похоже на самую интересную ниточку. А вот и нет, хотя это тоже интересно. На самом деле падает lightdm-gtk-greeter, и падает просто очень жестко: (gdb) bt #0 raise (sig=<optimized out>) at ../sysdeps/unix/sysv/linux/raise.c:50 #1 0x76e134e0 in g_log_default_handler (log_domain=<optimized out>, log_level=<optimized out>, message=<optimized out>, unused_data=<optimized out>) at gmessages.c:3111 #2 0x76e137a4 in g_logv (log_domain=0x76e6d990 "GLib", log_level=G_LOG_LEVEL_ERROR, format=<optimized out>, args=<optimized out>) at gmessages.c:1350 #3 0x76e139ac in g_log (log_domain=<optimized out>, log_level=<optimized out>, format=<optimized out>) at gmessages.c:1413 #4 0x76e11b80 in g_malloc0 (n_bytes=32) at gmem.c:134 #5 0x76df261c in g_hash_table_new_full (hash_func=<optimized out>, key_equal_func=0x76df4064 <g_str_equal>, key_destroy_func=0x76e11c14 <g_free>, value_destroy_func=0x76ef9f3c <g_object_unref>) at ghash.c:731 #6 0x774c7968 in gtk_builder_init (builder=<optimized out>) at gtkbuilder.c:305 #7 0x76f23184 in g_type_create_instance (type=<optimized out>) at gtype.c:1864 #8 0x76efac3c in g_object_new_internal (class=0x5511f0, params=0x0, n_params=0) at gobject.c:1805 #9 0x76efcb24 in g_object_new_with_properties (object_type=6008944, n_properties=0, names=0x0, values=0x0) at gobject.c:1973 #10 0x76efd520 in g_object_new (object_type=<optimized out>, first_property_name=<optimized out>) at gobject.c:1645 #11 0x77823004 in gtk_widget_init_template (widget=0x73ef11f8) at gtkwidget.c:16946 #12 0x777b7eb0 in gtk_tooltip_window_init (self=0x73ef11f8) at gtktooltipwindow.c:80 #13 0x76f23184 in g_type_create_instance (type=<optimized out>) at gtype.c:1864 #14 0x76efac3c in g_object_new_internal (class=0x76fce8, params=0x7f986bac, n_params=1) at gobject.c:1805 #15 0x76efd3ec in g_object_new_valist (object_type=7080672, first_property_name=<optimized out>, var_args=0x7f986c90) at gobject.c:2128 #16 0x76efd504 in g_object_new (object_type=<optimized out>, first_property_name=<optimized out>) at gobject.c:1648 #17 0x777b5728 in gtk_tooltip_init (tooltip=0x7466e8) at gtktooltip.c:191 #18 0x76f23184 in g_type_create_instance (type=<optimized out>) at gtype.c:1864 #19 0x76efac3c in g_object_new_internal (class=0x6c0a98, params=0x0, n_params=0) at gobject.c:1805 #20 0x76efcb24 in g_object_new_with_properties (object_type=4813488, n_properties=0, names=0x0, values=0x0) at gobject.c:1973 #21 0x76efd520 in g_object_new (object_type=<optimized out>, first_property_name=<optimized out>) at gobject.c:1645 #22 0x777b7090 in gtk_tooltip_handle_event_internal (event=0x6bf080) at gtktooltip.c:1411 #23 0x776505dc in gtk_main_do_event (event=<optimized out>) at gtkmain.c:1952 #24 0x772baa70 in _gdk_event_emit (event=0x6bf080) at gdkevents.c:73 #25 0x772fd964 in gdk_event_source_dispatch (source=<optimized out>, callback=<optimized out>, user_data=<optimized out>) at gdkeventsource.c:367 #26 0x76e0a720 in g_main_dispatch (context=0x441c68) at gmain.c:3182 #27 g_main_context_dispatch (context=0x441c68) at gmain.c:3847 #28 0x76e0aa24 in g_main_context_iterate (context=0x441c68, block=<optimized out>, dispatch=1, self=<optimized out>) at gmain.c:3920 #29 0x76e0af48 in g_main_loop_run (loop=0x760b00) at gmain.c:4116 #30 0x7764f518 in gtk_main () at gtkmain.c:1323 #31 0x00408db4 in main (argc=<optimized out>, argv=<optimized out>) at lightdm-gtk-greeter.c:3221 Если постораться, можно вынуть из корки сообщение, которое оно пыталось залогироавть: "gmem.c:135: failed to allocate 32 bytes" То есть, ему тупо не хватило памяти. 177191 11 iv 2019-01-09 13:30:35 +0300 > То есть, ему тупо не хватило памяти. И... у нас есть workaround! [root@localhost ~]# cat /etc/systemd/system/lightdm.service.d/override.conf [Service] LimitMEMLOCK=infinity После чего, естественно, нужен systemctl daemon-reolad, или перезагрузка. Проверил и так, и так. Почему у systemd вдруг такие жесткие лимиты? 177192 12 grenka 2019-01-09 13:45:09 +0300 (В ответ на комментарий №11 > И... у нас есть workaround! Можно это увидеть в сизифе? 177193 13 iv 2019-01-09 13:50:20 +0300 (In reply to comment #11) > Почему у systemd вдруг такие жесткие лимиты? Не такие и жесткие -- 64M. Однако lightdm, чтобы нормально запустить lightdm-gtk-greeter, нужно хотя бы LimitMEMLOCK=140M (на mipsel). И то при попытке посмотреть список языков память кончилась. Иконки нынче тяжелые пошли... 177195 14 antohami 2019-01-09 13:54:59 +0300 (В ответ на комментарий №13) > (In reply to comment #11) > > Почему у systemd вдруг такие жесткие лимиты? > > Не такие и жесткие -- 64M. Однако lightdm, чтобы нормально запустить > lightdm-gtk-greeter, нужно хотя бы LimitMEMLOCK=140M (на mipsel). И то при > попытке посмотреть список языков память кончилась. > > Иконки нынче тяжелые пошли... Т.е. проблему можно решить превратив svg в png в greeter'ах? 177196 15 iv 2019-01-09 14:28:19 +0300 Дело вряд ли в иконках, это я не подумав написал. Информация для размышления: вот кусок /proc/$pid/status для slick-greeter на моём ноутбуке (x86_64): VmPeak: 707160 kB VmSize: 689840 kB VmLck: 0 kB VmPin: 0 kB VmHWM: 66568 kB VmRSS: 53380 kB VmData: 56724 kB VmStk: 132 kB VmExe: 280 kB VmLib: 26740 kB VmPTE: 472 kB VmSwap: 0 kB А вот то же самое с Таволги: [root@localhost ~]# grep '^Vm' /proc/$(pidof slick-greeter)/status VmPeak: 175472 kB VmSize: 163312 kB VmLck: 163296 kB VmPin: 0 kB VmHWM: 119536 kB VmRSS: 107376 kB VmData: 56192 kB VmStk: 160 kB VmExe: 416 kB VmLib: 30832 kB VmPTE: 80 kB VmSwap: 0 kB Почему почти вся память, которую выделяет себе greeter, на mipsel попадает в VmLck? Это стоит понять. Тем временем, очевидно, что на mipsel нужно поднимать lightdm на memlock хотя бы до 200M. Кто-нибудь может повторить эксперимент на i586 и написать, что там получается в VmLck? 177197 16 antohami 2019-01-09 14:59:47 +0300 i586 grep '^Vm' /proc/$(pidof slick-greeter)/status VmPeak: 184408 kB VmSize: 173512 kB VmLck: 173492 kB VmPin: 0 kB VmHWM: 182196 kB VmRSS: 171448 kB VmData: 61576 kB VmStk: 132 kB VmExe: 276 kB VmLib: 26952 kB VmPTE: 188 kB VmPMD: 0 kB VmSwap: 0 kB 177199 17 iv 2019-01-09 15:21:10 +0300 (In reply to comment #15) > Почему почти вся память, которую выделяет себе greeter, на mipsel попадает в > VmLck? Это стоит понять. И понять это достаточно просто: сделано это на всякий случай в самом начале main: http://git.altlinux.org/gears/l/lightdm-gtk-greeter.git?p=lightdm-gtk-greeter.git;a=blob;f=src/lightdm-gtk-greeter.c;h=39eb7cfab6316fdd20f5e357e4d2bf7b468d5fc1;hb=d93b64418e12f85e862d9091816ff49a150b16b0#l2697 Как это работало раньше, и почему на x86_64 это не приводит к проблемам -- это следующий вопрос. 177200 18 iv 2019-01-09 15:29:17 +0300 (In reply to comment #16) > i586 > > grep '^Vm' /proc/$(pidof slick-greeter)/status > VmPeak: 184408 kB > VmSize: 173512 kB > VmLck: 173492 kB [...] Спасибо! Итого: greeter'ы (и lightdm-gtk-greeter, и slick-greeter) лочат всю свою память, и это наверное правильно, а памяти ему нужно до гига. Думаю, надо написать LimitMEMLOCK=infinity в lightdm.service. shaba@? 177313 19 antohami 2019-01-14 09:54:23 +0300 (В ответ на комментарий №18) > (In reply to comment #16) > > i586 > > > > grep '^Vm' /proc/$(pidof slick-greeter)/status > > VmPeak: 184408 kB > > VmSize: 173512 kB > > VmLck: 173492 kB > [...] > > Спасибо! > > Итого: greeter'ы (и lightdm-gtk-greeter, и slick-greeter) лочат всю свою > память, и это наверное правильно, а памяти ему нужно до гига. > > Думаю, надо написать LimitMEMLOCK=infinity в lightdm.service. > > shaba@? Алексей Шабалин, откликнетесь, пожалуйста. Сегодня, очень желательно, с этим что-то решить, так как уже завтра сборка тестовых регулярок. 177314 20 iv 2019-01-14 10:21:10 +0300 Думаю, можно и самим, благо Ева в acl. Сделал test-only таск #219337. http://git.altlinux.org/people/iv/packages/lightdm.git?p=lightdm.git;a=commitdiff;h=3d4528fc8952bd05ed06eef6712594bf52f561f3 177355 21 iv 2019-01-15 11:27:30 +0300 Время офигительных историй! (In reply to comment #17) > (In reply to comment #15) > > Почему почти вся память, которую выделяет себе greeter, на mipsel попадает в > > VmLck? Это стоит понять. > > И понять это достаточно просто: сделано это на всякий случай в самом начале > main: > > http://git.altlinux.org/gears/l/lightdm-gtk-greeter.git?p=lightdm-gtk-greeter.git;a=blob;f=src/lightdm-gtk-greeter.c;h=39eb7cfab6316fdd20f5e357e4d2bf7b468d5fc1;hb=d93b64418e12f85e862d9091816ff49a150b16b0#l2697 > > Как это работало раньше, и почему на x86_64 это не приводит к проблемам -- это > следующий вопрос. Если кого-то так же, как и меня, интересовал этот вопрос, то вот разгадка: результат вызова mlockall в гритерах не проверяется, а на x86_64 к началу main сразу выделено столько памяти, что залочить её не удаётся: mlockall(MCL_CURRENT|MCL_FUTURE) = -1 ENOMEM (Cannot allocate memory) То есть, чтобы всё упало, limit на mlock должен быть достаточным чтобы вызов mlockall прошёл вначале main greeter'а, но недостаточным для полноценной работы. Найти такое значение лимита можно и для x86_64. Например, для slick-greeter оно больше 128M и меньше 512M -- если выставить лимит в 256M, проблема воспроизводится на моём боевом ноуте. В systemd 240 подняли значение лимита на mlock для сервисов по умолчанию с 32M до 64M. Этого оказалось недостаточно чтобы попасть в "проблемное окно" на x86_64, но хватило 32-битным системам. 177356 22 iv 2019-01-15 11:31:33 +0300 А может кто-нибудь затестить lightdm из таски #219399 TESTED #1 [test-only] sisyphus lightdm.git=1.16.7-alt24 ? 177357 23 antohami 2019-01-15 11:34:55 +0300 (В ответ на комментарий №22) > А может кто-нибудь затестить lightdm из таски > > #219399 TESTED #1 [test-only] sisyphus lightdm.git=1.16.7-alt24 > > ? Я проверю на i586 177360 24 antohami 2019-01-15 11:45:57 +0300 (В ответ на комментарий №23) > (В ответ на комментарий №22) > > А может кто-нибудь затестить lightdm из таски > > > > #219399 TESTED #1 [test-only] sisyphus lightdm.git=1.16.7-alt24 > > > > ? > > Я проверю на i586 Работает 177361 25 iv 2019-01-15 11:49:09 +0300 (In reply to comment #22) > А может кто-нибудь затестить lightdm из таски > > #219399 TESTED #1 [test-only] sisyphus lightdm.git=1.16.7-alt24 > > ? x86_64 не сломалось. Но при этом обнаружилось внезапное: у нас же есть не только ligtdm.service, но и prefdm.servcie; если lightdm запускается через последний, то фикс из 1.16.7-alt23 ничем не поможет. Я бы предположил, что prefdm, если он нужен, надо чинить отдельно. 177363 26 repository-robot 2019-01-15 12:09:05 +0300 lightdm-1.16.7-alt24 -> sisyphus: Tue Jan 15 2019 Ivan A. Melnikov <iv@altlinux> 1.16.7-alt24 - Replace 'Conflicts <>' with auxiliary package Mon Jan 14 2019 Ivan A. Melnikov <iv@altlinux> 1.16.7-alt23 - Remove MEMLOCK limit in systemd unit file (closes: #35844). 177372 27 mike 2019-01-15 14:44:26 +0300 (В ответ на комментарий №21) > Время офигительных историй! Феерия #ubuntu... 177646 28 grenka 2019-01-20 15:36:43 +0300 Спасибо огромное! Всё отлично работает.