Re: [systemd-devel] Bug in systemd? Running X without a display manager
On Sun, 26 Aug 2012, Dave Reisner wrote: On Fri, Aug 24, 2012 at 12:17:08PM -0400, Alan Stern wrote: I need some help with a problem. I'm currently using Fedora 16, but without a display manager. I log into a text-mode VT (usually tty1) and run startx manually. The display uses tty7 and works fine. But systemd isn't aware of it, or at least, isn't aware that my login session now owns tty7. For example, the devices labelled with the uaccess tag have their ACLs adjusted so that I can't use them in the graphical environment. (When I switch back to a text-mode VT they work fine.) I'm not sure who to blame for this: systemd, dbus, or myself. Still, it seems like this _ought_ to work okay. Can anybody help? Alan Stern You'll need to start X on the same VT that you logged in on. If it's tty1, then: startx -- vt01 That's a reasonable workaround, but it's not a real fix. Fedora 16 uses ConsoleKit, and testing shows that ConsoleKit is aware of both the test-mode and X session whereas systemd isn't: [stern@iolanthe ~]$ ck-list-sessions Session1: unix-user = '2102' realname = 'Alan Stern' seat = 'Seat1' session-type = '' active = FALSE x11-display = '' x11-display-device = '' display-device = '/dev/tty1' remote-host-name = '' is-local = TRUE on-since = '2012-08-27T13:52:33.245828Z' login-session-id = '1' idle-since-hint = '2012-08-27T13:53:04.012294Z' Session2: unix-user = '2102' realname = 'Alan Stern' seat = 'Seat1' session-type = '' active = TRUE x11-display = ':0' x11-display-device = '/dev/tty7' display-device = '' remote-host-name = '' is-local = TRUE on-since = '2012-08-27T13:52:37.086051Z' login-session-id = '1' [stern@iolanthe ~]$ systemd-loginctl list-sessions SESSIONUID USER SEAT 1 2102 sternseat0 1 sessions listed. [stern@iolanthe ~]$ systemd-loginctl show-session 1 Id=1 Name=stern Timestamp=Mon, 27 Aug 2012 09:52:32 -0400 TimestampMonotonic=100394935 ControlGroupPath=/user/stern/1 VTNr=1 TTY=tty1 Remote=no Service=login Leader=992 Audit=1 Type=tty Active=no KillProcesses=no IdleHint=yes IdleSinceHint=3 IdleSinceHintMonotonic=0 Evidently information is getting sent to (or by) ConsoleKit but not to systemd, or else the information does get sent to systemd and systemd ignores it. Either way, this is a bug (although I can't tell where). Now perhaps ConsoleKit is old hat and nobody cares about it any more. I haven't tried doing this under a more recent version of Fedora. Is there any reason to think it would work any better? Alan Stern ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Bug in systemd? Running X without a display manager
On Mon, Aug 27, 2012 at 10:32:43AM -0400, Alan Stern wrote: On Sun, 26 Aug 2012, Dave Reisner wrote: On Fri, Aug 24, 2012 at 12:17:08PM -0400, Alan Stern wrote: I need some help with a problem. I'm currently using Fedora 16, but without a display manager. I log into a text-mode VT (usually tty1) and run startx manually. The display uses tty7 and works fine. But systemd isn't aware of it, or at least, isn't aware that my login session now owns tty7. For example, the devices labelled with the uaccess tag have their ACLs adjusted so that I can't use them in the graphical environment. (When I switch back to a text-mode VT they work fine.) I'm not sure who to blame for this: systemd, dbus, or myself. Still, it seems like this _ought_ to work okay. Can anybody help? Alan Stern You'll need to start X on the same VT that you logged in on. If it's tty1, then: startx -- vt01 That's a reasonable workaround, but it's not a real fix. Why isn't it a real fix? It's simply different semantics from consolekit. If you want this done automatically, it's trivial to write your own ~/.xserverrc which does the VT detection and passes it to X as an argument: https://gist.github.com/3489325 Fedora 16 uses ConsoleKit, and testing shows that ConsoleKit is aware of both the test-mode and X session whereas systemd isn't: That's unfortunate. I doubt anyone on this list cares about CK in any real way. logind is the way forward. [stern@iolanthe ~]$ ck-list-sessions Session1: unix-user = '2102' realname = 'Alan Stern' seat = 'Seat1' session-type = '' active = FALSE x11-display = '' x11-display-device = '' display-device = '/dev/tty1' remote-host-name = '' is-local = TRUE on-since = '2012-08-27T13:52:33.245828Z' login-session-id = '1' idle-since-hint = '2012-08-27T13:53:04.012294Z' Session2: unix-user = '2102' realname = 'Alan Stern' seat = 'Seat1' session-type = '' active = TRUE x11-display = ':0' x11-display-device = '/dev/tty7' display-device = '' remote-host-name = '' is-local = TRUE on-since = '2012-08-27T13:52:37.086051Z' login-session-id = '1' Presumably, this only works because you launch X with ck-launch-session and pam_ck_connector somewhere in your PAM login stack. I don't know exactly how CK works, but it's my understanding that logind requires a process running as root to register a new session (on the new tty) if it is to be authenticated for at_console privileges. [stern@iolanthe ~]$ systemd-loginctl list-sessions SESSIONUID USER SEAT 1 2102 sternseat0 1 sessions listed. [stern@iolanthe ~]$ systemd-loginctl show-session 1 Id=1 Name=stern Timestamp=Mon, 27 Aug 2012 09:52:32 -0400 TimestampMonotonic=100394935 ControlGroupPath=/user/stern/1 VTNr=1 TTY=tty1 Remote=no Service=login Leader=992 Audit=1 Type=tty Active=no KillProcesses=no IdleHint=yes IdleSinceHint=3 IdleSinceHintMonotonic=0 Evidently information is getting sent to (or by) ConsoleKit but not to systemd, or else the information does get sent to systemd and systemd ignores it. Either way, this is a bug (although I can't tell where). I can't speak for Lennart and Kay, but I'm pretty sure they'll tell you that this is working as intended. Now perhaps ConsoleKit is old hat and nobody cares about it any more. I haven't tried doing this under a more recent version of Fedora. Is there any reason to think it would work any better? Well, the startx behavior I showed you will continue to work. I'd suspect that a newer version of Fedora might not have consolekit at all. Alan Stern ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Bug in systemd? Running X without a display manager
On Mon, 27 Aug 2012, Dave Reisner wrote: You'll need to start X on the same VT that you logged in on. If it's tty1, then: startx -- vt01 That's a reasonable workaround, but it's not a real fix. Why isn't it a real fix? It's simply different semantics from consolekit. If you want this done automatically, it's trivial to write your own ~/.xserverrc which does the VT detection and passes it to X as an argument: https://gist.github.com/3489325 I meant that it shouldn't be necessary to tell X to run on the same tty as the original login session. X should be able to pick whichever tty it wants (or is told), and that information should get propagated to systemd. The lack of propagation is a bug, and telling X explicitly what tty to use doesn't fix it. Fedora 16 uses ConsoleKit, and testing shows that ConsoleKit is aware of both the test-mode and X session whereas systemd isn't: That's unfortunate. I doubt anyone on this list cares about CK in any real way. logind is the way forward. ... Presumably, this only works because you launch X with ck-launch-session and pam_ck_connector somewhere in your PAM login stack. I don't know Indeed: $ grep pam_ck_connector /etc/pam.d/* /etc/pam.d/login:-session optional pam_ck_connector.so And ps says: stern 1740 1723 0 10:36 tty1 00:00:00 xinit /etc/X11/xinit/xinitrc -- /usr/bin/X vt01 -auth /home/stern/.serverauth.1723 root 1741 1740 7 10:36 ?00:05:22 /usr/bin/X :0 vt01 -auth /home/stern/.serverauth.1723 stern 1746 1740 0 10:36 ?00:00:00 /usr/bin/ck-xinit-session /usr/bin/ssh-agent /home/stern/.Xclients exactly how CK works, but it's my understanding that logind requires a process running as root to register a new session (on the new tty) if it is to be authenticated for at_console privileges. Now perhaps ConsoleKit is old hat and nobody cares about it any more. I haven't tried doing this under a more recent version of Fedora. Is there any reason to think it would work any better? Well, the startx behavior I showed you will continue to work. I'd suspect that a newer version of Fedora might not have consolekit at all. Hmmm. Maybe the best thing to do is wait until I install a new version of Fedora (I'm waiting for the official release of 18) and then see what the story is. Thanks for your help, Alan Stern ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Bug in systemd? Running X without a display manager
'Twas brillig, and Alan Stern at 27/08/12 16:53 did gyre and gimble: On Mon, 27 Aug 2012, Dave Reisner wrote: You'll need to start X on the same VT that you logged in on. If it's tty1, then: startx -- vt01 That's a reasonable workaround, but it's not a real fix. Why isn't it a real fix? It's simply different semantics from consolekit. If you want this done automatically, it's trivial to write your own ~/.xserverrc which does the VT detection and passes it to X as an argument: https://gist.github.com/3489325 I meant that it shouldn't be necessary to tell X to run on the same tty as the original login session. X should be able to pick whichever tty it wants (or is told), and that information should get propagated to systemd. This has been discussed on this list a while back (I think started by me). It's not really as simple as that these days. In order to do things cleanly (and from what I understand the CK way was certainly far from clean), you really need to use some kind of login agent. Typically this would be the job of the DM, but as you are not using one, it's obviously not going to work. So in theory you need to spawn something that acts as a proper login agent, has a real PAM conversation and then starts X for you. That's the only real way to do the proper user registration (for the simply fact that it's not really possible to start a session from a session. The lack of propagation is a bug, and telling X explicitly what tty to use doesn't fix it. The primary problem is that logind doesn't know that your session is active. As you change vt the session you do have listed in loginctl becomes inactive and thus various ACLs are removed form you user. It was my understanding that startx in Fedora was going to be patched to work. I patched it in Mageia here: http://svnweb.mageia.org/packages/cauldron/xinit/current/SOURCES/xinit-1.3.2-use-current-vt.patch?revision=229253view=markup Fedora 16 uses ConsoleKit, and testing shows that ConsoleKit is aware of both the test-mode and X session whereas systemd isn't: That's unfortunate. I doubt anyone on this list cares about CK in any real way. logind is the way forward. ... Presumably, this only works because you launch X with ck-launch-session and pam_ck_connector somewhere in your PAM login stack. I don't know Indeed: $ grep pam_ck_connector /etc/pam.d/* /etc/pam.d/login:-session optional pam_ck_connector.so And ps says: stern 1740 1723 0 10:36 tty1 00:00:00 xinit /etc/X11/xinit/xinitrc -- /usr/bin/X vt01 -auth /home/stern/.serverauth.1723 root 1741 1740 7 10:36 ?00:05:22 /usr/bin/X :0 vt01 -auth /home/stern/.serverauth.1723 stern 1746 1740 0 10:36 ?00:00:00 /usr/bin/ck-xinit-session /usr/bin/ssh-agent /home/stern/.Xclients Yup, console-kit had two ways to start a session, via the pam connector or via the ck-launch*/ck-xinit* stuff. Sadly a consolekit session is really quite half-hearted and didn't really track user processes properly. With systemd's cgroup support user processes are properly tracked which gives a lot more control, but sadly it comes at the expense of a ck-launch*/ck-xinit replacement. This means you *have* to use PAM, which means that a text login session cannot spawn a 2nd session which, in turn, means the best way is to simply keep the current session active which means reusing the current VT for X. Looking forward a simple autologin system could get around this. e.g. gdm has autologin support. Say it was modified to take the autologin user as an argument. You could have a small setuid binary wrapper that started gdm for you and passes your user as the autologin user when it execs the main gdm process. This would mean all the proper PAM conversations happen as expected and everything should be fine. I only use gdm as an example here as it's got (AFAIUI) good PAM code. A standalone autologin system that does PAM well would be fine too (tho' I believe it's quite easy to write bad PAM code...) 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] Bug in systemd? Running X without a display manager
On Tue, 28 Aug 2012 00:32:47 +0100 Colin Guthrie gm...@colin.guthr.ie wrote: It's not really as simple as that these days. In order to do things cleanly (and from what I understand the CK way was certainly far from clean), you really need to use some kind of login agent. Typically this would be the job of the DM, but as you are not using one, it's obviously not going to work. So in theory you need to spawn something that acts as a proper login agent, has a real PAM conversation and then starts X for you. That's the only real way to do the proper user registration (for the simply fact that it's not really possible to start a session from a session. ... Looking forward a simple autologin system could get around this. e.g. gdm has autologin support. Say it was modified to take the autologin user as an argument. You could have a small setuid binary wrapper that started gdm for you and passes your user as the autologin user when it execs the main gdm process. This would mean all the proper PAM conversations happen as expected and everything should be fine. I only use gdm as an example here as it's got (AFAIUI) good PAM code. A standalone autologin system that does PAM well would be fine too (tho' I believe it's quite easy to write bad PAM code...) Just to be clear, there's nothing wrong with login establishing the PAM session and doing startx without changing vt from there, right? Wanted to ask, because it seem to me that gdm with autologin seem to be unnecessary if just startx works, and OP seemed to be logging into a text vt explicitly anyway, so I can assume gdm does something more (PAM-wise?) than login(1) does? -- Mike Kazantsev // fraggod.net signature.asc Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
