From: Jan Braun <janbraun@gmx.de>
To: Laurent Bercot <ska-supervision@skarnet.org>
Cc: supervision@list.skarnet.org
Subject: Re: Have an external script wait for a oneshot service
Date: Sun, 8 Dec 2024 00:46:12 +0100 [thread overview]
Message-ID: <Z1TeRM3hF_N5WTgq@abakus> (raw)
In-Reply-To: <emf0648862-dc16-477c-9f16-8384e1e6720a@6555180b.com>
[-- Attachment #1: Type: text/plain, Size: 1984 bytes --]
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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2024-12-07 23:46 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-04 15:28 Paul Sopka
2024-12-04 15:38 ` Charles Cazabon via supervision
2024-12-04 17:12 ` Paul Sopka
2024-12-04 21:47 ` Hoël Bézier
2024-12-04 20:00 ` Brett Neumeier via supervision
2024-12-04 20:05 ` Paul Sopka
2024-12-04 20:18 ` Brett Neumeier via supervision
2024-12-04 20:59 ` Paul Sopka
2024-12-04 21:58 ` Re[2]: " Laurent Bercot
2024-12-05 5:59 ` Tanuj Bagaria
2024-12-05 6:54 ` Paul Sopka
2024-12-05 8:05 ` Re[2]: " Laurent Bercot
2024-12-05 13:52 ` Paul Sopka
2024-12-05 19:44 ` Re[2]: " Laurent Bercot
2024-12-05 21:10 ` Paul Sopka
2024-12-05 21:42 ` Brett Neumeier via supervision
2024-12-06 5:32 ` Paul Sopka
2024-12-05 23:03 ` Re[2]: " Laurent Bercot
2024-12-06 12:41 ` Paul Sopka
2024-12-06 15:43 ` Re[2]: " Laurent Bercot
2024-12-06 16:11 ` Hoël Bézier
2024-12-06 17:14 ` Paul Sopka
2024-12-07 23:46 ` Jan Braun [this message]
2024-12-05 21:24 ` Jan Braun
2024-12-05 23:15 ` Re[2]: " Laurent Bercot
2024-12-04 20:09 ` Tanuj Bagaria
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Z1TeRM3hF_N5WTgq@abakus \
--to=janbraun@gmx.de \
--cc=ska-supervision@skarnet.org \
--cc=supervision@list.skarnet.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).