Discussion:
Randomly on shutdown, stop timeout for user at .service (repeated report, different user)
(too old to reply)
Toms Seisums
2013-09-30 15:55:14 UTC
Permalink
It appears that history repeats itself.

Once (July 2013) a similar issue was reported here, by different user:
http://lists.freedesktop.org/archives/systemd-devel/2013-July/012283.html

I'm also using Arch Linux, systemd-207, linux-3.11.2.

On shutdown and reboot, ***@0.service occasionally freezes my system until
it times out and gets killed.

Steps to reproduce:
1) Boot
2) Login
3) Execute either systemctl reboot or reboot or shutdown -h now or whatever.

I've went through the steps here, to get a proper shutdown log:
http://freedesktop.org/wiki/Software/systemd/Debugging/#shutdowncompleteseventually

And, the shutdown log can be found here: http://pastebin.com/wbr04AQw

The actual lines related to issue:

#2223 [ 74.387130] systemd[1]: Got D-Bus request:
org.freedesktop.DBus.Local.Disconnected() on /org/freedesktop/DBus/Local
#2224 [ 163.814925] systemd[1]: ***@0.service stopping timed out. Killing.
#2225 [ 163.815447] systemd[1]: ***@0.service changed stop-sigterm ->
stop-sigkill
#2226 [ 163.816063] systemd[1]: Received SIGCHLD from PID 326 (systemd).
#2227 [ 163.816093] systemd[1]: Got SIGCHLD for process 326 (systemd)
#2228 [ 163.816153] systemd[1]: Child 326 died (code=killed, status=9/KILL)
#2229 [ 163.816158] systemd[1]: Child 326 belongs to ***@0.service
#2230 [ 163.816171] systemd[1]: ***@0.service: main process exited,
code=killed, status=9/KILL
#2231 [ 163.816183] systemd[1]: ***@0.service changed stop-sigkill ->
failed

I currently haven't found out a pattern for this. I have attempted to quit
some processes before initiating the shutdown/reboot, but the result is
random.

About 95% of shutdowns/reboots it will be a long one.
3% it will be noticeably longer than the quickest one, but shorter than the
above one.
Remaining 2%, the shutdown will be very quick.

It also happens if I get to log in console screen and Ctrl + Alt + Del,
like, I perform an ASAP shutdown after boot.

In case anything more is needed, please ask.
--
Toms Seisums

- (+371) 26431391

May the force be with you, always!
Andrey Borzenkov
2013-09-30 16:32:03 UTC
Permalink
В Mon, 30 Sep 2013 18:55:14 +0300
Post by Toms Seisums
It appears that history repeats itself.
http://lists.freedesktop.org/archives/systemd-devel/2013-July/012283.html
I'm also using Arch Linux, systemd-207, linux-3.11.2.
it times out and gets killed.
1) Boot
2) Login
3) Execute either systemctl reboot or reboot or shutdown -h now or whatever.
http://freedesktop.org/wiki/Software/systemd/Debugging/#shutdowncompleteseventually
And, the shutdown log can be found here: http://pastebin.com/wbr04AQw
org.freedesktop.DBus.Local.Disconnected() on /org/freedesktop/DBus/Local
Full log would be interesting. As far as I can tell, SIGRTMIN+24 used to
terminate user instance is either lost or ignored. But I could never
reproduce it while using any form of debugging.

https://bugzilla.novell.com/show_bug.cgi?id=841544
Lennart Poettering
2013-10-01 00:43:38 UTC
Permalink
Post by Toms Seisums
It appears that history repeats itself.
http://lists.freedesktop.org/archives/systemd-devel/2013-July/012283.html
I'm also using Arch Linux, systemd-207, linux-3.11.2.
it times out and gets killed.
1) Boot
2) Login
3) Execute either systemctl reboot or reboot or shutdown -h now or whatever.
http://freedesktop.org/wiki/Software/systemd/Debugging/#shutdowncompleteseventually
And, the shutdown log can be found here: http://pastebin.com/wbr04AQw
org.freedesktop.DBus.Local.Disconnected() on /org/freedesktop/DBus/Local
stop-sigkill
#2226 [ 163.816063] systemd[1]: Received SIGCHLD from PID 326 (systemd).
#2227 [ 163.816093] systemd[1]: Got SIGCHLD for process 326 (systemd)
#2228 [ 163.816153] systemd[1]: Child 326 died (code=killed, status=9/KILL)
code=killed, status=9/KILL
failed
I currently haven't found out a pattern for this. I have attempted to quit
some processes before initiating the shutdown/reboot, but the result is
random.
About 95% of shutdowns/reboots it will be a long one.
3% it will be noticeably longer than the quickest one, but shorter than the
above one.
Remaining 2%, the shutdown will be very quick.
Hmm, this is the systemd user instance for root which fails to shut
down. Can you reproduce this if you start/stop "***@0.service" quickly
in a loop?

