Re: Have an external script wait for a oneshot service

Jan Braun <[email protected]> Sun, 8 Dec 2024 00:46:12 +0100

Newsgroups	gmane.comp.sysutils.supervision.general
Message-ID	<Z1TeRM3hF_N5WTgq@abakus>

Laurent Bercot schrob:
[restored quote for context]
> > > You want to run s6-rc at login time, sure, I can totally see where i
> > > can be beneficial there. But earlier? Even systemd doesn't run user
> > > stuff before a user logs in. And if *they* don't do it, it means that
> > > there are ZERO use cases.
> >
> > This is an argumentum ad verecundiam.
>
>  Not at all. I never refer to systemd as an authority (lol).
>  It's just that systemd is maximalist: every use case they can think of,
> they include. (Since the unit file format is extensive, they have to.)
> They include way, way more than they should; they are by no means an
> example to follow. My point is that if a use case isn't planned for in
> systemd, there's a pretty good chance it's not a real one.

Users have been able to run oneshots at boot since before systemd
existed: @reboot in a user crontab. That alone should prove the use case
is real.

And systemd apparently *does* have the ability to run user stuff without
the user logging in:
https://wiki.archlinux.org/title/Systemd/User#Automatic_start-up_of_systemd_user_instances

I didn't find an @reboot equivalent for systemd timers in a quick
search, but since oneshots are used for managing state, my guess is
their answer would be "there should be a special systemd functionality
for managing that particular state, use that" and/or "fix the state in
the ExecStartPre for the service relying on the state". The latter would
even be reasonable: as a runit user, I've always been ensuring necessary
state in the ./run file, and never found the lack of explicit support
for oneshots limiting.

That is also why I can't form an opinion on the merits of Paul Sopka's
proposal. But effectively saying "(user)oneshots/s6-rc are useful while
the user is logged in, but not while the user is not logged in" seems
wrong. That's machinery that might be useful, or might not be, but it
shouldn't depend on or care about the user's login state.

cheers,
    Jan

signature.asc (application/pgp-signature, 833 B)