[Bug 1012883] New: System hangs at reboot/shutdown: A stop job is running for User Manager for UID 1000 (1min30)
http://bugzilla.opensuse.org/show_bug.cgi?id=1012883
Bug ID: 1012883 Summary: System hangs at reboot/shutdown: A stop job is running for User Manager for UID 1000 (1min30) Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: 64bit OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Bootloader Assignee: jsrain@suse.com Reporter: jeckferson@gmail.com QA Contact: jsrain@suse.com Found By: --- Blocker: ---
It's an upstream systemd bug as described in:
https://github.com/systemd/systemd/issues/1615
It also manifested in 42.2.
http://bugzilla.opensuse.org/show_bug.cgi?id=1012883
Jiri Srain jsrain@suse.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|Bootloader |Basesystem Assignee|jsrain@suse.com |systemd-maintainers@suse.de QA Contact|jsrain@suse.com |qa-bugs@suse.de
http://bugzilla.opensuse.org/show_bug.cgi?id=1012883 http://bugzilla.opensuse.org/show_bug.cgi?id=1012883#c1
Franck Bui fbui@suse.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |fbui@suse.com
--- Comment #1 from Franck Bui fbui@suse.com --- So doing as described in comment https://github.com/systemd/systemd/issues/1615#issuecomment-223836805 fixes this issue ?
Also is this 100% reproducible ?
http://bugzilla.opensuse.org/show_bug.cgi?id=1012883 http://bugzilla.opensuse.org/show_bug.cgi?id=1012883#c2
--- Comment #2 from Kyaw Thu Soe jeckferson@gmail.com --- It had happened 3 times in Tumbleweed up until the image 20161125. The occurence is intermittent and I was waiting for it to happen again for three days now. I was distro-hopping around this issue. Debian Jessie 8.6 with systemd 215.x, Centos 7.2 with 219.x or someversion (I don't remember exactly): all infected by this bug. I reported it for Debian. They ignored my report for months without a single reply. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=822996
From reading the journalctl logs, it had something to do with coredump. I found
klauncher started coredumping just before the 90s time lapse. I will report the log when it happen again. Also I updated the bios yesterday. Apparently, not all machine live through this problem hence it might be hardware-related.
http://bugzilla.opensuse.org/show_bug.cgi?id=1012883 http://bugzilla.opensuse.org/show_bug.cgi?id=1012883#c3
--- Comment #3 from Franck Bui fbui@suse.com --- If you use persistent journals (probably the default on TW), you should be able to read the old logs from previous boots(see man journalctl and the '-b' option).
Otherwise I would recommend to switch to persistent journal mode (by creating /var/log/journal directory and restart systemd-journald.service).
Could you try the following test (several time if you can't reproduce):
0/ enable the debug logs: "systemd-analyze set-log-level debug"
1/ try to login (as a regular user) via your display manager (GDM, LXDM, ...) and start all applications you use to execute (chromium, firefox, ...).
2/ open a root session (via ssh for example)
3/ in your root session: retrieve the session number created when you logged in as a regular user by executing "loginctl"
4/ in your root session: stop your regular session with "systemctl stop session-<id>.scope" where "id" is the session number you found in the previous step.
5/ if the command is stuck, this means that you reproduced the issue otherwise back to step 1/
6/ so the command is stuck which probably means that a process is failing to react to the SIGTERM sent by systemd when you stopped/closed your user session. In that case please show the content of the following commands:
6.1/ ps aux 6.2/ systemd-cgls 6.3/ journalctl -b
Thanks !
http://bugzilla.opensuse.org/show_bug.cgi?id=1012883 http://bugzilla.opensuse.org/show_bug.cgi?id=1012883#c4
--- Comment #4 from Kyaw Thu Soe jeckferson@gmail.com --- Created attachment 704873 --> http://bugzilla.opensuse.org/attachment.cgi?id=704873&action=edit yesterdaystopjob
Pay attention to the following time-lapsing lines:
" Dec 05 07:02:58 linux-ghot systemd[1]: Stopped Session 3 of user kts. Dec 05 07:03:01 linux-ghot systemd[1]: Received SIGRTMIN+20 from PID 2490 (plymouthd). Dec 05 07:03:04 linux-ghot systemd[1]: Received SIGRTMIN+20 from PID 2490 (plymouthd). Dec 05 07:04:25 linux-ghot systemd[1]: session-1.scope: Stopping timed out. Killing. "
It happened yesterday again.
http://bugzilla.opensuse.org/show_bug.cgi?id=1012883 http://bugzilla.opensuse.org/show_bug.cgi?id=1012883#c5
--- Comment #5 from Franck Bui fbui@suse.com --- Then please follow the procedure provided in comment #3 so we can try to find out what's going on.
http://bugzilla.opensuse.org/show_bug.cgi?id=1012883 http://bugzilla.opensuse.org/show_bug.cgi?id=1012883#c6
Franck Bui fbui@suse.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |kde-maintainers@suse.de Flags| |needinfo?(kde-maintainers@s | |use.de)
--- Comment #6 from Franck Bui fbui@suse.com --- Ok I've been able to reproduce a similar issue on Leap 42.2 with KDE as default DE (like you).
Apparently when closing the session, the process "ksmserver" was reacting badly to the TERM signal sent by systemd. The process was stuck somewhere in its signal handler:
(gdb) bt #0 0x00007f70e869ef66 in waitpid () from /lib64/libc.so.6 #1 0x00007f70e126fbf2 in ?? () from /usr/lib64/libKF5Crash.so.5 #2 0x00007f70e12706d4 in KCrash::defaultCrashHandler(int) () from /usr/lib64/libKF5Crash.so.5 #3 <signal handler called> #4 0x00007f70e59b8883 in ?? () from /usr/lib64/libKF5GlobalAccel.so.5 #5 0x00007f70e59b2bab in ?? () from /usr/lib64/libKF5GlobalAccel.so.5 #6 0x00007f70e2fc01c3 in QMetaObject::activate(QObject*, int, int, void**) () from /usr/lib64/libQt5Core.so.5 #7 0x00007f70e2fc07af in QObject::destroyed(QObject*) () from /usr/lib64/libQt5Core.so.5 #8 0x00007f70e2fc825e in QObject::~QObject() () from /usr/lib64/libQt5Core.so.5 #9 0x00007f70e3c93bd8 in QAction::~QAction() () from /usr/lib64/libQt5Widgets.so.5 #10 0x00007f70e3c93bf9 in QAction::~QAction() () from /usr/lib64/libQt5Widgets.so.5 #11 0x00007f70e2fbeaa5 in QObjectPrivate::deleteChildren() () from /usr/lib64/libQt5Core.so.5 #12 0x00007f70e2fc7fbe in QObject::~QObject() () from /usr/lib64/libQt5Core.so.5 #13 0x00007f70e5c1ffbe in KActionCollection::~KActionCollection() () from /usr/lib64/libKF5XmlGui.so.5 #14 0x00007f70e5c20069 in KActionCollection::~KActionCollection() () from /usr/lib64/libKF5XmlGui.so.5 #15 0x00007f70e2fbeaa5 in QObjectPrivate::deleteChildren() () from /usr/lib64/libQt5Core.so.5 #16 0x00007f70e2fc7fbe in QObject::~QObject() () from /usr/lib64/libQt5Core.so.5 #17 0x00007f70e89a1389 in KSMServer::~KSMServer (this=0x26b5620, __in_chrg=<optimized out>) at /usr/src/debug/plasma-workspace-5.8.3/ksmserver/server.cpp:733 #18 0x00007f70e899f75c in sighandler (sig=<optimized out>) at /usr/src/debug/plasma-workspace-5.8.3/ksmserver/server.cpp:539 #19 <signal handler called> #20 sighandler (sig=1) at /usr/src/debug/plasma-workspace-5.8.3/ksmserver/server.cpp:529 #21 <signal handler called> #22 0x00007f70d6a30bd0 in ?? () from /usr/lib64/libgbm.so.1 #23 0x00007f70e8bdf21a in _dl_fini () from /lib64/ld-linux-x86-64.so.2 #24 0x00007f70e861c139 in __run_exit_handlers () from /lib64/libc.so.6 #25 0x00007f70e861c185 in exit () from /lib64/libc.so.6 #26 0x00007f70d305addd in QXcbConnection::processXcbEvents() () from /usr/lib64/libQt5XcbQpa.so.5 #27 0x00007f70e2fc1166 in QObject::event(QEvent*) () from /usr/lib64/libQt5Core.so.5 #28 0x00007f70e3c9ce3c in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib64/libQt5Widgets.so.5 #29 0x00007f70e3ca149a in QApplication::notify(QObject*, QEvent*) () from /usr/lib64/libQt5Widgets.so.5 #30 0x00007f70e2f95fc5 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /usr/lib64/libQt5Core.so.5 #31 0x00007f70e2f97daa in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () from /usr/lib64/libQt5Core.so.5 #32 0x00007f70e2fe6c83 in ?? () from /usr/lib64/libQt5Core.so.5 #33 0x00007f70dcbb6134 in g_main_context_dispatch () from /usr/lib64/libglib-2.0.so.0 #34 0x00007f70dcbb6388 in ?? () from /usr/lib64/libglib-2.0.so.0 #35 0x00007f70dcbb642c in g_main_context_iteration () from /usr/lib64/libglib-2.0.so.0 #36 0x00007f70e2fe632b in QEventDispatcherGlib::processEvents(QFlagsQEventLoop::ProcessEventsFlag) () from /usr/lib64/libQt5Core.so.5 #37 0x00007f70e2f93fdb in QEventLoop::exec(QFlagsQEventLoop::ProcessEventsFlag) () from /usr/lib64/libQt5Core.so.5 #38 0x00007f70e2f9bec6 in QCoreApplication::exec() () from /usr/lib64/libQt5Core.so.5 #39 0x00007f70e899b4f7 in kdemain (argc=1, argv=<optimized out>) at /usr/src/debug/plasma-workspace-5.8.3/ksmserver/main.cpp:349 #40 0x00007f70e86056e5 in __libc_start_main () from /lib64/libc.so.6 #41 0x0000000000400839 in _start () at ../sysdeps/x86_64/start.S:118 (gdb)
KDE team, could you give a look at the backtrace ?
http://bugzilla.opensuse.org/show_bug.cgi?id=1012883 http://bugzilla.opensuse.org/show_bug.cgi?id=1012883#c7
--- Comment #7 from Kyaw Thu Soe jeckferson@gmail.com --- When that happened, nothing can ever be typed. The machine goes into unresponsive mode with three asterisk moving back and forth. It always happens around Plymouthd in my cases in both openSUSE and Centos. It's machine specific in that my Dell Inspiron with Sandybridge chipset showed no sign of that problem or any problems. It's only Haswell that occured. I will permanently set log level to debug from now on.
http://bugzilla.opensuse.org/show_bug.cgi?id=1012883 http://bugzilla.opensuse.org/show_bug.cgi?id=1012883#c8
--- Comment #8 from Franck Bui fbui@suse.com --- (In reply to Kyaw Thu Soe from comment #7)
I will permanently set log level to debug from now on.
Unfortunately, that won't really help as systemd doesnt show the hanging processes that prevents the user session to be closed hence to shutdown the system even in debug mode.
However I built a test package that includes such traces which will help us to identify the culprit (hopefully).
Could you install the following repo on your affected system and try to reproduce ?
In order to do that, please do:
zypper ar http://download.opensuse.org/repositories/home:/fbui:/branches:/openSUSE:/Fa... systemd-with-debug-trace zypper dup --repo systemd-with-debug-trace
Also make sure to have the journal in persistent mode: mkdir -p /var/log/journal
and then reboot until you can reproduce the issue.
Once done please show the content of the journal of the previous boot (journalctl -b -1 and search for the "FOO" string).
Thanks.
http://bugzilla.opensuse.org/show_bug.cgi?id=1012883 http://bugzilla.opensuse.org/show_bug.cgi?id=1012883#c9
--- Comment #9 from Franck Bui fbui@suse.com --- With the testing package, I managed to reproduce the issue one more time and the journal had:
Dec 07 18:59:39 linux-bzg2 systemd[1]: session-1.scope: Stopping timed out. Killing. Dec 07 18:59:39 linux-bzg2 systemd[1]: session-1.scope: ksmserver ignored TERM signal, killed. Dec 07 18:59:39 linux-bzg2 systemd[1]: session-1.scope changed stop-sigterm -> stop-sigkill Dec 07 18:59:39 linux-bzg2 systemd[1]: Received SIGCHLD from PID 1883 (ksmserver). Dec 07 18:59:39 linux-bzg2 systemd[1]: Child 1883 (ksmserver) died (code=killed, status=9/KILL) Dec 07 18:59:39 linux-bzg2 systemd[1]: session-1.scope: Child 1883 belongs to session-1.scope Dec 07 18:59:39 linux-bzg2 systemd[1]: session-1.scope: cgroup is empty Dec 07 18:59:39 linux-bzg2 systemd[1]: session-1.scope changed stop-sigkill -> failed Dec 07 18:59:39 linux-bzg2 systemd[1]: session-1.scope: Job session-1.scope/stop finished, result=done Dec 07 18:59:39 linux-bzg2 systemd[1]: Stopped Session 1 of user fbui. Dec 07 18:59:39 linux-bzg2 systemd[1]: session-1.scope: Unit entered failed state.
This confirms that ksmserver is the hanging process that seems to fail to handle the TERM signal properly in my case.
http://bugzilla.opensuse.org/show_bug.cgi?id=1012883 http://bugzilla.opensuse.org/show_bug.cgi?id=1012883#c10
--- Comment #10 from Kyaw Thu Soe jeckferson@gmail.com --- Created attachment 705719 --> http://bugzilla.opensuse.org/attachment.cgi?id=705719&action=edit multiple
By setting permanent debug LogLevel, I got additional messages between the time lapse. The problem is always before the "session-1.scope: Stopping timed out. Killing." line.
If you search my attachment the keyword "timed out" several time FROM THE BOTTOM, you will found the offending process, systemd-timesyncd.service which is not previously found due to the info LogLevel. Every other previous hanging can be browsed with the "timed out" keyword or "session-1.scope: Stopping timed out. Killing." keyword. It's always after the "Received SIGRTMIN+20 from PID 2332 (plymouthd)" and before the "session-1.scope: Stopping timed out". If you query the keyword "timed out" several times, there's so much occurrence of the line "systemd-timesyncd[1077]: Timed out waiting for reply from 216.239.35.12:123 (time4.google.com)" here and there which is highly distrust-able.
One coredump occurence just before the problem is also found:
"systemd-coredump[2328]: Process 2327 (klauncher) of user 1000 dumped core. Nov 29 20:17:09 linux-ghot systemd[1]: Received SIGRTMIN+20 from PID 2332 (plymouthd)."
According to this bug report: https://www.reddit.com/r/archlinux/comments/4bawf7/a_stop_job_is_running_for... it's due to timesyncd.
According to https://github.com/systemd/systemd/issues/1615 and https://github.com/systemd/systemd/issues/2691
it's due to coredump which was fixed at the later versions.
http://bugzilla.opensuse.org/show_bug.cgi?id=1012883 http://bugzilla.opensuse.org/show_bug.cgi?id=1012883#c11
--- Comment #11 from Franck Bui fbui@suse.com --- (In reply to Kyaw Thu Soe from comment #10)
Created attachment 705719 [details] multiple
and what about trying the testing package in comment #9 ?
and please do not send all journals from your system...
http://bugzilla.opensuse.org/show_bug.cgi?id=1012883 http://bugzilla.opensuse.org/show_bug.cgi?id=1012883#c12
--- Comment #12 from Kyaw Thu Soe jeckferson@gmail.com --- Feel bad man.
http://bugzilla.opensuse.org/show_bug.cgi?id=1012883 http://bugzilla.opensuse.org/show_bug.cgi?id=1012883#c13
--- Comment #13 from Franck Bui fbui@suse.com --- Don't dude, you'll feel better after.
http://bugzilla.opensuse.org/show_bug.cgi?id=1012883 http://bugzilla.opensuse.org/show_bug.cgi?id=1012883#c14
Franck Bui fbui@suse.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Assignee|systemd-maintainers@suse.de |kde-maintainers@suse.de
--- Comment #14 from Franck Bui fbui@suse.com --- Dear KDE maintainers,
I think this issue is due to ksmserver that fails to handle TERM signal sent by systemd during the shutdown so I'm reassigning this bug to you so it can get some care.
This doesn't happen systematically however.
See comment #6 and comment #9 for some details.
Thanks.
http://bugzilla.opensuse.org/show_bug.cgi?id=1012883 http://bugzilla.opensuse.org/show_bug.cgi?id=1012883#c15
--- Comment #15 from Kyaw Thu Soe jeckferson@gmail.com --- These days, the occasional encounters of it read regularly like the following.
One can find more of this occurrence in the previous attachment named "multiple" by searching the word "timed out". To my relief, systemd 232v is in Factory staging and possibly will come out any minute now. It will perhaps bring an end to the problems of coredump or timesyncd, which I think are the root causes.
Dec 12 16:19:36 linux-ghot systemd[1]: Started Show Plymouth Reboot Screen. Dec 12 16:19:36 linux-ghot systemd[1]: Accepted new private connection. Dec 12 16:19:36 linux-ghot systemd[1]: Got message type=signal sender=n/a destination=n/a object=/org/freedesktop/systemd1/agent interface=org.freedesktop.systemd1.Agent member=Released cookie=1 reply_cookie=0 error=n/a Dec 12 16:19:36 linux-ghot systemd[1]: Got disconnect on private connection. Dec 12 16:19:40 linux-ghot systemd[1]: systemd-journald.service: Got notification message from PID 588 (FDSTORE=1) Dec 12 16:19:40 linux-ghot systemd[1]: systemd-journald.service: Added fd to fd store. Dec 12 16:19:40 linux-ghot systemd[1]: systemd-journald.service: Got notification message from PID 588 (FDSTORE=1) Dec 12 16:19:40 linux-ghot systemd[1]: systemd-journald.service: Added fd to fd store. Dec 12 16:19:41 linux-ghot systemd[1]: systemd-timesyncd.service: Got notification message from PID 1042 (WATCHDOG=1) Dec 12 16:19:41 linux-ghot systemd[1]: systemd-timesyncd.service: Got notification message from PID 1042 (STATUS=Idle.) Dec 12 16:19:41 linux-ghot systemd[1]: systemd-timesyncd.service: Got notification message from PID 1042 (STATUS=Idle.) Dec 12 16:19:41 linux-ghot systemd[1]: systemd-timesyncd.service: Got notification message from PID 1042 (STATUS=Idle.) Dec 12 16:19:41 linux-ghot systemd[1]: systemd-timesyncd.service: Got notification message from PID 1042 (STATUS=Idle.) Dec 12 16:19:41 linux-ghot systemd[1]: systemd-timesyncd.service: Got notification message from PID 1042 (STATUS=Idle.) Dec 12 16:19:41 linux-ghot systemd[1]: systemd-timesyncd.service: Got notification message from PID 1042 (STATUS=Idle.) Dec 12 16:19:41 linux-ghot systemd[1]: systemd-timesyncd.service: Got notification message from PID 1042 (STATUS=Idle.) Dec 12 16:19:41 linux-ghot systemd[1]: systemd-timesyncd.service: Got notification message from PID 1042 (STATUS=Idle.) Dec 12 16:19:41 linux-ghot systemd[1]: systemd-timesyncd.service: Got notification message from PID 1042 (STATUS=Idle.) Dec 12 16:19:41 linux-ghot systemd[1]: systemd-timesyncd.service: Got notification message from PID 1042 (STATUS=Idle.) Dec 12 16:19:41 linux-ghot systemd[1]: systemd-timesyncd.service: Got notification message from PID 1042 (STATUS=Idle.) Dec 12 16:19:41 linux-ghot systemd[1]: systemd-timesyncd.service: Got notification message from PID 1042 (STATUS=Idle.) Dec 12 16:19:41 linux-ghot systemd[1]: systemd-timesyncd.service: Got notification message from PID 1042 (STATUS=Idle.) Dec 12 16:19:41 linux-ghot systemd[1]: systemd-timesyncd.service: Got notification message from PID 1042 (STATUS=Idle.) Dec 12 16:19:41 linux-ghot systemd[1]: systemd-timesyncd.service: Got notification message from PID 1042 (STATUS=Idle.) Dec 12 16:19:41 linux-ghot systemd[1]: systemd-timesyncd.service: Got notification message from PID 1042 (STATUS=Idle.) Dec 12 16:19:41 linux-ghot systemd[1]: systemd-timesyncd.service: Got notification message from PID 1042 (STATUS=Idle.) Dec 12 16:19:41 linux-ghot systemd[1]: systemd-timesyncd.service: Got notification message from PID 1042 (STATUS=Idle.) Dec 12 16:19:41 linux-ghot systemd[1]: systemd-timesyncd.service: Got notification message from PID 1042 (STATUS=Idle.) Dec 12 16:19:41 linux-ghot systemd[1]: systemd-timesyncd.service: Got notification message from PID 1042 (STATUS=Idle.) Dec 12 16:19:41 linux-ghot systemd[1]: systemd-timesyncd.service: Got notification message from PID 1042 (STATUS=Idle.) Dec 12 16:19:42 linux-ghot systemd[1]: Received SIGRTMIN+20 from PID 2245 (plymouthd). Dec 12 16:19:42 linux-ghot systemd[1]: Enabling showing of status. Dec 12 16:20:12 linux-ghot systemd[1]: systemd-timesyncd.service: Got notification message from PID 1042 (STATUS=Idle.) Dec 12 16:20:12 linux-ghot systemd[1]: systemd-timesyncd.service: Got notification message from PID 1042 (STATUS=Idle.) Dec 12 16:20:12 linux-ghot systemd[1]: systemd-timesyncd.service: Got notification message from PID 1042 (STATUS=Idle.) Dec 12 16:20:12 linux-ghot systemd[1]: systemd-timesyncd.service: Got notification message from PID 1042 (STATUS=Idle.) Dec 12 16:20:12 linux-ghot systemd[1]: systemd-timesyncd.service: Got notification message from PID 1042 (STATUS=Idle.) Dec 12 16:20:12 linux-ghot systemd[1]: systemd-timesyncd.service: Got notification message from PID 1042 (STATUS=Idle.) Dec 12 16:20:12 linux-ghot systemd[1]: systemd-timesyncd.service: Got notification message from PID 1042 (STATUS=Idle.) Dec 12 16:20:12 linux-ghot systemd[1]: systemd-timesyncd.service: Got notification message from PID 1042 (STATUS=Idle.) Dec 12 16:20:12 linux-ghot systemd[1]: systemd-timesyncd.service: Got notification message from PID 1042 (STATUS=Idle.) Dec 12 16:20:12 linux-ghot systemd[1]: systemd-timesyncd.service: Got notification message from PID 1042 (STATUS=Idle.) Dec 12 16:20:12 linux-ghot systemd[1]: systemd-timesyncd.service: Got notification message from PID 1042 (STATUS=Idle.) Dec 12 16:20:12 linux-ghot systemd[1]: systemd-timesyncd.service: Got notification message from PID 1042 (STATUS=Idle.) Dec 12 16:20:12 linux-ghot systemd[1]: systemd-timesyncd.service: Got notification message from PID 1042 (STATUS=Idle.) Dec 12 16:20:12 linux-ghot systemd[1]: systemd-timesyncd.service: Got notification message from PID 1042 (STATUS=Idle.) Dec 12 16:20:12 linux-ghot systemd[1]: systemd-timesyncd.service: Got notification message from PID 1042 (STATUS=Idle.) Dec 12 16:20:12 linux-ghot systemd[1]: systemd-timesyncd.service: Got notification message from PID 1042 (STATUS=Idle.) Dec 12 16:20:12 linux-ghot systemd[1]: systemd-timesyncd.service: Got notification message from PID 1042 (STATUS=Idle.) Dec 12 16:20:12 linux-ghot systemd[1]: systemd-timesyncd.service: Got notification message from PID 1042 (STATUS=Idle.) Dec 12 16:20:12 linux-ghot systemd[1]: systemd-timesyncd.service: Got notification message from PID 1042 (STATUS=Idle.) Dec 12 16:20:12 linux-ghot systemd[1]: systemd-timesyncd.service: Got notification message from PID 1042 (STATUS=Idle.) Dec 12 16:20:12 linux-ghot systemd[1]: systemd-timesyncd.service: Got notification message from PID 1042 (STATUS=Idle.) Dec 12 16:20:20 linux-ghot systemd[1]: Received SIGRTMIN+20 from PID 2245 (plymouthd). Dec 12 16:20:20 linux-ghot systemd[1]: Enabling showing of status. Dec 12 16:20:26 linux-ghot systemd[1]: systemd-udevd.service: Got notification message from PID 625 (WATCHDOG=1) Dec 12 16:20:35 linux-ghot systemd[1]: session-1.scope: Stopping timed out. Killing. Dec 12 16:20:35 linux-ghot systemd[1]: session-1.scope changed stop-sigterm -> stop-sigkill Dec 12 16:20:35 linux-ghot systemd[1]: Received SIGCHLD from PID 2183 (drkonqi). Dec 12 16:20:35 linux-ghot systemd[1]: Child 1675 (kded5) died (code=killed, status=9/KILL) Dec 12 16:20:35 linux-ghot systemd[1]: session-1.scope: Child 1675 belongs to session-1.scope Dec 12 16:20:35 linux-ghot systemd[1]: Child 2183 (drkonqi) died (code=exited, status=1/FAILURE) Dec 12 16:20:35 linux-ghot systemd[1]: session-1.scope: Child 2183 belongs to session-1.scope Dec 12 16:20:35 linux-ghot systemd[1]: session-1.scope: cgroup is empty Dec 12 16:20:35 linux-ghot systemd[1]: session-1.scope changed stop-sigkill -> failed Dec 12 16:20:35 linux-ghot systemd[1]: session-1.scope: Job session-1.scope/stop finished, result=done Dec 12 16:20:35 linux-ghot systemd[1]: Stopped Session 1 of user kts. Dec 12 16:20:35 linux-ghot systemd[1]: session-1.scope: Unit entered failed state.
http://bugzilla.opensuse.org/show_bug.cgi?id=1012883 http://bugzilla.opensuse.org/show_bug.cgi?id=1012883#c16
--- Comment #16 from Franck Bui fbui@suse.com --- (In reply to Kyaw Thu Soe from comment #15)
One can find more of this occurrence in the previous attachment named "multiple" by searching the word "timed out". To my relief, systemd 232v is in Factory staging and possibly will come out any minute now. It will perhaps bring an end to the problems of coredump or timesyncd, which I think are the root causes.
Currently I don't think coredump nor timesyncd is your problem. And you can easily check that by disabling both of them and see if the problem goes away.
http://bugzilla.opensuse.org/show_bug.cgi?id=1012883 http://bugzilla.opensuse.org/show_bug.cgi?id=1012883#c17
--- Comment #17 from Kyaw Thu Soe jeckferson@gmail.com --- Thank you for all your replies, my friend :). I will wait for the 232v. Logging out of the session before shutdown/reboot will cope in the meantime.
http://bugzilla.opensuse.org/show_bug.cgi?id=1012883
Tomáš Chvátal tchvatal@suse.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Assignee|kde-maintainers@suse.de |opensuse-kde-bugs@opensuse. | |org
http://bugzilla.opensuse.org/show_bug.cgi?id=1012883 http://bugzilla.opensuse.org/show_bug.cgi?id=1012883#c18
Wolfgang Bauer wbauer@tmo.at changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jeckferson@gmail.com, | |wbauer@tmo.at Flags|needinfo?(kde-maintainers@s |needinfo?(jeckferson@gmail. |use.de) |com)
--- Comment #18 from Wolfgang Bauer wbauer@tmo.at --- So, is this still a problem or can it be closed?
There have been many updates since then...
http://bugzilla.opensuse.org/show_bug.cgi?id=1012883 http://bugzilla.opensuse.org/show_bug.cgi?id=1012883#c19
Felix Miata mrmazda@earthlink.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mrmazda@earthlink.net
--- Comment #19 from Felix Miata mrmazda@earthlink.net --- For me the timeout period is two minutes for UID 0. This has happened multiple times in recent days following zypper dups on various PCs.
Mailing list thread I started 3 days ago: https://lists.opensuse.org/opensuse-support/2019-03/msg00090.html
To reproduce: 1-boot Tumbleweed to multi-user 2-login root 3-zypper ref; zypper dup 4-issue shutdown or reboot command
Actual behavior: 1-reboot is delayed 2 minutes waiting on User Manager for UID 0 stop job
Expected behavior: 1-reboot or shutdown takes mere seconds
http://bugzilla.opensuse.org/show_bug.cgi?id=1012883 http://bugzilla.opensuse.org/show_bug.cgi?id=1012883#c20
--- Comment #20 from Felix Miata mrmazda@earthlink.net --- In case it might matter: 1-plymouth is not installed 2-sddm is not installed 3-lightdm is not installed 4-one of kdm or tdm or or kdm3 is installed 5-grub2* are not installed 6-systems are all multiboot 7-nfs filesystems are mounted 8-no cifs filesystems are mounted 9-samba and nfs servers are enabled, but no connections are active
http://bugzilla.opensuse.org/show_bug.cgi?id=1012883
Manfred Hollstein manfred.h@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |manfred.h@gmx.net
http://bugzilla.opensuse.org/show_bug.cgi?id=1012883 http://bugzilla.opensuse.org/show_bug.cgi?id=1012883#c21
--- Comment #21 from Felix Miata mrmazda@earthlink.net --- "Ctrl-Alt-Del was pressed more than 7 times within 2s" spews, but has no effect on the two minute UID 0 stop job wait.
http://bugzilla.opensuse.org/show_bug.cgi?id=1012883 http://bugzilla.opensuse.org/show_bug.cgi?id=1012883#c22
Felix Miata mrmazda@earthlink.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Hardware|64bit |All
--- Comment #22 from Felix Miata mrmazda@earthlink.net --- Delay of 2 minutes waiting on User Manager for UID 0 stop job has happened here at least 3 times in recent days, hosts gx260, gx28b & gx760, two of which are i586.
http://bugzilla.opensuse.org/show_bug.cgi?id=1012883 http://bugzilla.opensuse.org/show_bug.cgi?id=1012883#c24
Axel Braun axel.braun@gmx.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |CONFIRMED CC| |axel.braun@gmx.de Flags|needinfo?(jeckferson@gmail. | |com) |
--- Comment #24 from Axel Braun axel.braun@gmx.de --- I see this issue as well on TW 20200609, esp. after switching between users (log-off one user, log in as different user)
I feel we can set this to 'confirmed'
http://bugzilla.opensuse.org/show_bug.cgi?id=1012883 http://bugzilla.opensuse.org/show_bug.cgi?id=1012883#c25
Jazz jayjayjazz@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jayjayjazz@gmail.com
--- Comment #25 from Jazz jayjayjazz@gmail.com --- I reinstalled one of my machines some days ago. This issue did not occur until the reinstallation. For the installation itself I used "openSUSE-Tumbleweed-NET-x86_64-Snapshot20220805-Media".
Since then, I am seeing also this hang situation. I also did update the machine using zypper.
My journalctl is showing these messages, but I don't know, if they are really related:
Stopped User Login Management Started Show Plymouth Power Off Screen Tell Plymouth To Jump To initramfs was skipped because of a failed condition check (ConditionPathExists=/run/initramfs/bin/sh) plasma-kded.service: State 'stop-sigterm' timed out. Killing. plasma-kded.service: Killing process 1653 (kded5) with signal SIGKILL. plasma-kded.service: Killing process 1686 (dconf worker) with signal SIGKILL. plasma-kded.service: Main process exited, code=killed, status=9/KILL plasma-kded.service: Failed with result 'timeout'. <<<
Unfortunately, this bug report and also the mail thread do not contain a clear hint, what the problem might be.
http://bugzilla.opensuse.org/show_bug.cgi?id=1012883 http://bugzilla.opensuse.org/show_bug.cgi?id=1012883#c26
--- Comment #26 from Jazz jayjayjazz@gmail.com --- Additional Info: There is another Forum Topic: https://forums.opensuse.org/showthread.php/565261-90-Sekunden-stop-job-beim-...
Unfortunately, it is only in German.
-
bugzilla_noreply＠novell.com -
bugzilla_noreply＠suse.com