Lennart
--
Lennart Poettering - Red Hat, Inc.
Toms Seisums
2013-10-04 16:31:43 UTC
Permalink
@Andrey, the full log can be found here, the link was there before also:
http://pastebin.com/wbr04AQw (systemd-207)
It's quite silent about the cause for the timeout, though.

I've been debugging this for three days now, and I've crystallized a little
bit of information.

1. If I boot the system and stay on login screen, no matter when I hit
Ctrl+Alt+Del (ASAP or after an hour), the system will always reboot
normally.
2. If I login, and instantly type `reboot`, in about 75% the system will
reboot normally, the other 25% being slow, resulting in ***@0.servicetimeout.
2.1. If I login and wait for some time, the next reboot is going to be slow.
3. I'm using Arch, and they had a bug report already there -
https://bugs.archlinux.org/task/37007, it has come down to that systemd-208
fixes it, though, I've updated and the problem still remains.
4. I've attempted numerous daemon configurations, but the results are
inconsistent. Due to that Arch issue being closed and not reopened, I did
this, in order to find out whether running daemons aren't at fault.
4.1. I, for some reboot's disabled every daemon (not also running them
after the system booted up), and the reboots/shutdowns were still slow.
4.1.1. The Ctrl+Alt+Del before logging in, is still fast.
5. Downgrading to systemd-204 works flawlessly, also removing the issue
that's described in next point.
6. Whenever I boot with systemd-207 or systemd-208 and login, I am
presented with:

Failed to open private bus connection: Failed to connect to socket
/run/user/0/dbus/user_bus_socket: No such file or directory

6.1. The issue appears to already be reported by @Andrey - here:
http://lists.freedesktop.org/archives/systemd-devel/2013-September/013393.html
7. Apparently, I specially set up a system running in VBox, also an Arch
Linux, that didn't have the problem neither running with systemd-207,
neither has it with systemd-208 (that actually led me to disable the
daemons).
7.1. I did encounter it once though, but since then, it hasn't happened.
8. If, before running shutdown, I manually: `systemctl stop ***@0.service`,
the system shuts down prefectly.

Here are some logs of shutdown with systemd-208:

