Unreliable systemd user service

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Unreliable systemd user service

Aidan Gauland-5
I have a user service for running xautolock that does not start on login
reliably, and I have no idea why, because there is no error message,
just an exit code of 1.  (Unit file and output of systemctl status
attached.)  Any suggestions on what to do next to troubleshoot this?

Regards,
Aidan Gauland


auto-screen-lock.out (600 bytes) Download Attachment
auto-screen-lock.service (278 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Unreliable systemd user service

Ansgar Burchardt-11
Aidan Gauland writes:
> I have a user service for running xautolock that does not start on login
> reliably, and I have no idea why, because there is no error message,
> just an exit code of 1.  (Unit file and output of systemctl status
> attached.)  Any suggestions on what to do next to troubleshoot this?

I would guess `xautolock` might be started before X is
running/accessible by your user.

Does the journal contain any useful log messages?  Note that there is a
race condition that some messages might not be logged as part of the
user service[1], so you might have to check all log messages and cannot
rely on journalctl's `--user-unit` option.

Ansgar

  [1] https://github.com/systemd/systemd/issues/2913

Reply | Threaded
Open this post in threaded view
|

Re: Unreliable systemd user service

Aidan Gauland-5
On 21/06/19 6:25 PM, Ansgar Burchardt wrote:
Aidan Gauland writes:
I have a user service for running xautolock that does not start on login
reliably, and I have no idea why, because there is no error message,
just an exit code of 1.  (Unit file and output of systemctl status
attached.)  Any suggestions on what to do next to troubleshoot this?
I would guess `xautolock` might be started before X is
running/accessible by your user.

Does the journal contain any useful log messages?  Note that there is a
race condition that some messages might not be logged as part of the
user service[1], so you might have to check all log messages and cannot
rely on journalctl's `--user-unit` option.

Nope, absolutely nothing in the logs.

Someone else suggested running xautolock from my .xsessionrc script so that it is always run after X is running, and that seems to work.  I wanted to run this via systemd because that's easier to restart after making tweaks than something run as part of a startup script, but I have not been able to find any mechanism to delay starting a user service until the graphical login is ready.

Reply | Threaded
Open this post in threaded view
|

Re: Unreliable systemd user service

john doe-6
On 6/21/2019 8:50 AM, Aidan Gauland wrote:

> On 21/06/19 6:25 PM, Ansgar Burchardt wrote:
>> Aidan Gauland writes:
>>> I have a user service for running xautolock that does not start on login
>>> reliably, and I have no idea why, because there is no error message,
>>> just an exit code of 1.  (Unit file and output of systemctl status
>>> attached.)  Any suggestions on what to do next to troubleshoot this?
>> I would guess `xautolock` might be started before X is
>> running/accessible by your user.
>>
>> Does the journal contain any useful log messages?  Note that there is a
>> race condition that some messages might not be logged as part of the
>> user service[1], so you might have to check all log messages and cannot
>> rely on journalctl's `--user-unit` option.
>
> Nope, absolutely nothing in the logs.
>
> Someone else suggested running xautolock from my .xsessionrc script so
> that it is always run after X is running, and that seems to work.  I
> wanted to run this via systemd because that's easier to restart after
> making tweaks than something run as part of a startup script, but I have
> not been able to find any mechanism to delay starting a /user/ service
> until the graphical login is ready.
>

Is it always working if you run the command manually?

--
John Doe

Reply | Threaded
Open this post in threaded view
|

Re: Unreliable systemd user service

Jonathan Dowland
In reply to this post by Aidan Gauland-5
On Fri, Jun 21, 2019 at 06:50:14PM +1200, Aidan Gauland wrote:
>Someone else suggested running xautolock from my .xsessionrc script so
>that it is always run after X is running, and that seems to work.  I
>wanted to run this via systemd because that's easier to restart after
>making tweaks than something run as part of a startup script,

What about starting the service *via systemd* in your .xsessionrc?
something like "systemctl start xautolock".

--
Jonathan Dowland

Reply | Threaded
Open this post in threaded view
|

Re: Unreliable systemd user service

Aidan Gauland-5
In reply to this post by john doe-6
On 21/06/19 7:24 PM, john doe wrote:
> Is it always working if you run the command manually?
It has so far, yes.

Reply | Threaded
Open this post in threaded view
|

Re: Unreliable systemd user service

Aidan Gauland-5
In reply to this post by Jonathan Dowland
On 21/06/19 8:33 PM, Jonathan Dowland wrote:
> On Fri, Jun 21, 2019 at 06:50:14PM +1200, Aidan Gauland wrote:
>> Someone else suggested running xautolock from my .xsessionrc script so
>> that it is always run after X is running, and that seems to work.  I
>> wanted to run this via systemd because that's easier to restart after
>> making tweaks than something run as part of a startup script,
>
> What about starting the service *via systemd* in your .xsessionrc?
> something like "systemctl start xautolock".
I had thought of that, but it feels even messier to use both .xsessionrc
and systemd together.  Why is there no "the graphical session is ready"
systemd target?

Reply | Threaded
Open this post in threaded view
|

Re: Unreliable systemd user service

Michael Biebl-3
Hi

>  Why is there no "the graphical session is ready"
> systemd target?

There is, incidentally it is named graphical-session.target :-)
See man systemd.special

Unfortunately, no display/session manager is hooked up yet to manage the
lifetime of that target, so you can't make use of that target as of now.

Martin Pitt has been working on that in the past, see
https://lists.freedesktop.org/archives/systemd-devel/2018-June/040952.html
which contains a few references to work from 2016.

When Martin left Canonical, work on this mostly stopped and I don't know
what the current state is in that regard.
I did find
https://blogs.gnome.org/laney/2018/06/26/starting-sessions-with-systemd/
so I hope we will eventually see proper support for
graphical-session.target.

Regards,
Michael


--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Unreliable systemd user service

Aidan Gauland-5
On 25/06/19 3:46 AM, Michael Biebl wrote:
 Why is there no "the graphical session is ready"
systemd target?
There is, incidentally it is named graphical-session.target :-)
See man systemd.special

Unfortunately, no display/session manager is hooked up yet to manage the
lifetime of that target, so you can't make use of that target as of now.
Ah, that would be why using that was valid but did not work.  Good to know, thanks!