[systemd-devel] synchronizing user service

[Colin Guthrie]

'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 <lennart at poettering.net> wrote:
>> On Fri, 07.03.14 19:58, Alec Leamas (leamas.alec at 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/