1. Quick, Ctrl+Alt+Del before logging in. (1: http://pastebin.com/5X0sUHCV)
2. Slow, executed a little later after logging in. (2:
http://pastebin.com/tjnLNJKH)
3. Slow, executed by Ctrl+Alt+Del after logging in, doing some tasks, then
`logout`. (3: http://pastebin.com/4hEmRYen)
4. I wanted to catch a fast reboot with a full login and full daemons
running, but couldn't manage to - they all were slow.
5. It also happens if I log in with a different user than root and push
Ctrl+Alt+Del. (4: http://pastebin.com/U36WqDzP)
5.1. This is just a test for you @Lennart, just to see if a different user
changes anything.
6. `systemctl stop ***@0.service` to `reboot`, that results in a quick
one. (5: http://pastebin.com/aJ0s32MR) (I, for a second thought that Apache
might be causing some issues, because it almost always gets killed, so, I
disabled it for some tests, this log has no Apache information - that's
just in case you're wondering why the logs don't match. More on Apache
adventures below...)
6.1. I reran it after Apache tests to clarify, quick reboot the first time
(9: http://pastebin.com/HcUA72AE). The second time. (10:
http://pastebin.com/rf96QiGA) The third time. (11:
http://pastebin.com/bpFu1sQK) All in a row. I did 2 more to test for the
next point, all quick.
6.2. This doesn't seem to change the SFTP behavior, though.

An extra piece of information I can provide, is that, this appears to
happen to break SFTP. If I boot, then connect from my other PC with SFTP
(as root), and initiate a reboot from tty0, my SFTP connection will not be
dropped. It will actually never even timeout. I could restart my Linux
machine for about 100times, and the SFTP window will not even blink,
thinking that it's connected. Only when I refresh the SFTP window, I get an
error message, asking me to reconnect. With systemd-204 there is no such an
issue - it disconnects immediately. Though, on my VBox Arch, there wasn't
such an issue with systemd-207, nor with systemd-208.


And @Lennart, you asked, I delivered, here is a log with
***@0.servicestart/stop with 0.5second intervals between start/stop
calls. I stripped
the booting sequence, starting the log off at about where the system ended
it's boot. (12: http://sharetext.org/zJc, the link is different because I
exceeded pastebins free limit, doh).
Nothing special there, except that dbus thingy.

---

Apache:

So, noticing that Apache gets killed most of time, and systemd-204 also had
some delays where it waited for Apache to exit, I thought that the problem
is with Apache.

I started this debugging scenario by simply doing a "systemctl stop httpd"
into "reboot", that made my system to reboot quickly. (6:
http://pastebin.com/4NgxVAeP)

Though, one `httpd` instance still remains (occasionally, when I "systemctl
stop httpd", "ps aux" immediately after - will still display one httpd
process), that appears to actually be a bug in Apache's (I guess), that
appears to be the one that has to be explicitly killed at the end of reboot
process.

By partially confirming, that this is because of Apache, I stopped it upon
next boot, disabled it, and rebooted. Starting freshly with "ps aux"
reporting no signs of httpd, I attempted to "reboot" - guess what? That's a
long one. Three times in a row with no httpd upon boot - all reboots were
long, I guess that's not Apache then.

While writing the above and debugging, after having enabled Apache back and
stopping it upon boot, even though previous reboots executed immediately,
one didn't. (7: http://pastebin.com/3FnikCX9) Apparently the next one after
it also didn't. (8: http://pastebin.com/pnWhuQWC)

---

P.S. While debugging this, and trying to link some of the problems to some
of the daemons, I'm starting to feel as if I'd hit a delusion spree. While
occasionally it reboots fast, it might as well be just the random
quick-reboot I've been hunting before. Just that stopping those daemons
makes me think the problem is tied to them.


---

Loads of information, some of it are probably total duplicates, but I hope
I've given enough and that you'll be able to understand what I've provided.
More importantly, I hope that this will help to resolve these issues.
Post by Toms Seisums
Post by Toms Seisums
It appears that history repeats itself.
http://lists.freedesktop.org/archives/systemd-devel/2013-July/012283.html
Post by Toms Seisums
I'm also using Arch Linux, systemd-207, linux-3.11.2.
until
Post by Toms Seisums
it times out and gets killed.
1) Boot
2) Login
3) Execute either systemctl reboot or reboot or shutdown -h now or
whatever.
http://freedesktop.org/wiki/Software/systemd/Debugging/#shutdowncompleteseventually
Post by Toms Seisums
And, the shutdown log can be found here: http://pastebin.com/wbr04AQw
org.freedesktop.DBus.Local.Disconnected() on /org/freedesktop/DBus/Local
Killing.
Post by Toms Seisums
stop-sigkill
#2226 [ 163.816063] systemd[1]: Received SIGCHLD from PID 326 (systemd).
#2227 [ 163.816093] systemd[1]: Got SIGCHLD for process 326 (systemd)
#2228 [ 163.816153] systemd[1]: Child 326 died (code=killed,
status=9/KILL)
Post by Toms Seisums
code=killed, status=9/KILL
failed
I currently haven't found out a pattern for this. I have attempted to
quit
Post by Toms Seisums
some processes before initiating the shutdown/reboot, but the result is
random.
About 95% of shutdowns/reboots it will be a long one.
3% it will be noticeably longer than the quickest one, but shorter than
the
Post by Toms Seisums
above one.
Remaining 2%, the shutdown will be very quick.
Hmm, this is the systemd user instance for root which fails to shut
in a loop?
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
Toms Seisums

- (+371) 26431391

May the force be with you, always!
Toms Seisums
2013-10-04 16:37:10 UTC
Permalink
Next reboot after the ***@0.service start/stop cycle was a quick one. It
looks as something gets messed up upon logging in. And if not resolved, the
system has problems shutting down.
Post by Toms Seisums
http://pastebin.com/wbr04AQw (systemd-207)
It's quite silent about the cause for the timeout, though.
I've been debugging this for three days now, and I've crystallized a
little bit of information.
1. If I boot the system and stay on login screen, no matter when I hit
Ctrl+Alt+Del (ASAP or after an hour), the system will always reboot
normally.
2. If I login, and instantly type `reboot`, in about 75% the system will
2.1. If I login and wait for some time, the next reboot is going to be slow.
3. I'm using Arch, and they had a bug report already there -
https://bugs.archlinux.org/task/37007, it has come down to that
systemd-208 fixes it, though, I've updated and the problem still remains.
4. I've attempted numerous daemon configurations, but the results are
inconsistent. Due to that Arch issue being closed and not reopened, I did
this, in order to find out whether running daemons aren't at fault.
4.1. I, for some reboot's disabled every daemon (not also running them
after the system booted up), and the reboots/shutdowns were still slow.
4.1.1. The Ctrl+Alt+Del before logging in, is still fast.
5. Downgrading to systemd-204 works flawlessly, also removing the issue
that's described in next point.
6. Whenever I boot with systemd-207 or systemd-208 and login, I am
Failed to open private bus connection: Failed to connect to socket
/run/user/0/dbus/user_bus_socket: No such file or directory
http://lists.freedesktop.org/archives/systemd-devel/2013-September/013393.html
7. Apparently, I specially set up a system running in VBox, also an Arch
Linux, that didn't have the problem neither running with systemd-207,
neither has it with systemd-208 (that actually led me to disable the
daemons).
7.1. I did encounter it once though, but since then, it hasn't happened.
the system shuts down prefectly.
http://pastebin.com/5X0sUHCV)
http://pastebin.com/tjnLNJKH)
3. Slow, executed by Ctrl+Alt+Del after logging in, doing some tasks,
then `logout`. (3: http://pastebin.com/4hEmRYen)
4. I wanted to catch a fast reboot with a full login and full daemons
running, but couldn't manage to - they all were slow.
5. It also happens if I log in with a different user than root and push
Ctrl+Alt+Del. (4: http://pastebin.com/U36WqDzP)
user changes anything.
one. (5: http://pastebin.com/aJ0s32MR) (I, for a second thought that
Apache might be causing some issues, because it almost always gets killed,
so, I disabled it for some tests, this log has no Apache information -
that's just in case you're wondering why the logs don't match. More on
Apache adventures below...)
6.1. I reran it after Apache tests to clarify, quick reboot the first
http://pastebin.com/bpFu1sQK) All in a row. I did 2 more to test for the
next point, all quick.
6.2. This doesn't seem to change the SFTP behavior, though.
An extra piece of information I can provide, is that, this appears to
happen to break SFTP. If I boot, then connect from my other PC with SFTP
(as root), and initiate a reboot from tty0, my SFTP connection will not be
dropped. It will actually never even timeout. I could restart my Linux
machine for about 100times, and the SFTP window will not even blink,
thinking that it's connected. Only when I refresh the SFTP window, I get an
error message, asking me to reconnect. With systemd-204 there is no such an
issue - it disconnects immediately. Though, on my VBox Arch, there wasn't
such an issue with systemd-207, nor with systemd-208.
the booting sequence, starting the log off at about where the system ended
it's boot. (12: http://sharetext.org/zJc, the link is different because I
exceeded pastebins free limit, doh).
Nothing special there, except that dbus thingy.
---
So, noticing that Apache gets killed most of time, and systemd-204 also
had some delays where it waited for Apache to exit, I thought that the
problem is with Apache.
I started this debugging scenario by simply doing a "systemctl stop httpd"
http://pastebin.com/4NgxVAeP)
Though, one `httpd` instance still remains (occasionally, when I
"systemctl stop httpd", "ps aux" immediately after - will still display one
httpd process), that appears to actually be a bug in Apache's (I guess),
that appears to be the one that has to be explicitly killed at the end of
reboot process.
By partially confirming, that this is because of Apache, I stopped it upon
next boot, disabled it, and rebooted. Starting freshly with "ps aux"
reporting no signs of httpd, I attempted to "reboot" - guess what? That's a
long one. Three times in a row with no httpd upon boot - all reboots were
long, I guess that's not Apache then.
While writing the above and debugging, after having enabled Apache back
and stopping it upon boot, even though previous reboots executed
immediately, one didn't. (7: http://pastebin.com/3FnikCX9) Apparently the
next one after it also didn't. (8: http://pastebin.com/pnWhuQWC)
---
P.S. While debugging this, and trying to link some of the problems to some
of the daemons, I'm starting to feel as if I'd hit a delusion spree. While
occasionally it reboots fast, it might as well be just the random
quick-reboot I've been hunting before. Just that stopping those daemons
makes me think the problem is tied to them.
---
Loads of information, some of it are probably total duplicates, but I hope
I've given enough and that you'll be able to understand what I've provided.
More importantly, I hope that this will help to resolve these issues.
Post by Toms Seisums
Post by Toms Seisums
It appears that history repeats itself.
http://lists.freedesktop.org/archives/systemd-devel/2013-July/012283.html
Post by Toms Seisums
I'm also using Arch Linux, systemd-207, linux-3.11.2.
until
Post by Toms Seisums
it times out and gets killed.
1) Boot
2) Login
3) Execute either systemctl reboot or reboot or shutdown -h now or
whatever.
http://freedesktop.org/wiki/Software/systemd/Debugging/#shutdowncompleteseventually
Post by Toms Seisums
And, the shutdown log can be found here: http://pastebin.com/wbr04AQw
org.freedesktop.DBus.Local.Disconnected() on /org/freedesktop/DBus/Local
Killing.
Post by Toms Seisums
stop-sigkill
#2226 [ 163.816063] systemd[1]: Received SIGCHLD from PID 326
(systemd).
Post by Toms Seisums
#2227 [ 163.816093] systemd[1]: Got SIGCHLD for process 326 (systemd)
#2228 [ 163.816153] systemd[1]: Child 326 died (code=killed,
status=9/KILL)
Post by Toms Seisums
code=killed, status=9/KILL
failed
I currently haven't found out a pattern for this. I have attempted to
quit
Post by Toms Seisums
some processes before initiating the shutdown/reboot, but the result is
random.
About 95% of shutdowns/reboots it will be a long one.
3% it will be noticeably longer than the quickest one, but shorter than
the
Post by Toms Seisums
above one.
Remaining 2%, the shutdown will be very quick.
Hmm, this is the systemd user instance for root which fails to shut
in a loop?
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
Toms Seisums
- (+371) 26431391
May the force be with you, always!
--
Toms Seisums

