Re: Unreliable systemd user service
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!
Re: Unreliable systemd user service
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 Description: OpenPGP digital signature
Re: Unreliable systemd user service
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?
Re: Unreliable systemd user service
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.
Re: Unreliable systemd user service
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
Re: Unreliable systemd user service
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
Re: Unreliable systemd user service
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.
Re: Unreliable systemd user service
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
Unreliable systemd user service
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.service - Lock the screen automatically after a timeout Loaded: loaded (/home/aidan/.config/systemd/user/auto-screen-lock.service; enabled; vendor preset: enabled) Active: failed (Result: exit-code) since Sun 2019-06-16 16:29:26 NZST; 43min ago Process: 1542 ExecStart=/usr/bin/xautolock -time 5 -locker /home/aidan/bin/i3lock (code=exited, status=1/FAILURE) Main PID: 1542 (code=exited, status=1/FAILURE) [Unit] Description=Lock the screen automatically after a timeout [Service] Environment=DISPLAY=:0 ExecStart=/usr/bin/xautolock -time 5 -locker /home/aidan/bin/i3lock [Install] WantedBy=default.target
