Re: [systemd-devel] How soon after login can I rely on systemd --user having reached sockets.target?
Lennart Poettering wrote on 27/10/14 18:11: On Thu, 23.10.14 17:26, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: order it after basic.target (which things are by default anyway)... My proposal now, (which is the same Damien's as I understood him): 1. pam_systemd should sync on default.target 2. by default default.target should just be an alias to basic.target. That way we have two things: a) as basic.target pulls in all sockets and busnames we know that everything that needs to be listened on is listened on by the time PAM succeeds b) if people really want they can change the default.target symlink to something else and thus add additional services into this, that may run after the sockets/busnames, but before PAM succeeds. Makes sense? Not to me. It still potentially delays user login a lot, because it conflates things which should be started by default with things which should be started before login completes. If I want to start a bunch of daemons whenever my systemd instance is running, I want to add them to default.target, that's what it is there for. I see a strong parallel with the system default.target: it specifies what should be launched on boot, but user logins are allowed much earlier. Maybe this should be made explicit and PAM should wait for a new user-login.target, which by default will simply have Wants=basic.target, but the user is free to add additional dependencies if they want to have more stuff running before they are allowed to log in. I see what you mean. But user- sounds like an unnecessary prefix, if we are already in user context, no? Maybe just login.target? Yeah this seems sensible to me. I certainly like it better than default.target It actually felt kinda weird using WantedBy=default.target seeing as this is typically a symlink under system-mode where we're much more used to using multi-user.target. Now that I've thought about it all, I'm not sure whether it is using WantedBy=default.target in user-mode that feels wrong, or NOT using WantedBy=default.target in system-mode that *should* feel wrong :p 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] How soon after login can I rely on systemd --user having reached sockets.target?
On Sun, 26.10.14 20:47, Damien Robert (damien.olivier.rob...@gmail.com) wrote: From Lennart Poettering, Fri 24 Oct 2014 at 01:09:56 (+0200) : So, I really would prefer if this logic wasn't just a hook, but actually the primary action of logging in graphically via a display manager. Ok, and login off would just be something like 'systemctl stop gnome.target'? Could be, yeah. On multiseat setups you could hence merge multiple seats into a single meta-session with the workspace spanning all of the seats if you keep logging in with the same user. I could imagine having several virtual machines that connects via ssh -X to the main computer to launch graphical sessions (so that there is no need to install it on the vms); in this case there would be a need to start the same target but with different displays. And the solution I outlined on my preceding mail using instances target templates work very well (and it does since a long time, I was very impressed when I tried it and it worked out of the box); but having 'hooks' on logind would help a bit. Well, the way I think remoting espcially with the advent of wayland should work is that when you cannot via VNC/Spice or similar, this new screen also gets added to the existing meta-session as another display. In this case these VNC/spice displays would simply show the same contents as any pre-existing sesion already though by default, instead of extending the virtual screen real estate... (and to turn this around: even in multi-head setups such a clone mode might make sense too: on each display you log into you could optionally just clone what you already see on the others...) Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How soon after login can I rely on systemd --user having reached sockets.target?
On Thu, 23.10.14 17:26, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: order it after basic.target (which things are by default anyway)... My proposal now, (which is the same Damien's as I understood him): 1. pam_systemd should sync on default.target 2. by default default.target should just be an alias to basic.target. That way we have two things: a) as basic.target pulls in all sockets and busnames we know that everything that needs to be listened on is listened on by the time PAM succeeds b) if people really want they can change the default.target symlink to something else and thus add additional services into this, that may run after the sockets/busnames, but before PAM succeeds. Makes sense? Not to me. It still potentially delays user login a lot, because it conflates things which should be started by default with things which should be started before login completes. If I want to start a bunch of daemons whenever my systemd instance is running, I want to add them to default.target, that's what it is there for. I see a strong parallel with the system default.target: it specifies what should be launched on boot, but user logins are allowed much earlier. Maybe this should be made explicit and PAM should wait for a new user-login.target, which by default will simply have Wants=basic.target, but the user is free to add additional dependencies if they want to have more stuff running before they are allowed to log in. I see what you mean. But user- sounds like an unnecessary prefix, if we are already in user context, no? Maybe just login.target? Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How soon after login can I rely on systemd --user having reached sockets.target?
From Lennart Poettering, Fri 24 Oct 2014 at 01:09:56 (+0200) : So, I really would prefer if this logic wasn't just a hook, but actually the primary action of logging in graphically via a display manager. Ok, and login off would just be something like 'systemctl stop gnome.target'? Note though that in the scheme I'd propose for GNOME we wouldn't support multiple parallel logins of the same user anymore. Instead, if you do this we'd add the seat you are logging into to your existing session. I sometime login from the same seat multiple times (to test my X settings). But I agree Xephyr would probably be better for this case. On multiseat setups you could hence merge multiple seats into a single meta-session with the workspace spanning all of the seats if you keep logging in with the same user. I could imagine having several virtual machines that connects via ssh -X to the main computer to launch graphical sessions (so that there is no need to install it on the vms); in this case there would be a need to start the same target but with different displays. And the solution I outlined on my preceding mail using instances target templates work very well (and it does since a long time, I was very impressed when I tried it and it worked out of the box); but having 'hooks' on logind would help a bit. But this is not really an important feature request for me, it was just an idea in passing. -- Damien Robert http://www.normalesup.org/~robert/pro ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How soon after login can I rely on systemd --user having reached sockets.target?
On Wed, 22.10.14 12:57, Damien Robert (damien.olivier.robert+gm...@gmail.com)
wrote:
Lennart Poettering wrote in message 20141020173828.GA4509@gardel-login:
They should probably adopt socket activation anyway, otherwise they'd
be quite annoying on multi-user systems if lingering is used.
I am brainstorming here, but would it make sense to add hooks to logind
when a session is started/closed (both system hooks and user hooks)?
For instance when I log into X, my .xprofile contains
systemctl --no-block --user start xsession@${DISPLAY}.target
to start my user services.
The intention here is that a new version of gnome-session (or
equivalent) would issue a command equivalent to this as its primary
job, and then just stay hanging until the X display dies.
So, I really would prefer if this logic wasn't just a hook, but
actually the primary action of logging in graphically via a display
manager.
Note though that in the scheme I'd propose for GNOME we wouldn't
support multiple parallel logins of the same user anymore. Instead, if
you do this we'd add the seat you are logging into to your existing
session. On multiseat setups you could hence merge multiple seats into
a single meta-session with the workspace spanning all of the seats if
you keep logging in with the same user.
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How soon after login can I rely on systemd --user having reached sockets.target?
On Thursday 23 October 2014 at 07:06:18, Mantas Mikulėnas wrote: On Oct 23, 2014 1:54 AM, Lennart Poettering lenn...@poettering.net wrote: On Wed, 22.10.14 12:44, Damien Robert ( damien.olivier.robert+gm...@gmail.com) wrote: [...] policykit really should get fixed there. it shouldn't try to do access control for individual sessions but for users on specific sessions. Wasn't this already fixed in polkit.git recently? Oh, if this indeed was, then... does it mean that the last significant blocker for widely using `systemd --user` has gone away? -- Ivan Shapovalov / intelfx / signature.asc Description: This is a digitally signed message part. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How soon after login can I rely on systemd --user having reached sockets.target?
From Mantas Mikulėnas, Thu 23 Oct 2014 at 07:06:18 (+0300) : Wasn't this already fixed in polkit.git recently? Yes indeed: commit a68f5dfd7662767b7b9822090b70bc5bd145c50c sessionmonitor-systemd: prepare for D-Bus user bus model In the D-Bus user bus model, all sessions of a user share the same D-Bus instance, a polkit requesting process might live outside the login session which registered the user's polkit agent. In case a polkit requesting process is not part of the user's login session, we ask systemd-logind for the the user's display session instead. https://bugs.freedesktop.org/show_bug.cgi?id=78905 Wonderfull! The future is bright for user session :) With PA's socket activation, since mpd already has socket activation, the only thing I am still missing is ssh-agent socket activation! -- Damien Robert ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How soon after login can I rely on systemd --user having reached sockets.target?
Zbigniew Jędrzejewski-Szmek wrote in message 20141019135812.gu29...@in.waw.pl: PAM creates sessions by calling into systemd's pam-module, which then uses CreateSession() (internal api!). This call does not return until the job of user@.service is done. `systemd --user` notifies READY=1 only after default.target is ready. Hm, this seems a bit excessive, because default.target can take a while. basic.target would seem more natural. But isn't using default.target more flexible than basic.target? When basic.target is activated I expect at least socket.target, timers.target and path.target to get activated too; whereas I could imagine an user wanting a completly empty user session [*], which could be done with an empty default.target [#]. [*] I don't use cron anymore, so I don't know if a cron session goes through systemd's pam module in my distribution's pam settings default, but I could imagine that if it were the case we would want a mostly empty user session in this case. [#] With DefaultDependencies=false Right now by default default.target is a symlink to basic.target. It seems natural that the user session starts default.target, like the system session does. Otherwise what would be the meaning of default.target? Something started by the DM when the user logs in rather than by pam? (Actually now that user sessions are getting more used, it would indeed be nice to standardize a name of a target to start when a graphical login is used!) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How soon after login can I rely on systemd --user having reached sockets.target?
On Thu, 23.10.14 08:09, Damien Robert (damien.olivier.robert+gm...@gmail.com) wrote: Zbigniew Jędrzejewski-Szmek wrote in message 20141019135812.gu29...@in.waw.pl: PAM creates sessions by calling into systemd's pam-module, which then uses CreateSession() (internal api!). This call does not return until the job of user@.service is done. `systemd --user` notifies READY=1 only after default.target is ready. Hm, this seems a bit excessive, because default.target can take a while. basic.target would seem more natural. But isn't using default.target more flexible than basic.target? When basic.target is activated I expect at least socket.target, timers.target and path.target to get activated too; whereas I could imagine an user wanting a completly empty user session [*], which could be done with an empty default.target [#]. basic.target includes sockets.target, busnames.target, timers.target and paths.target as well as sysinit.target. [*] I don't use cron anymore, so I don't know if a cron session goes through systemd's pam module in my distribution's pam settings default, but I could imagine that if it were the case we would want a mostly empty user session in this case. Yes, all user code really should go through PAM, so that security labels and resource limits can be set up properly. [#] With DefaultDependencies=false Right now by default default.target is a symlink to basic.target. It seems natural that the user session starts default.target, like the system session does. Otherwise what would be the meaning of default.target? Something started by the DM when the user logs in rather than by pam? (Actually now that user sessions are getting more used, it would indeed be nice to standardize a name of a target to start when a graphical login is used!) Regarding graphical stuff: the way I figured this should work is that all desktop environments would define their own gnome.target, kde.target, xfce.target and then some graphical.target symlink would point to the preferred version. These targets would then bring up averything that's necessary for the specific session type. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How soon after login can I rely on systemd --user having reached sockets.target?
From Lennart Poettering, Thu 23 Oct 2014 at 11:49:27 (+0200) : On Thu, 23.10.14 08:09, Damien Robert (damien.olivier.robert+gm...@gmail.com) wrote: But isn't using default.target more flexible than basic.target? When basic.target is activated I expect at least socket.target, timers.target and path.target to get activated too; whereas I could imagine an user wanting a completly empty user session [*], which could be done with an empty default.target [#]. basic.target includes sockets.target, busnames.target, timers.target and paths.target as well as sysinit.target. No, that's the system wide basic.target. The user basic.target only has sockets, timers and paths. But I was arguing that basic.target has a well defined meaning (basic system wide/user wide system initialisation), and we may want to allow default.target (in a user session) to be different from basic.target, even if they should be the same for most user cases. Yes, all user code really should go through PAM, so that security labels and resource limits can be set up properly. Yeah but do they need to go through pam_systemd.so also? Regarding graphical stuff: the way I figured this should work is that all desktop environments would define their own gnome.target, kde.target, xfce.target and then some graphical.target symlink would point to the preferred version. These targets would then bring up averything that's necessary for the specific session type. Ok, that looks nice. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How soon after login can I rely on systemd --user having reached sockets.target?
On Thu, 23.10.14 13:47, Damien Robert (damien.olivier.rob...@gmail.com) wrote: From Lennart Poettering, Thu 23 Oct 2014 at 11:49:27 (+0200) : On Thu, 23.10.14 08:09, Damien Robert (damien.olivier.robert+gm...@gmail.com) wrote: But isn't using default.target more flexible than basic.target? When basic.target is activated I expect at least socket.target, timers.target and path.target to get activated too; whereas I could imagine an user wanting a completly empty user session [*], which could be done with an empty default.target [#]. basic.target includes sockets.target, busnames.target, timers.target and paths.target as well as sysinit.target. No, that's the system wide basic.target. The user basic.target only has sockets, timers and paths. Oh indeed, there is not sysinit.target. It sounded so wron in a user context... I figure if people want to stick something in there they can just as well use basic.target here... But I was arguing that basic.target has a well defined meaning (basic system wide/user wide system initialisation), and we may want to allow default.target (in a user session) to be different from basic.target, even if they should be the same for most user cases. sure, that sounds like something to support. i'd still say though that pam_systemd should only wait for basic.target, since that's where all the listening bits should be established, and everything else can be started later. Yes, all user code really should go through PAM, so that security labels and resource limits can be set up properly. Yeah but do they need to go through pam_systemd.so also? Yes. All user code should go through pam_systemd.so too, so that it gets moved into the user's slice. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How soon after login can I rely on systemd --user having reached sockets.target?
From Lennart Poettering, Thu 23 Oct 2014 at 14:01:22 (+0200) : Oh indeed, there is not sysinit.target. It sounded so wron in a user context... I figure if people want to stick something in there they can just as well use basic.target here... But I was arguing that basic.target has a well defined meaning (basic system wide/user wide system initialisation), and we may want to allow default.target (in a user session) to be different from basic.target, even if they should be the same for most user cases. sure, that sounds like something to support. i'd still say though that pam_systemd should only wait for basic.target, since that's where all the listening bits should be established, and everything else can be started later. Yes but maybe the user wants something even more minimal than basic.target. For instance if I run under a cron, maybe I don't want my timers to be launched. I was thinking of using a default.target with DefaultDependencies=false, so it does not even pull basic.target; not something that launch more things than basic.target. -- Damien Robert http://www.normalesup.org/~robert/pro ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How soon after login can I rely on systemd --user having reached sockets.target?
On Thu, 23.10.14 16:06, Damien Robert (damien.olivier.rob...@gmail.com) wrote: From Lennart Poettering, Thu 23 Oct 2014 at 14:01:22 (+0200) : Oh indeed, there is not sysinit.target. It sounded so wron in a user context... I figure if people want to stick something in there they can just as well use basic.target here... But I was arguing that basic.target has a well defined meaning (basic system wide/user wide system initialisation), and we may want to allow default.target (in a user session) to be different from basic.target, even if they should be the same for most user cases. sure, that sounds like something to support. i'd still say though that pam_systemd should only wait for basic.target, since that's where all the listening bits should be established, and everything else can be started later. Yes but maybe the user wants something even more minimal than basic.target. For instance if I run under a cron, maybe I don't want my timers to be launched. I was thinking of using a default.target with DefaultDependencies=false, so it does not even pull basic.target; not something that launch more things than basic.target. Hmm, maybe you do have a point here and default.target should be what we sync on after all. It would by default point to basic.target, but if people really want to redfine things they could do so. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How soon after login can I rely on systemd --user having reached sockets.target?
On Thu, 23.10.14 17:52, Mantas Mikulėnas (graw...@gmail.com) wrote: On Oct 23, 2014 5:48 PM, Lennart Poettering lenn...@poettering.net wrote: On Thu, 23.10.14 16:06, Damien Robert (damien.olivier.rob...@gmail.com) wrote: From Lennart Poettering, Thu 23 Oct 2014 at 14:01:22 (+0200) : Oh indeed, there is not sysinit.target. It sounded so wron in a user context... I figure if people want to stick something in there they can just as well use basic.target here... But I was arguing that basic.target has a well defined meaning (basic system wide/user wide system initialisation), and we may want to allow default.target (in a user session) to be different from basic.target, even if they should be the same for most user cases. sure, that sounds like something to support. i'd still say though that pam_systemd should only wait for basic.target, since that's where all the listening bits should be established, and everything else can be started later. Yes but maybe the user wants something even more minimal than basic.target. For instance if I run under a cron, maybe I don't want my timers to be launched. I was thinking of using a default.target with DefaultDependencies=false, so it does not even pull basic.target; not something that launch more things than basic.target. Hmm, maybe you do have a point here and default.target should be what we sync on after all. It would by default point to basic.target, but if people really want to redfine things they could do so. But wouldn't that also redefine the services one wants to start automatically? How would one choose the unit to start separately from the unit to sync to? order it after basic.target (which things are by default anyway)... My proposal now, (which is the same Damien's as I understood him): 1. pam_systemd should sync on default.target 2. by default default.target should just be an alias to basic.target. That way we have two things: a) as basic.target pulls in all sockets and busnames we know that everything that needs to be listened on is listened on by the time PAM succeeds b) if people really want they can change the default.target symlink to something else and thus add additional services into this, that may run after the sockets/busnames, but before PAM succeeds. Makes sense? Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How soon after login can I rely on systemd --user having reached sockets.target?
On Thu, Oct 23, 2014 at 04:59:45PM +0200, Lennart Poettering wrote: On Thu, 23.10.14 17:52, Mantas Mikulėnas (graw...@gmail.com) wrote: On Oct 23, 2014 5:48 PM, Lennart Poettering lenn...@poettering.net wrote: On Thu, 23.10.14 16:06, Damien Robert (damien.olivier.rob...@gmail.com) wrote: From Lennart Poettering, Thu 23 Oct 2014 at 14:01:22 (+0200) : Oh indeed, there is not sysinit.target. It sounded so wron in a user context... I figure if people want to stick something in there they can just as well use basic.target here... But I was arguing that basic.target has a well defined meaning (basic system wide/user wide system initialisation), and we may want to allow default.target (in a user session) to be different from basic.target, even if they should be the same for most user cases. sure, that sounds like something to support. i'd still say though that pam_systemd should only wait for basic.target, since that's where all the listening bits should be established, and everything else can be started later. Yes but maybe the user wants something even more minimal than basic.target. For instance if I run under a cron, maybe I don't want my timers to be launched. I was thinking of using a default.target with DefaultDependencies=false, so it does not even pull basic.target; not something that launch more things than basic.target. Hmm, maybe you do have a point here and default.target should be what we sync on after all. It would by default point to basic.target, but if people really want to redfine things they could do so. But wouldn't that also redefine the services one wants to start automatically? How would one choose the unit to start separately from the unit to sync to? order it after basic.target (which things are by default anyway)... My proposal now, (which is the same Damien's as I understood him): 1. pam_systemd should sync on default.target 2. by default default.target should just be an alias to basic.target. That way we have two things: a) as basic.target pulls in all sockets and busnames we know that everything that needs to be listened on is listened on by the time PAM succeeds b) if people really want they can change the default.target symlink to something else and thus add additional services into this, that may run after the sockets/busnames, but before PAM succeeds. Makes sense? Not to me. It still potentially delays user login a lot, because it conflates things which should be started by default with things which should be started before login completes. If I want to start a bunch of daemons whenever my systemd instance is running, I want to add them to default.target, that's what it is there for. I see a strong parallel with the system default.target: it specifies what should be launched on boot, but user logins are allowed much earlier. Maybe this should be made explicit and PAM should wait for a new user-login.target, which by default will simply have Wants=basic.target, but the user is free to add additional dependencies if they want to have more stuff running before they are allowed to log in. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How soon after login can I rely on systemd --user having reached sockets.target?
From Zbigniew Jędrzejewski-Szmek, Thu 23 Oct 2014 at 17:26:57 (+0200) : order it after basic.target (which things are by default anyway)... My proposal now, (which is the same Damien's as I understood him): 1. pam_systemd should sync on default.target 2. by default default.target should just be an alias to basic.target. That way we have two things: a) as basic.target pulls in all sockets and busnames we know that everything that needs to be listened on is listened on by the time PAM succeeds b) if people really want they can change the default.target symlink to something else and thus add additional services into this, that may run after the sockets/busnames, but before PAM succeeds. I was more thinking of having a default.target that is even smaller than basic.target, but I forgot that we may want pam_systemd to start a session different from the synced session before login, so this also conflates two different use of default.target. Maybe this should be made explicit and PAM should wait for a new user-login.target, which by default will simply have Wants=basic.target, but the user is free to add additional dependencies if they want to have more stuff running before they are allowed to log in. Yes, this would be ideal. This way - pam_systemd starts default.target - the login returns when user-login.target is reached. [the question is what happen is default.target does not pull user-login.target; and I would argue that the login should return immediatly rather than wait for default.target] The important thing for me is that I may want default.target to be even smaller than basic.target; and I thought that syncing on basic.target would necessarily means launching it at each session, but maybe the implementation could be carefull about that. So in a scheme where - pam_systemd starts default.target - the login returns when basic.target is reached OR returns immediatly if basic.target is not pulled in I would be equally happy. The proposal by Zbigniew has my preference because it is more flexible, and does not conflates these three different things: - when to return for the login (user-login.target) - what services we want to launch by default (default.target) - when standard basic setup is considered done (basic.target) And unlike the system case where I always want default.target to requires basic.target, in the user case I may want default.target to be smaller than basic.target (for cron jobs I don't want my timers to launch); but still requires basic.target when I launch say xfce.target. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How soon after login can I rely on systemd --user having reached sockets.target?
Colin Guthrie wrote in message m1rf8b$ojg$1...@ger.gmane.org: I want to rely on systemd --user to handle PulseAudio's activation (ditching the built in stuff) and but I'm worried that e.g. GNOME or KDE might start up their own session stuff and spawn some PA consuming process before systemd --user has reached it's sockets.target and is thus ready and listening on PA's native socket. Interesting, does PA now support socket activation? Mine (pulseaudio 5.0) does not seem to support it. Doesn't seem to be a problem on my machine here (it's working really nicely actually!) but figured I should ask here too. I have been using systemd user sessions for a long time, and it works really well, except for this policykit bug: https://bugs.freedesktop.org/show_bug.cgi?id=67728 For instance since I start dbus under the user session, the dbus activated services also run inside it: CGroup: /user.slice/user-1000.slice/user@1000.service ├─615 /usr/lib/systemd/systemd --user ├─616 (sd-pam) ├─dbus.service │ ├─ 702 /usr/bin/dbus-daemon --session --address=systemd: --nofork │ ├─ 835 /usr/lib/gvfs/gvfs-udisks2-volume-monitor So udisks2 fails to mount my usb keys because it is not under an active session (since it is not launche from my active session) so it gets denied by policykit. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How soon after login can I rely on systemd --user having reached sockets.target?
Lennart Poettering wrote in message 20141020173828.GA4509@gardel-login:
They should probably adopt socket activation anyway, otherwise they'd
be quite annoying on multi-user systems if lingering is used.
I am brainstorming here, but would it make sense to add hooks to logind
when a session is started/closed (both system hooks and user hooks)?
For instance when I log into X, my .xprofile contains
systemctl --no-block --user start xsession@${DISPLAY}.target
to start my user services.
I need to make sure that everyway I have to log into X (with a *DM, with
startx, with xinit) I somehow source .xprofile.
Stopping the started services also involve some contorsion. When I quit X
most of the services started by xsession@$DISPLAY fails because X is no
longer available, and I don't want systemd to try to restart them in this
case. So I need to stop these services whenever X exits.
So inside xsession@.target, I launch xwatch@.service:
[Unit]
Description=Watch for X on display %I
BindsTo=xsession@.target
[Service]
Environment=DISPLAY=%I
SyslogIdentifier=xwatch@%I
ExecStart=/bin/sh -c 'exec %h/mine/script/services/xwatch %I'
Nice=19
[Install]
WantedBy=xsession@.target
with $ cat ~/script/services/xwatch
#!/bin/sh
xprop -spy -root XFree86_VT
systemctl --user stop xsession@$1.target
So whenever my X session stops, xwatch will stop xsession@$DISPLAY.target,
and thus stop all services files that I configured to be PartOf
xsession@.target. For instance xcompmgr@.service:
[Unit]
Description=xcompmgr on display %I
PartOf=xsession@.target
ConditionFileIsExecutable=/usr/bin/xcompmgr
[Service]
Environment=DISPLAY=%I
ExecStart=/usr/bin/xcompmgr
Restart=on-failure
RestartSec=3
StandardOutput=null
[Install]
WantedBy=xsession@.target
Also=xwatch@.service
It works really well, I can even log onto different X sessions and have the
corresponding services launched into the different $DISPLAY, but having
some close hooks in logind would help getting rid of xwatch.service.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How soon after login can I rely on systemd --user having reached sockets.target?
On Wed, 22.10.14 12:44, Damien Robert (damien.olivier.robert+gm...@gmail.com) wrote: Colin Guthrie wrote in message m1rf8b$ojg$1...@ger.gmane.org: I want to rely on systemd --user to handle PulseAudio's activation (ditching the built in stuff) and but I'm worried that e.g. GNOME or KDE might start up their own session stuff and spawn some PA consuming process before systemd --user has reached it's sockets.target and is thus ready and listening on PA's native socket. Interesting, does PA now support socket activation? Mine (pulseaudio 5.0) does not seem to support it. Colin recently posted the patches for this on the PA ML. Doesn't seem to be a problem on my machine here (it's working really nicely actually!) but figured I should ask here too. I have been using systemd user sessions for a long time, and it works really well, except for this policykit bug: https://bugs.freedesktop.org/show_bug.cgi?id=67728 For instance since I start dbus under the user session, the dbus activated services also run inside it: CGroup: /user.slice/user-1000.slice/user@1000.service ├─615 /usr/lib/systemd/systemd --user ├─616 (sd-pam) ├─dbus.service │ ├─ 702 /usr/bin/dbus-daemon --session --address=systemd: --nofork │ ├─ 835 /usr/lib/gvfs/gvfs-udisks2-volume-monitor So udisks2 fails to mount my usb keys because it is not under an active session (since it is not launche from my active session) so it gets denied by policykit. policykit really should get fixed there. it shouldn't try to do access control for individual sessions but for users on specific sessions. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How soon after login can I rely on systemd --user having reached sockets.target?
On Oct 23, 2014 1:54 AM, Lennart Poettering lenn...@poettering.net wrote: On Wed, 22.10.14 12:44, Damien Robert ( damien.olivier.robert+gm...@gmail.com) wrote: Colin Guthrie wrote in message m1rf8b$ojg$1...@ger.gmane.org: I want to rely on systemd --user to handle PulseAudio's activation (ditching the built in stuff) and but I'm worried that e.g. GNOME or KDE might start up their own session stuff and spawn some PA consuming process before systemd --user has reached it's sockets.target and is thus ready and listening on PA's native socket. Interesting, does PA now support socket activation? Mine (pulseaudio 5.0) does not seem to support it. Colin recently posted the patches for this on the PA ML. Doesn't seem to be a problem on my machine here (it's working really nicely actually!) but figured I should ask here too. I have been using systemd user sessions for a long time, and it works really well, except for this policykit bug: https://bugs.freedesktop.org/show_bug.cgi?id=67728 For instance since I start dbus under the user session, the dbus activated services also run inside it: CGroup: /user.slice/user-1000.slice/user@1000.service ├─615 /usr/lib/systemd/systemd --user ├─616 (sd-pam) ├─dbus.service │ ├─ 702 /usr/bin/dbus-daemon --session --address=systemd: --nofork │ ├─ 835 /usr/lib/gvfs/gvfs-udisks2-volume-monitor So udisks2 fails to mount my usb keys because it is not under an active session (since it is not launche from my active session) so it gets denied by policykit. policykit really should get fixed there. it shouldn't try to do access control for individual sessions but for users on specific sessions. Wasn't this already fixed in polkit.git recently? -- Mantas Mikulėnas ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How soon after login can I rely on systemd --user having reached sockets.target?
Hi On Sun, Oct 19, 2014 at 3:58 PM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: On Sun, Oct 19, 2014 at 12:43:59PM +0200, Colin Guthrie wrote: David Herrmann wrote on 19/10/14 12:05: Hi On Fri, Oct 17, 2014 at 6:14 PM, Colin Guthrie gm...@colin.guthr.ie wrote: Hi, How soon after login can I rely on systemd --user having reached sockets.target? This feels a bit like a you shouldn't rely on that point in time... type answer is warrented, and when e.g. GNOME or KDE sessions fully use systemd to bring themselves up it won't be an issue, but right now, systemd --user is started by (I think) PAM. I want to rely on systemd --user to handle PulseAudio's activation (ditching the built in stuff) and but I'm worried that e.g. GNOME or KDE might start up their own session stuff and spawn some PA consuming process before systemd --user has reached it's sockets.target and is thus ready and listening on PA's native socket. Doesn't seem to be a problem on my machine here (it's working really nicely actually!) but figured I should ask here too. Ordering of user units is (see /usr/lib/systemd/user/): default.target after basic.target after sockets.target PAM creates sessions by calling into systemd's pam-module, which then uses CreateSession() (internal api!). This call does not return until the job of user@.service is done. `systemd --user` notifies READY=1 only after default.target is ready. Hm, this seems a bit excessive, because default.target can take a while. basic.target would seem more natural. No idea what the semantics here are. I mean the important fact is that we block on _some_ target so you can order stuff before the PAM call returns. Which target this is, I don't really care. But I don't think we ever defined how the semantics for user-sessions are, anyway. Btw., manager_check_finished() doesn't explicitly wait for default.target, but instead waits for all jobs to be done. Not sure why.. Anyway, this means any dynamically scheduled jobs will also contribute to this delay. Thanks David ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How soon after login can I rely on systemd --user having reached sockets.target?
On Mon, Oct 20, 2014 at 1:02 PM, David Herrmann dh.herrm...@gmail.com wrote: Btw., manager_check_finished() doesn't explicitly wait for default.target, but instead waits for all jobs to be done. Not sure why.. Because default.target can be reached long before all jobs that are part of transaction finish. Do not forget that Wants != After. Anyway, this means any dynamically scheduled jobs will also contribute to this delay. OTOH it means that if your service has systemctl start other.service, other.service will contribute. I wonder - does it wait for *any* job or only for those started as part of initial transaction? Arguably, the latter would be the right semantic here, not? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How soon after login can I rely on systemd --user having reached sockets.target?
On Mon, Oct 20, 2014 at 02:16:30PM +0400, Andrei Borzenkov wrote: On Mon, Oct 20, 2014 at 1:02 PM, David Herrmann dh.herrm...@gmail.com wrote: Btw., manager_check_finished() doesn't explicitly wait for default.target, but instead waits for all jobs to be done. Not sure why.. Because default.target can be reached long before all jobs that are part of transaction finish. Do not forget that Wants != After. It's confusing, but being Wanted by a target automatically adds a Before dependency. Anyway, this means any dynamically scheduled jobs will also contribute to this delay. OTOH it means that if your service has systemctl start other.service, other.service will contribute. I wonder - does it wait for *any* job or only for those started as part of initial transaction? Arguably, the latter would be the right semantic here, not? I guess that it didn't matter too much so far, given that an empty user session starts in tens of milliseconds. But not it's starting to matter and we should define something sane here. Allowing the initial transaction to complete is not good, becuase if one adds a job like fetch all my mail, preload the cache, or anything else which is perfectly reasonable but could take unbounded time, the user will be blocked out. default.target is better, but still to much I think. We need the equivalent of systemd-user-sessions.service or basic.target, that would mean basic user infrastracture is in place and a shell or a graphical env can be launched, user sockets are open, even if the services are not fully there yet. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How soon after login can I rely on systemd --user having reached sockets.target?
On Mon, Oct 20, 2014 at 4:47 PM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: On Mon, Oct 20, 2014 at 02:16:30PM +0400, Andrei Borzenkov wrote: On Mon, Oct 20, 2014 at 1:02 PM, David Herrmann dh.herrm...@gmail.com wrote: Btw., manager_check_finished() doesn't explicitly wait for default.target, but instead waits for all jobs to be done. Not sure why.. Because default.target can be reached long before all jobs that are part of transaction finish. Do not forget that Wants != After. It's confusing, but being Wanted by a target automatically adds a Before dependency. But not every unit is directly WantedBy default.target, right? default.target Wants A.service where A.service Wants B.service. Now B.service is pretty much on free run, not? Anyway, this means any dynamically scheduled jobs will also contribute to this delay. OTOH it means that if your service has systemctl start other.service, other.service will contribute. I wonder - does it wait for *any* job or only for those started as part of initial transaction? Arguably, the latter would be the right semantic here, not? I guess that it didn't matter too much so far, given that an empty user session starts in tens of milliseconds. But not it's starting to matter and we should define something sane here. I'm mostly concerned about system boot here to be honest ... the old recurring question - how can we know that boot is complete. Allowing the initial transaction to complete is not good, becuase if one adds a job like fetch all my mail, preload the cache, or anything else which is perfectly reasonable but could take unbounded time, the user will be blocked out. default.target is better, but still to much I think. We need the equivalent of systemd-user-sessions.service or basic.target, that would mean basic user infrastracture is in place and a shell or a graphical env can be launched, user sockets are open, even if the services are not fully there yet. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How soon after login can I rely on systemd --user having reached sockets.target?
On Mon, Oct 20, 2014 at 05:01:14PM +0400, Andrei Borzenkov wrote: On Mon, Oct 20, 2014 at 4:47 PM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: On Mon, Oct 20, 2014 at 02:16:30PM +0400, Andrei Borzenkov wrote: On Mon, Oct 20, 2014 at 1:02 PM, David Herrmann dh.herrm...@gmail.com wrote: Btw., manager_check_finished() doesn't explicitly wait for default.target, but instead waits for all jobs to be done. Not sure why.. Because default.target can be reached long before all jobs that are part of transaction finish. Do not forget that Wants != After. It's confusing, but being Wanted by a target automatically adds a Before dependency. But not every unit is directly WantedBy default.target, right? default.target Wants A.service where A.service Wants B.service. Now B.service is pretty much on free run, not? A.service will also have After=B quite often. Yes, it is true that not everything has a temporaral dependency, but 'systemctl list-dependencies --after default.target' gives a pretty dense tree. Anyway, this means any dynamically scheduled jobs will also contribute to this delay. OTOH it means that if your service has systemctl start other.service, other.service will contribute. I wonder - does it wait for *any* job or only for those started as part of initial transaction? Arguably, the latter would be the right semantic here, not? I guess that it didn't matter too much so far, given that an empty user session starts in tens of milliseconds. But not it's starting to matter and we should define something sane here. I'm mostly concerned about system boot here to be honest ... the old recurring question - how can we know that boot is complete. There's no real point where the boot is complete. For example, let's say that you start some sync job at every boot that can take a couple of hours. Who cares if this jobs is done or not, and whether it is part of default.target? The imporant thing is that the system as a whole is in a well defined state. The watchdogs are active and if something hangs then it will be detected with timeouts and dependencies, and handled appropriately. A single target for the whole system is too coarse and not dynamic enough. Allowing the initial transaction to complete is not good, becuase if one adds a job like fetch all my mail, preload the cache, or anything else which is perfectly reasonable but could take unbounded time, the user will be blocked out. default.target is better, but still to much I think. We need the equivalent of systemd-user-sessions.service or basic.target, that would mean basic user infrastracture is in place and a shell or a graphical env can be launched, user sockets are open, even if the services are not fully there yet. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How soon after login can I rely on systemd --user having reached sockets.target?
On Sun, 19.10.14 15:58, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: PAM creates sessions by calling into systemd's pam-module, which then uses CreateSession() (internal api!). This call does not return until the job of user@.service is done. `systemd --user` notifies READY=1 only after default.target is ready. Hm, this seems a bit excessive, because default.target can take a while. basic.target would seem more natural. Excessive? Why would default.target take so long? Note that this is not supposed to pull up a full GNOME session or so. In most cases default.target would be very little more than basic.target... That said, I am not really opposed to changing this to basic.target. The important thing I guess is that after login all services are connectable, hence socket.target and busnames.target should have been reached at least, which basic.target delivers as much as default.target does... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How soon after login can I rely on systemd --user having reached sockets.target?
On Sun, 19.10.14 12:05, David Herrmann (dh.herrm...@gmail.com) wrote: Hi On Fri, Oct 17, 2014 at 6:14 PM, Colin Guthrie gm...@colin.guthr.ie wrote: Hi, How soon after login can I rely on systemd --user having reached sockets.target? This feels a bit like a you shouldn't rely on that point in time... type answer is warrented, and when e.g. GNOME or KDE sessions fully use systemd to bring themselves up it won't be an issue, but right now, systemd --user is started by (I think) PAM. I want to rely on systemd --user to handle PulseAudio's activation (ditching the built in stuff) and but I'm worried that e.g. GNOME or KDE might start up their own session stuff and spawn some PA consuming process before systemd --user has reached it's sockets.target and is thus ready and listening on PA's native socket. Doesn't seem to be a problem on my machine here (it's working really nicely actually!) but figured I should ask here too. Ordering of user units is (see /usr/lib/systemd/user/): default.target after basic.target after sockets.target PAM creates sessions by calling into systemd's pam-module, which then uses CreateSession() (internal api!). This call does not return until the job of user@.service is done. `systemd --user` notifies READY=1 only after default.target is ready. Long story short: The PAM module blocks until the user-manager is ready. Therefore, sockets.target is loaded and ready. (I'm no expert in sd job handling, so maybe Lennart can confirm this) I hereby confirm this. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How soon after login can I rely on systemd --user having reached sockets.target?
On Mon, 20.10.14 11:02, David Herrmann (dh.herrm...@gmail.com) wrote: I want to rely on systemd --user to handle PulseAudio's activation (ditching the built in stuff) and but I'm worried that e.g. GNOME or KDE might start up their own session stuff and spawn some PA consuming process before systemd --user has reached it's sockets.target and is thus ready and listening on PA's native socket. Doesn't seem to be a problem on my machine here (it's working really nicely actually!) but figured I should ask here too. Ordering of user units is (see /usr/lib/systemd/user/): default.target after basic.target after sockets.target PAM creates sessions by calling into systemd's pam-module, which then uses CreateSession() (internal api!). This call does not return until the job of user@.service is done. `systemd --user` notifies READY=1 only after default.target is ready. Hm, this seems a bit excessive, because default.target can take a while. basic.target would seem more natural. No idea what the semantics here are. I mean the important fact is that we block on _some_ target so you can order stuff before the PAM call returns. Which target this is, I don't really care. But I don't think we ever defined how the semantics for user-sessions are, anyway. Btw., manager_check_finished() doesn't explicitly wait for default.target, but instead waits for all jobs to be done. Not sure why.. Anyway, this means any dynamically scheduled jobs will also contribute to this delay. Hmm, this actually appears broken the way it currently is implemented... We probably should really move sd_notify() earlier than just becoming idle. Long running cron-like jobs might really break things here. I figure we should go for Zbigniew's suggestion to only wait for basic.target. Zbigniew? Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How soon after login can I rely on systemd --user having reached sockets.target?
On Mon, Oct 20, 2014 at 7:59 PM, Lennart Poettering lenn...@poettering.net wrote: On Sun, 19.10.14 15:58, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: PAM creates sessions by calling into systemd's pam-module, which then uses CreateSession() (internal api!). This call does not return until the job of user@.service is done. `systemd --user` notifies READY=1 only after default.target is ready. Hm, this seems a bit excessive, because default.target can take a while. basic.target would seem more natural. Excessive? Why would default.target take so long? Note that this is not supposed to pull up a full GNOME session or so. In most cases default.target would be very little more than basic.target... That said, I am not really opposed to changing this to basic.target. The important thing I guess is that after login all services are connectable, hence socket.target and busnames.target should have been reached at least, which basic.target delivers as much as default.target does... Personal user services (dropbox, krenew, mpd...)? -- Mantas Mikulėnas graw...@gmail.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How soon after login can I rely on systemd --user having reached sockets.target?
On Mon, 20.10.14 20:36, Mantas Mikulėnas (graw...@gmail.com) wrote: On Mon, Oct 20, 2014 at 7:59 PM, Lennart Poettering lenn...@poettering.net wrote: On Sun, 19.10.14 15:58, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: PAM creates sessions by calling into systemd's pam-module, which then uses CreateSession() (internal api!). This call does not return until the job of user@.service is done. `systemd --user` notifies READY=1 only after default.target is ready. Hm, this seems a bit excessive, because default.target can take a while. basic.target would seem more natural. Excessive? Why would default.target take so long? Note that this is not supposed to pull up a full GNOME session or so. In most cases default.target would be very little more than basic.target... That said, I am not really opposed to changing this to basic.target. The important thing I guess is that after login all services are connectable, hence socket.target and busnames.target should have been reached at least, which basic.target delivers as much as default.target does... Personal user services (dropbox, krenew, mpd...)? They should probably adopt socket activation anyway, otherwise they'd be quite annoying on multi-user systems if lingering is used. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How soon after login can I rely on systemd --user having reached sockets.target?
On Mon, Oct 20, 2014 at 07:07:05PM +0200, Lennart Poettering wrote: On Mon, 20.10.14 11:02, David Herrmann (dh.herrm...@gmail.com) wrote: I want to rely on systemd --user to handle PulseAudio's activation (ditching the built in stuff) and but I'm worried that e.g. GNOME or KDE might start up their own session stuff and spawn some PA consuming process before systemd --user has reached it's sockets.target and is thus ready and listening on PA's native socket. Doesn't seem to be a problem on my machine here (it's working really nicely actually!) but figured I should ask here too. Ordering of user units is (see /usr/lib/systemd/user/): default.target after basic.target after sockets.target PAM creates sessions by calling into systemd's pam-module, which then uses CreateSession() (internal api!). This call does not return until the job of user@.service is done. `systemd --user` notifies READY=1 only after default.target is ready. Hm, this seems a bit excessive, because default.target can take a while. basic.target would seem more natural. No idea what the semantics here are. I mean the important fact is that we block on _some_ target so you can order stuff before the PAM call returns. Which target this is, I don't really care. But I don't think we ever defined how the semantics for user-sessions are, anyway. Btw., manager_check_finished() doesn't explicitly wait for default.target, but instead waits for all jobs to be done. Not sure why.. Anyway, this means any dynamically scheduled jobs will also contribute to this delay. Hmm, this actually appears broken the way it currently is implemented... We probably should really move sd_notify() earlier than just becoming idle. Long running cron-like jobs might really break things here. I figure we should go for Zbigniew's suggestion to only wait for basic.target. Zbigniew? Yeah. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How soon after login can I rely on systemd --user having reached sockets.target?
Hi On Fri, Oct 17, 2014 at 6:14 PM, Colin Guthrie gm...@colin.guthr.ie wrote: Hi, How soon after login can I rely on systemd --user having reached sockets.target? This feels a bit like a you shouldn't rely on that point in time... type answer is warrented, and when e.g. GNOME or KDE sessions fully use systemd to bring themselves up it won't be an issue, but right now, systemd --user is started by (I think) PAM. I want to rely on systemd --user to handle PulseAudio's activation (ditching the built in stuff) and but I'm worried that e.g. GNOME or KDE might start up their own session stuff and spawn some PA consuming process before systemd --user has reached it's sockets.target and is thus ready and listening on PA's native socket. Doesn't seem to be a problem on my machine here (it's working really nicely actually!) but figured I should ask here too. Ordering of user units is (see /usr/lib/systemd/user/): default.target after basic.target after sockets.target PAM creates sessions by calling into systemd's pam-module, which then uses CreateSession() (internal api!). This call does not return until the job of user@.service is done. `systemd --user` notifies READY=1 only after default.target is ready. Long story short: The PAM module blocks until the user-manager is ready. Therefore, sockets.target is loaded and ready. (I'm no expert in sd job handling, so maybe Lennart can confirm this) Thanks David ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How soon after login can I rely on systemd --user having reached sockets.target?
David Herrmann wrote on 19/10/14 12:05: Hi On Fri, Oct 17, 2014 at 6:14 PM, Colin Guthrie gm...@colin.guthr.ie wrote: Hi, How soon after login can I rely on systemd --user having reached sockets.target? This feels a bit like a you shouldn't rely on that point in time... type answer is warrented, and when e.g. GNOME or KDE sessions fully use systemd to bring themselves up it won't be an issue, but right now, systemd --user is started by (I think) PAM. I want to rely on systemd --user to handle PulseAudio's activation (ditching the built in stuff) and but I'm worried that e.g. GNOME or KDE might start up their own session stuff and spawn some PA consuming process before systemd --user has reached it's sockets.target and is thus ready and listening on PA's native socket. Doesn't seem to be a problem on my machine here (it's working really nicely actually!) but figured I should ask here too. Ordering of user units is (see /usr/lib/systemd/user/): default.target after basic.target after sockets.target PAM creates sessions by calling into systemd's pam-module, which then uses CreateSession() (internal api!). This call does not return until the job of user@.service is done. `systemd --user` notifies READY=1 only after default.target is ready. Long story short: The PAM module blocks until the user-manager is ready. Therefore, sockets.target is loaded and ready. (I'm no expert in sd job handling, so maybe Lennart can confirm this) Thanks for the clarification. This is pretty much what Lennart thought when I quizzed him a couple nights ago, but said he'd double check. It sound like this is indeed the case. Nice :) 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] How soon after login can I rely on systemd --user having reached sockets.target?
On Sun, Oct 19, 2014 at 12:43:59PM +0200, Colin Guthrie wrote: David Herrmann wrote on 19/10/14 12:05: Hi On Fri, Oct 17, 2014 at 6:14 PM, Colin Guthrie gm...@colin.guthr.ie wrote: Hi, How soon after login can I rely on systemd --user having reached sockets.target? This feels a bit like a you shouldn't rely on that point in time... type answer is warrented, and when e.g. GNOME or KDE sessions fully use systemd to bring themselves up it won't be an issue, but right now, systemd --user is started by (I think) PAM. I want to rely on systemd --user to handle PulseAudio's activation (ditching the built in stuff) and but I'm worried that e.g. GNOME or KDE might start up their own session stuff and spawn some PA consuming process before systemd --user has reached it's sockets.target and is thus ready and listening on PA's native socket. Doesn't seem to be a problem on my machine here (it's working really nicely actually!) but figured I should ask here too. Ordering of user units is (see /usr/lib/systemd/user/): default.target after basic.target after sockets.target PAM creates sessions by calling into systemd's pam-module, which then uses CreateSession() (internal api!). This call does not return until the job of user@.service is done. `systemd --user` notifies READY=1 only after default.target is ready. Hm, this seems a bit excessive, because default.target can take a while. basic.target would seem more natural. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How soon after login can I rely on systemd --user having reached sockets.target?
On Sun, Oct 19, 2014 at 4:58 PM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: On Sun, Oct 19, 2014 at 12:43:59PM +0200, Colin Guthrie wrote: David Herrmann wrote on 19/10/14 12:05: Hi On Fri, Oct 17, 2014 at 6:14 PM, Colin Guthrie gm...@colin.guthr.ie wrote: Hi, How soon after login can I rely on systemd --user having reached sockets.target? This feels a bit like a you shouldn't rely on that point in time... type answer is warrented, and when e.g. GNOME or KDE sessions fully use systemd to bring themselves up it won't be an issue, but right now, systemd --user is started by (I think) PAM. I want to rely on systemd --user to handle PulseAudio's activation (ditching the built in stuff) and but I'm worried that e.g. GNOME or KDE might start up their own session stuff and spawn some PA consuming process before systemd --user has reached it's sockets.target and is thus ready and listening on PA's native socket. Doesn't seem to be a problem on my machine here (it's working really nicely actually!) but figured I should ask here too. Ordering of user units is (see /usr/lib/systemd/user/): default.target after basic.target after sockets.target PAM creates sessions by calling into systemd's pam-module, which then uses CreateSession() (internal api!). This call does not return until the job of user@.service is done. `systemd --user` notifies READY=1 only after default.target is ready. Hm, this seems a bit excessive, because default.target can take a while. basic.target would seem more natural. Same -- I never noticed this since I have linger enabled, but I would be a bit worried about the login blocking until /all/ of my services have started... Which makes socket activation not very useful. -- Mantas Mikulėnas graw...@gmail.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] How soon after login can I rely on systemd --user having reached sockets.target?
Hi, How soon after login can I rely on systemd --user having reached sockets.target? This feels a bit like a you shouldn't rely on that point in time... type answer is warrented, and when e.g. GNOME or KDE sessions fully use systemd to bring themselves up it won't be an issue, but right now, systemd --user is started by (I think) PAM. I want to rely on systemd --user to handle PulseAudio's activation (ditching the built in stuff) and but I'm worried that e.g. GNOME or KDE might start up their own session stuff and spawn some PA consuming process before systemd --user has reached it's sockets.target and is thus ready and listening on PA's native socket. Doesn't seem to be a problem on my machine here (it's working really nicely actually!) but figured I should ask here too. Cheers 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