- (+371) 26431391

May the force be with you, always!
Kok, Auke-jan H
2013-10-04 18:57:44 UTC
Permalink
[object Object]
Look at Gmail failing flat on its face... lol

Aside from that, can you perhaps try this patch:

--- systemd-user-sessions.service 2013-10-02 15:37:14.181330287 -0700
+++ systemd-user-sessions.service 2013-10-04 11:53:37.023333867 -0700
@@ -8,7 +8,7 @@
[Unit]
Description=Permit User Sessions
Documentation=man:systemd-user-sessions.service(8)
-After=remote-fs.target
+After=remote-fs.target dbus.service

[Service]
Type=oneshot

some colleagues of mine identified that tasks in the user session that
attempt to contact the system bus during shutdown may hang doing so.
We can prevent this hang by making user sessions shut down entirely
first before dbus is destroyed.

It may or may not help. You can also insert After=dbus.service in to
***@.service, but I feel this is a better spot.


Thanks,

Auke
Tom Gundersen
2013-10-04 22:46:03 UTC
Permalink
On Fri, Oct 4, 2013 at 8:57 PM, Kok, Auke-jan H
Post by Kok, Auke-jan H
[object Object]
Look at Gmail failing flat on its face... lol
--- systemd-user-sessions.service 2013-10-02 15:37:14.181330287 -0700
+++ systemd-user-sessions.service 2013-10-04 11:53:37.023333867 -0700
@@ -8,7 +8,7 @@
[Unit]
Description=Permit User Sessions
Documentation=man:systemd-user-sessions.service(8)
-After=remote-fs.target
+After=remote-fs.target dbus.service
[Service]
Type=oneshot
some colleagues of mine identified that tasks in the user session that
attempt to contact the system bus during shutdown may hang doing so.
We can prevent this hang by making user sessions shut down entirely
first before dbus is destroyed.
It may or may not help. You can also insert After=dbus.service in to
This sounds reasonable (until kdbus is here ;) ).

