[systemd-devel] Randomly on shutdown, stop timeout for user at .service (repeated report, different user)

[Kok, Auke-jan H]

On Mon, Oct 7, 2013 at 12:08 PM, Zbigniew Jędrzejewski-Szmek
<zbyszek at in.waw.pl> wrote:
> On Mon, Oct 07, 2013 at 10:03:22PM +0300, Toms Seisums wrote:
>> On 7 October 2013 20:33, Kok, Auke-jan H <auke-jan.h.kok at intel.com> wrote:
>> > On Mon, Oct 7, 2013 at 1:27 AM, Toms Seisums <toms.seisums at gmail.com>
>> > wrote:
>> > > 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).
>> >
>> > 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 user at 0.service whenever a root
> 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