'Twas brillig, and Alec Leamas at 07/03/14 19:45 did gyre and gimble: > Sorry for not being clear. The priob > > On 3/7/14, Lennart Poettering <lenn...@poettering.net> wrote: >> On Fri, 07.03.14 19:58, Alec Leamas (leamas.a...@gmail.com) wrote: >> >>> Dear list, >>> >>> Being a systemd dummie, I have a problem. It's a about running a >>> service as a user, which needs to synchronize with a systemd service. >> >> What do you mean by "synchronize"? >> >>> Since the service needs to be part of the session, I presume that a >>> /systemd/user service isn't really the way to go (?): This leaves me >>> with the problem to start a service e. .g,, using a desktop file in >>> the autostart dir. The service needs a socket created by a systemd >>> service. >> >> You can simply order your system service before >> systemd-user-sessions.service. All user sessions are only started after >> that, hence ordering your service before that makes sure for users it is >> always accesssible. >> >>> As of now, I simply poll for the socket creation in a shell script. >>> It's just that my gut feeling is that this is not really the way to >>> do this. Is there a better approach? >> >> Well, you can make it socket activated, but otherwise just order it like >> suggested above... > > Sorry for not being clear... > > I can't make it socket activated, nor can I order it. My user service > is *not* a systemd service since it needs to be part of the session. > As of now, it's started as a desktop service using a desktop file. > > So the question is: is there any "good" way for a non-systemd user > service to to things that systemd services does, like waiting on a > socket or somehow become part of the ordering scheme?
So I guess one question is, do you have a "systemd --user" instance running? Typically this happens automatically via PAM with most reasonably recent systemds. So you *could* write a user systemd unit (or combo of units - socket+service) that would start your service. This might or might not really help tho' as whatever consumes your service would still need to block/wait I guess (even if it was socket activated in the user session I'm not sure you currently have any guarantees that non-systemd stuff is started after systemd stuff - would need a full conversion to systemd-based user sessions for that). You could use "systemctl --user is-active foo.socket" to do the polling which might or might not seem nicer to you. Another option which may work if you have a simple setup and control over the machine, is to write a *system* service but put User=+Group= directives in it to start as your user+group. You can order that before systemd-user-sessions.service and that will allow you to login confident that your service will already have started. This falls down quite royally when you have multiple users tho'! Hope that helps a bit. 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