However, should we perhaps take it one step further and order
dbus.service Before=basic.target to also cover stuff outside of user
sessions that may fall in its face when dbus goes away.

Cheers,

Tom
Toms Seisums
2013-10-07 08:27:40 UTC
Permalink
I got two systems having the exact same problem with similar symptoms. Both
systems are upgraded to latest Arch Linux, and just recieved Linux Kernel
3.11.4 upgrades also.

One is running on Linode, one is a local machine.

Apparently, the fix provided by Auke does not resolve the problem.
Tom Gundersens' one, though, does it.

Two problems still remain, though:

1. The dbus notice message upon logging in (Failed to open private bus
connection: Failed to connect to socket /run/user/0/dbus/user_bus_socket:
No such file or directory).
2. The SFTP problem - upon restart, the SFTP connection is not killed.
Post by Tom Gundersen
On Fri, Oct 4, 2013 at 8:57 PM, Kok, Auke-jan H
Post by Kok, Auke-jan H
[object Object]
Look at Gmail failing flat on its face... lol
--- systemd-user-sessions.service 2013-10-02 15:37:14.181330287 -0700
+++ systemd-user-sessions.service 2013-10-04 11:53:37.023333867 -0700
@@ -8,7 +8,7 @@
[Unit]
Description=Permit User Sessions
Documentation=man:systemd-user-sessions.service(8)
-After=remote-fs.target
+After=remote-fs.target dbus.service
[Service]
Type=oneshot
some colleagues of mine identified that tasks in the user session that
attempt to contact the system bus during shutdown may hang doing so.
We can prevent this hang by making user sessions shut down entirely
first before dbus is destroyed.
It may or may not help. You can also insert After=dbus.service in to
This sounds reasonable (until kdbus is here ;) ).
However, should we perhaps take it one step further and order
dbus.service Before=basic.target to also cover stuff outside of user
sessions that may fall in its face when dbus goes away.
Cheers,
Tom
--
Toms Seisums

