On Sun, May 27, 2012 at 5:51 AM, Shawn Ferris <shawn.fer...@gmail.com> wrote: > On Sat, May 26, 2012 at 10:00 PM, Shawn Ferris <shawn.fer...@gmail.com> wrote: >>> 1) systemctl --system start user@<username>.service (may not work, but is >>> usable as a template) >>> 2) ../user/default.target needs to define something meaningful >>> 3) "session optional pam_systemd.so" in /etc/pam.d/systemd-auth >>> 4) proper dbus.socket/dbus.service in ../user/ if you need a session bus >>> >>> without any of these, nothing will happen. >> >> Ok.. thanks Auke! I guess I'm a little surprised that having a >> user@<username>.service and all that jazz is a requirement just to get >> a simple shell. I'll give it a shot though. Appreciate the patience! >> >> Shawn > > Oops.. some how I removed the ML from that response... > > With all these piece now in place, systemd --user properly starts. (it > always had actually, it just never did anything beyond that) But now, > dbus also starts properly-ish. (see below) > > However, logging in interactively still doesn't work when pam_systemd > is enable. (using "session optional") > > If I go through ssh (w/o pam_systemd), i have to set > DBUS_SESSION_BUS_ADDRESS manually, but 'systemctl --user' hangs. I > presume it's because dbus and systemd are unable to register: > > Jan 01 01:50:52 jarvis systemd[1679]: About to execute: > /usr/bin/dbus-daemon --session --nofork --systemd-activation > Jan 01 01:50:52 jarvis systemd[1679]: Forked /usr/bin/dbus-daemon as 1683 > Jan 01 01:50:52 jarvis systemd[1679]: dbus.service changed start-pre -> > running > Jan 01 01:50:52 jarvis systemd[1679]: Job dbus.service/start finished, > result=done > Jan 01 01:50:52 jarvis systemd[1679]: default.target changed dead -> active > Jan 01 01:50:52 jarvis systemd[1679]: Job default.target/start > finished, result=done > Jan 01 01:50:52 jarvis systemd[1679]: Startup finished in 173ms 401us. > Jan 01 01:50:52 jarvis systemd[1679]: Got D-Bus request on system bus: > org.freedesktop.systemd1.Agent.Released() on > /org/freedesktop/systemd1/agent > Jan 01 01:50:52 jarvis systemd[1679]: Incoming traffic on dbus.socket > Jan 01 01:50:52 jarvis systemd[1679]: dbus.socket changed listening -> running > Jan 01 01:51:17 jarvis systemd[1679]: Failed to register to bus: Did > not receive a reply. Possible causes include: the remote application > did not send a reply, the message... was broken. > Jan 01 01:51:17 jarvis systemd[1679]: Failed setting up the API bus > > I'm looking to see if I have something blatantly misconfigured, but so > far haven't spotted it. I have a feeling it's related to why I can't > enable pam_systemd and open an interactive session.
make sure you have all of this in place: $ grep DBUS /usr/lib/systemd/system/user@.service Environment=DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/%I/dbus/user_bus_socket $ cat /usr/lib/systemd/user/dbus.socket [Unit] Description=D-Bus System Message Bus Socket [Socket] ListenStream=%t/dbus/user_bus_socket $ cat /usr/lib/systemd/user/dbus.service [Unit] Description=D-Bus System Message Bus Requires=dbus.socket [Service] ExecStartPre=/usr/bin/dbus-uuidgen --ensure ExecStartPre=-/bin/rm -f /var/run/messagebus.pid ExecStart=/usr/bin/dbus-daemon --session --address=systemd: --nofork --systemd-activation ExecReload=/usr/bin/dbus-send --print-reply --session --type=method_call --dest=org.freedesktop.DBus / org.freedesktop.DBus.ReloadConfig OOMScoreAdjust=-900 Also, you can try to add export XDG_RUNTIME_DIR=/run/user/$USER export DBUS_SESSION_BUS_ADDRESS=unix:path=$XDG_RUNTIME_DIR/dbus/user_bus_socket into your ~/.bashrc or ~/.bash_profile, which should make your logins automatically see the right session bus. Cheers, Auke _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
