On 3/10/14, Colin Guthrie <gm...@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 <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.

[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.
And it can't be, since it needs to be part of the session, accessing
the display and similar stuff. 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).

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.

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?

"confused"

--alec

I
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Reply via email to