- (+371) 26431391

May the force be with you, always!
Kok, Auke-jan H
2013-10-07 17:33:41 UTC
Permalink
Post by Toms Seisums
I got two systems having the exact same problem with similar symptoms. Both
systems are upgraded to latest Arch Linux, and just recieved Linux Kernel
3.11.4 upgrades also.
One is running on Linode, one is a local machine.
Apparently, the fix provided by Auke does not resolve the problem.
Tom Gundersens' one, though, does it.
1. The dbus notice message upon logging in (Failed to open private bus
connection: Failed to connect to socket /run/user/0/dbus/user_bus_socket: No
such file or directory).
Why are you starting a session dbus for user root?

Auke
Toms Seisums
2013-10-07 19:03:22 UTC
Permalink
I'm not, it's started automatically. Might be an issue in Arch Linux.
Post by Toms Seisums
Post by Toms Seisums
I got two systems having the exact same problem with similar symptoms.
Both
Post by Toms Seisums
systems are upgraded to latest Arch Linux, and just recieved Linux Kernel
3.11.4 upgrades also.
One is running on Linode, one is a local machine.
Apparently, the fix provided by Auke does not resolve the problem.
Tom Gundersens' one, though, does it.
1. The dbus notice message upon logging in (Failed to open private bus
connection: Failed to connect to socket
/run/user/0/dbus/user_bus_socket: No
Post by Toms Seisums
such file or directory).
Why are you starting a session dbus for user root?
Auke
--
Toms Seisums

- (+371) 26431391

