Re: [systemd-devel] Help with pam_systemd..
On Mon, Jun 11, 2012 at 12:49 PM, Peeters Simon peeters.si...@gmail.com wrote: Note that we should probably not use --address=systemd: since it passes DBUS_SESSION_BUS_ADDRESS=systemd:,guid=hash to all dbus-activated services, which is entirely broken. However, we want to point to the user bus for this user, which is conveniently in %t/dbus/user_bus_socket, just as it is written in the user@.service as well. Dbus will append a ,guid=hash but I didn't see that causing a problem. i made a bugreport (and patch) to fix this. (https://bugs.freedesktop.org/show_bug.cgi?id=50962) with the attached patch dbus will automaticly convert systemd: to the real addres of the sockets passed from systemd. this makes /usr/bin/dbus-daemon --session --address=systemd: --nofork --systemd-activation work as expected (for the --address= bit, the --systemd-activation is still to be broken here) Oh cool - I'll have to test this - thanks a ton for taking the time to attack this problem! Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Help with pam_systemd..
On Tue, May 29, 2012 at 9:39 PM, Kok, Auke-jan H auke-jan.h@intel.com wrote: On Tue, May 29, 2012 at 7:56 PM, Kok, Auke-jan H auke-jan.h@intel.com wrote: On Tue, May 29, 2012 at 12:52 PM, Colin Guthrie gm...@colin.guthr.ie wrote: 'Twas brillig, and Kok, Auke-jan H at 27/05/12 08:05 did gyre and gimble: $ 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 Just a random observation from an uneducated user... but does the two ExecStartPre's really belong here for a user session? Those commands look like something that should be done only for the system dbus daemon to me... good observation, they should be dropped. Just stumbled on some more issues related to this file, so, I had some time to reflect on why this service file was entirely broken, apart from the nitpick above, which won't do much unless you run systemd --user as root, which is quite unlikely. However, the dbus-daemon args are entirely wrong, and it bit me badly trying to figure out why dbus activation was horribly broken on my system to get things like gconfd-2 or gio working. For reference, here is the proper dbus.service file: [Unit] Description=D-Bus System Message Bus Requires=dbus.socket [Service] ExecStart=/usr/bin/dbus-daemon --session --address=unix:path=%t/dbus/user_bus_socket --nofork --systemd-activation ExecReload=/usr/bin/dbus-send --print-reply --session --type=method_call --dest=org.freedesktop.DBus / org.freedesktop.DBus.ReloadConfig OOMScoreAdjust=-900 argh, ignore this, using --address=unix:path:... breaks socket activation entirely. Not sure why it worked for me in the first place. It looks like dbus will need a patch upstream to work properly in the user session, so, I'm looking at that at this time. Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Help with pam_systemd..
It looks like dbus will need a patch upstream to work properly in the user session, so, I'm looking at that at this time. Is this potentially why on boot, mine might work 1 out of every 30 boots or so? I thought it was timing (and I still believe it is, I don't know with what), but I've set up the dependencies so that user@.service is the very last thing to run, and it doesn't work. Well, most of the time.. It has worked like twice. Starting it manually works flawlessly every time, though I'm using --address=systemd:.. I don't exactly know what you found, so it's probably not working as well as it looks. I still think there's something wrong with my pam_systemd though. Even with nothing else set up, if it's defined as optional, I wouldn't expect logins to be kicked out for any reason. Shawn ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Help with pam_systemd..
On Thu, May 31, 2012 at 4:42 AM, Shawn Ferris shawn.fer...@gmail.com wrote: It looks like dbus will need a patch upstream to work properly in the user session, so, I'm looking at that at this time. Is this potentially why on boot, mine might work 1 out of every 30 boots or so? I thought it was timing (and I still believe it is, I don't know with what), but I've set up the dependencies so that user@.service is the very last thing to run, and it doesn't work. Well, most of the time.. It has worked like twice. Starting it manually works flawlessly every time, though I'm using --address=systemd:.. I don't exactly know what you found, so it's probably not working as well as it looks. I still think there's something wrong with my pam_systemd though. Even with nothing else set up, if it's defined as optional, I wouldn't expect logins to be kicked out for any reason. unlikely. dbus activation inside your user-session will be broken for stuff like gconfd-2, gio, and others, but, your user session should still run. It would help if you could post your unit files somewhere. tar up /usr/lib/systemd/user ? Auke Shawn ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Help with pam_systemd..
It would help if you could post your unit files somewhere. tar up /usr/lib/systemd/user ? Certainly.. here you go: https://www.dropbox.com/s/8lxgh04jnpuecat/unit-files.tar.bz2 At this risk of not missing anything, I tar'd up all unit files.. including those included with the distro. And here's the journalctl.. (From boot) http://pastebin.com/0zzdN2rR The user service starts fine, and even starts my test service.. but dbus --session doesn't start due to a permission denied. And here's a journalctl after I've immediately done a stop on the service and then started it again: http://pastebin.com/uvuPZLZH Thanks again for looking at this! Shawn ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Help with pam_systemd..
'Twas brillig, and Kok, Auke-jan H at 27/05/12 08:05 did gyre and gimble: $ 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 Just a random observation from an uneducated user... but does the two ExecStartPre's really belong here for a user session? Those commands look like something that should be done only for the system dbus daemon to me... Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Help with pam_systemd..
On Tue, May 29, 2012 at 12:52 PM, Colin Guthrie gm...@colin.guthr.ie wrote: 'Twas brillig, and Kok, Auke-jan H at 27/05/12 08:05 did gyre and gimble: $ 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 Just a random observation from an uneducated user... but does the two ExecStartPre's really belong here for a user session? Those commands look like something that should be done only for the system dbus daemon to me... good observation, they should be dropped. Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Help with pam_systemd..
On Tue, May 29, 2012 at 7:56 PM, Kok, Auke-jan H auke-jan.h@intel.com wrote: On Tue, May 29, 2012 at 12:52 PM, Colin Guthrie gm...@colin.guthr.ie wrote: 'Twas brillig, and Kok, Auke-jan H at 27/05/12 08:05 did gyre and gimble: $ 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 Just a random observation from an uneducated user... but does the two ExecStartPre's really belong here for a user session? Those commands look like something that should be done only for the system dbus daemon to me... good observation, they should be dropped. Just stumbled on some more issues related to this file, so, I had some time to reflect on why this service file was entirely broken, apart from the nitpick above, which won't do much unless you run systemd --user as root, which is quite unlikely. However, the dbus-daemon args are entirely wrong, and it bit me badly trying to figure out why dbus activation was horribly broken on my system to get things like gconfd-2 or gio working. For reference, here is the proper dbus.service file: [Unit] Description=D-Bus System Message Bus Requires=dbus.socket [Service] ExecStart=/usr/bin/dbus-daemon --session --address=unix:path=%t/dbus/user_bus_socket --nofork --systemd-activation ExecReload=/usr/bin/dbus-send --print-reply --session --type=method_call --dest=org.freedesktop.DBus / org.freedesktop.DBus.ReloadConfig OOMScoreAdjust=-900 Note that we should probably not use --address=systemd: since it passes DBUS_SESSION_BUS_ADDRESS=systemd:,guid=hash to all dbus-activated services, which is entirely broken. However, we want to point to the user bus for this user, which is conveniently in %t/dbus/user_bus_socket, just as it is written in the user@.service as well. Dbus will append a ,guid=hash but I didn't see that causing a problem. I'm still seeing the initial systemd --user message: May 29 21:18:39 testbox systemd[4954]: Failed to register to bus: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. But that still seems harmless. Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Help with pam_systemd..
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
Re: [systemd-devel] Help with pam_systemd..
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! so specifically for that part, I haven't done anything yet to glue systemd --user to each and every login shell, and I actually would not prefer to do this right now. My interest and implementations are all auto-login graphical desktops (such as the Tizen phone/mobile UI), but I've also done enlightenment and Xfce4 desktops. No gdm either. From that perspective, we already always start a systemd --user instance at boot, so it makes no sense to start one on login from ssh, or a local console login. Ultimately that's something the login manager should do (and can, after all it could just call `systemctl start user@username.service` for you). pam_systemd.so should setup $XDG_RUNTIME_DIR, but I don't think it sets up DBUS_SESSION_BUS_ADDRESS as you pointed out, perhaps this is something related to the initial dbus handling in systemd that's not entirely right yet, after all it prints out 1 spurious dbus message when the user instance starts. I'm slowly working my way through all the bits myself and there's a bigger one that I'm chasing now that I'd like to close first. Cheers, Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Help with pam_systemd..
On Sat, May 26, 2012 at 8:12 PM, Kok, Auke-jan H auke-jan.h@intel.com wrote: On Sat, May 26, 2012 at 3:31 PM, Shawn Ferris shawn.fer...@gmail.com wrote: #PAM-1.0 auth required pam_unix.so auth required pam_nologin.so account required pam_unix.so password required pam_unix.so session required pam_unix.so session required pam_loginuid.so -session required pam_systemd.so kill-session-processes=1 debug=1 this needs to be session optional pam_systemd.so ... Changing the entry to optional will not fix anything, only hide the problems... -- Mantas Mikulėnas ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Help with pam_systemd..
On Sun, May 27, 2012 at 1:05 AM, Kok, Auke-jan H auke-jan.h@intel.com wrote: $ grep DBUS /usr/lib/systemd/system/user@.service Environment=DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/%I/dbus/user_bus_socket Yup.. had that $ cat /usr/lib/systemd/user/dbus.socket [Unit] Description=D-Bus System Message Bus Socket [Socket] ListenStream=%t/dbus/user_bus_socket Had this too $ 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 Damn.. I read that as '--address=system:' (not systemd) and assumed it was a system service thing.. I had tried '--address=unix:path=$XDG_RUNTIME_DIR/dbus/user_bus_socket' in it's place, which obviously didn't help. 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. With the fix '--address' fix above.. when I start user@.service manually, it works beautifully! Woot! I think there must be a timing issue though.. when I reboot, systemd --user starts, but nothing else.. I'll have to check my dependencies are correct I presume. Thanks again for your help Auke! I really do appreciate it! Shawn ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Help with pam_systemd..
On Sun, May 27, 2012 at 1:13 AM, Kok, Auke-jan H auke-jan.h@intel.com wrote: 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! so specifically for that part, I haven't done anything yet to glue systemd --user to each and every login shell, and I actually would not prefer to do this right now. Honestly, it's not my interest to tie the two together either. I'm just trying to figure out the appropriate place to add pam_systemd. Looking at my fedora installation, it would indicate that it's added nearly system wide, regardless if user@.service is enabled. Obviously, when I do that, I'm locked out of my pandaboard.. It seems that the only appropriate place for this (for me) is 'systemd-shared' as defined by ' PAMName' in user@.service. Otherwise, I can't have a hybrid system where I have system --user working and still be able to log in interactively under any ID, including root. Even with the 'systemd --user' working correctly, I'm still unable to login to a shell if pam_systemd is in my login pam file. Shrug.. I'm fine with having the vars set in my profile, so I'm good now that services are started under the user session. Regards, Shawn ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Help with pam_systemd..
On Sat, May 26, 2012 at 11:12 AM, Kok, Auke-jan H auke-jan.h@intel.com wrote: which pam entry is this? /etc/pam.d/?? Just 'login' for now.. didn't want to keep breaking ssh by using other. this needs to be session optional pam_systemd.so ... I tried that too and it didn't change anything, so I put it back to the man page suggestion. most likely systemd --user doesn't know what to do. Have you created a meaningful /usr/lib/systemd/user/default.target that actually does something? e.g., create a /usr/lib/systemd/user/default.target.wants, and symlink some services in there. I haven't. I figured I'd start playing with services after I could actually get logged in with a shell. I figured out of the box, I'd at least still get a shell. Is that not true? is there a template somewhere that I could inspect? (I checked my fedora 16 box) one thing I'm missing - are you in one way or another using user@.service? If not, that may be the problem. You'll basically need to do the equivalent of systemctl enable user@username.service to tell the pid=1 systemd to autostart your systemd --user session for you. I don't think you want to only start the systemd --user instance when you logon, but rather, have it running all the time. I have actually tried with and without this, but I can't remember the results.. again, I figured it I could just enable pam_systemd and get that working, I'd add on pieces at a time. I'll re-test this and post about my findings. Thanks for the continuing help Auke! I really appreciate it! Shawn ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Help with pam_systemd..
On Sat, May 26, 2012 at 5:29 PM, Shawn Ferris shawn.fer...@gmail.com wrote: On Sat, May 26, 2012 at 11:12 AM, Kok, Auke-jan H auke-jan.h@intel.com wrote: which pam entry is this? /etc/pam.d/?? Just 'login' for now.. didn't want to keep breaking ssh by using other. this needs to be session optional pam_systemd.so ... I tried that too and it didn't change anything, so I put it back to the man page suggestion. most likely systemd --user doesn't know what to do. Have you created a meaningful /usr/lib/systemd/user/default.target that actually does something? e.g., create a /usr/lib/systemd/user/default.target.wants, and symlink some services in there. I haven't. I figured I'd start playing with services after I could actually get logged in with a shell. I figured out of the box, I'd at least still get a shell. Is that not true? is there a template somewhere that I could inspect? (I checked my fedora 16 box) I've created versions for my purposes for e.g. entire desktop startups, but essentially without a ../user/default.target there won't be anything to do for systemd --user. Systemd upstream tarball doesn't ship anything useful, so for now you need to manually define all the units and targets you want to run from your systemd --user. one thing I'm missing - are you in one way or another using user@.service? If not, that may be the problem. You'll basically need to do the equivalent of systemctl enable user@username.service to tell the pid=1 systemd to autostart your systemd --user session for you. I don't think you want to only start the systemd --user instance when you logon, but rather, have it running all the time. I have actually tried with and without this, but I can't remember the results.. again, I figured it I could just enable pam_systemd and get that working, I'd add on pieces at a time. I'll re-test this and post about my findings. This isn't an automagic thing that just works, since there is absolutely no consensus over what a user instance of systemd actually is, in the first place. In short, the needed bits are: 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. Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Help with pam_systemd..
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. Any more clues? Shawn ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
