[systemd-devel] synchronizing user service

[Colin Guthrie]

'Twas brillig, and Alec Leamas at 10/03/14 15:46 did gyre and gimble:
> On 3/10/14, Colin Guthrie <gmane at colin.guthr.ie> wrote:
>> '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.
> 
> [cut]
>>> 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
>>
> Thanks for taking time to reply. That said, it seems hard to get the
> message through on this list: systemd doesn't always fit the bill :).
> 
> Again: My service is not a systemd service, neither system nor user.

Yes, it's not *currently* a systemd service. My first suggestion was to
make it into one.

FYI, when systemd in the user session is fully supported, it will likely
enumerate the .desktop files (whether they are XDG autostart or just
regular .desktop files) and they *will* be systemd (user) services.

> And it can't be, since it needs to be part of the session, accessing
> the display and similar stuff.

Yeah, fair enough, this certainly rules out the second option I
suggested (User=+Group=), but eventually this shouldn't be a problem
overall when the whole session is also managed by systemd, so you're not
too far away from making it all work as a systemd (user) service.

> As I understand it , systemd only runs
> processes outside the session, be it system or user ones(?) The
> obvious approach for such a service is then to start it using a
> desktop file in the .config/autostart directory (freedesktop specs).

At present, I'd say yes, this is likely the case.

> However, this service started outside of systemd still need a socket
> provided by a another  systemd service. Actually, I have worked around
> my problem using socket activation which means that the socket is
> there. But I have a gut feeling that there will be more of these
> problems, synchronizing session services started by e. g., gnome and
> systemd services running outside the session.

During this early "systemd in the user session" stage, yes I agree, but
longer term, these kind of things will be addressed by probably starting
the whole session via systemd --user (and perhaps with systemctl --user
import-environment too).


> Perhaps I just got it all wrong, and systemd will (does?) also handle
> the session services running within the session? Or is there a
> reasonable robust way for a system user service started outside the
> session to join it? Or, my first thought, is there a way (API/tool)
> for non-systemd services to wait for a systemd service being started
> or so?

It will, but it's all still a little early but people are making good
progress here (the whole concept of a "session" verses a "user" is a
little blurry these days - many "services" are per-user already (as user
activity is very much tied into device access etc.) rather than
per-session - think audio access, disk mounting etc. and thus allowing
multiple graphical sessions of the same user is likely something that
won't be supported IIUC (not that it's really "supported" as such now)).
I think in the next six months or so this kind of thing will be properly
hashed out and work quite nicely.

I wouldn't necessarily quote me on the above. I've not followed things
too closely here recently, so could be a little bit out of touch!

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/