May the force be with you, always!
Zbigniew Jędrzejewski-Szmek
2013-10-07 19:08:07 UTC
Permalink
Post by Toms Seisums
Post by Toms Seisums
Post by Toms Seisums
I got two systems having the exact same problem with similar symptoms.
Both
Post by Toms Seisums
systems are upgraded to latest Arch Linux, and just recieved Linux Kernel
3.11.4 upgrades also.
One is running on Linode, one is a local machine.
Apparently, the fix provided by Auke does not resolve the problem.
Tom Gundersens' one, though, does it.
1. The dbus notice message upon logging in (Failed to open private bus
connection: Failed to connect to socket
/run/user/0/dbus/user_bus_socket: No
Post by Toms Seisums
such file or directory).
Why are you starting a session dbus for user root?
I'm not, it's started automatically. Might be an issue in Arch Linux.
I think that we (as in upstream) start ***@0.service whenever a root
session is opened by cron or whatever.

Zbyszek
Kok, Auke-jan H
2013-10-07 19:58:16 UTC
Permalink
On Mon, Oct 7, 2013 at 12:08 PM, Zbigniew Jędrzejewski-Szmek
Post by Zbigniew Jędrzejewski-Szmek
Post by Toms Seisums
Post by Toms Seisums
Post by Toms Seisums
I got two systems having the exact same problem with similar symptoms.
Both
Post by Toms Seisums
systems are upgraded to latest Arch Linux, and just recieved Linux Kernel
3.11.4 upgrades also.
One is running on Linode, one is a local machine.
Apparently, the fix provided by Auke does not resolve the problem.
Tom Gundersens' one, though, does it.
1. The dbus notice message upon logging in (Failed to open private bus
connection: Failed to connect to socket
/run/user/0/dbus/user_bus_socket: No
Post by Toms Seisums
such file or directory).
Why are you starting a session dbus for user root?
I'm not, it's started automatically. Might be an issue in Arch Linux.
session is opened by cron or whatever.
ahh yes, I see that here now too.

So, the reason that dbus.socket/dbus.service isn't setup or anything
is that there is no properly setup default.target that requires or
sets up dbus.socket for user sessions.

Doing a `ln -sf /usr/lib/systemd/user/dbus.socket
/etc/systemd/user/default.target.wants/dbus.socket` (quick hack) or
something like that maybe helps, but you're running into the basic
problem that there's just not enough there for systemd --user to do
anything useful (no default target defined, no dependencies installed
to "sane" defaults, etc.).

Auke
Andrey Borzenkov
2013-10-08 02:53:37 UTC
Permalink
В Mon, 7 Oct 2013 12:58:16 -0700
Post by Kok, Auke-jan H
Doing a `ln -sf /usr/lib/systemd/user/dbus.socket
/etc/systemd/user/default.target.wants/dbus.socket` (quick hack) or
something like that maybe helps, but you're running into the basic
problem that there's just not enough there for systemd --user to do
anything useful (no default target defined, no dependencies installed
to "sane" defaults, etc.).
If there nothing to run as user session, why systemd starts user
session?

You probably misunderstand the problem. Stock systemd will start
***@0.service when session for root opens (and I assume
user@$UID.service for each other user). This service sometimes does not
stop on shutdown causing timeout. If this service is not needed, it
should not be started, right? So it is not "we" who are running in
basic problem - it is systemd which is running into basic problem :)
Kok, Auke-jan H
2013-10-08 06:29:38 UTC
Permalink
Post by Andrey Borzenkov
В Mon, 7 Oct 2013 12:58:16 -0700
Post by Kok, Auke-jan H
Doing a `ln -sf /usr/lib/systemd/user/dbus.socket
/etc/systemd/user/default.target.wants/dbus.socket` (quick hack) or
something like that maybe helps, but you're running into the basic
problem that there's just not enough there for systemd --user to do
anything useful (no default target defined, no dependencies installed
to "sane" defaults, etc.).
If there nothing to run as user session, why systemd starts user
session?
You probably misunderstand the problem. Stock systemd will start
stop on shutdown causing timeout. If this service is not needed, it
should not be started, right? So it is not "we" who are running in
basic problem - it is systemd which is running into basic problem :)
I can't speak for others, but I have not yet reproduced the issue at
shutdown with just an empty ***@0.service running.

Auke
Arokux
2013-10-21 16:01:33 UTC
Permalink
Post by Tom Gundersen
However, should we perhaps take it one step further and order
dbus.service Before=basic.target to also cover stuff outside of user
sessions that may fall in its face when dbus goes away.
Unfortunately the proposed fix won't help. I still have the same issue.
Toms Seisums
2013-10-21 16:15:26 UTC
Permalink
No, I haven't. I have attempted every single post-204 fix found on the
internet and nothing seems to be fixing the issue.

Only thing fixing is downgrading to 204.

I have connected some dots with services that are running, but it's very
random. It happens much less with some daemons turned off, but still can
happen and symptoms appear to be the same.

I'm out of clues, and for now, have forfeited my attempts at debugging the
issue.
Post by Arokux
Post by Tom Gundersen
However, should we perhaps take it one step further and order
dbus.service Before=basic.target to also cover stuff outside of user
sessions that may fall in its face when dbus goes away.
Unfortunately the proposed fix won't help. I still have the same issue.
_______________________________________________
systemd-devel mailing list
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
Toms Seisums

- (+371) 26431391

May the force be with you, always!
Andrey Borzenkov
2013-10-21 18:59:48 UTC
Permalink
В Mon, 21 Oct 2013 19:15:26 +0300
Post by Toms Seisums
No, I haven't. I have attempted every single post-204 fix found on the
internet and nothing seems to be fixing the issue.
Only thing fixing is downgrading to 204.
I have connected some dots with services that are running, but it's very
random. It happens much less with some daemons turned off, but still can
happen and symptoms appear to be the same.
I'm out of clues, and for now, have forfeited my attempts at debugging the
issue.
In my case root cause appears to be outside of systemd (kernel?). I
ended up masking ***@.service; it does not do anything useful right
now anyway as far as I can tell.
Post by Toms Seisums
Post by Arokux
Post by Tom Gundersen
However, should we perhaps take it one step further and order
dbus.service Before=basic.target to also cover stuff outside of user
sessions that may fall in its face when dbus goes away.
Unfortunately the proposed fix won't help. I still have the same issue.
_______________________________________________
systemd-devel mailing list
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Andrey Borzenkov
2013-10-04 16:59:33 UTC
Permalink
В Fri, 4 Oct 2013 19:31:43 +0300
Post by Toms Seisums
http://pastebin.com/wbr04AQw (systemd-207)
It's quite silent about the cause for the timeout, though.
How do you generate it? It lacks any output from systemd in user mode.
Use "journalctl -b -1" to output all messages during previous boot.

Some of of other logs you linked have only very early boot messages, no
shutdown messages.
Post by Toms Seisums
1. If I boot the system and stay on login screen, no matter when I hit
Ctrl+Alt+Del (ASAP or after an hour), the system will always reboot
normally.
Of course. ***@0.service is started during login only.
Toms Seisums
2013-10-04 18:47:56 UTC
Permalink
All of those are shutdown messages, generated by:
http://freedesktop.org/wiki/Software/systemd/Debugging/#shutdowncompleteseventually

In case boot messages are needed, I'll be able to provide them on monday.

If I need to change some kernel parameters for shutdown to get more verbose
output, I'd like to know how. I'm fairly new to Linux and systemd in
general.
В Fri, 4 Oct 2013 19:31:43 +0300
Post by Toms Seisums
http://pastebin.com/wbr04AQw (systemd-207)
It's quite silent about the cause for the timeout, though.
How do you generate it? It lacks any output from systemd in user mode.
Use "journalctl -b -1" to output all messages during previous boot.
Some of of other logs you linked have only very early boot messages, no
shutdown messages.
Post by Toms Seisums
1. If I boot the system and stay on login screen, no matter when I hit
Ctrl+Alt+Del (ASAP or after an hour), the system will always reboot
normally.
--
Toms Seisums

- (+371) 26431391

May the force be with you, always!
Arokux
2013-10-21 15:51:35 UTC
Permalink
Hi Toms,

there was a lengthy discussion here, but have you succeeded in fixing the
problem? I have the same issue now...

Thanks,
Arokux
Continue reading on narkive:
Loading...