Marco Moock <
mm+usenet-es@dorfdsl.de> wrote:
On 25.10.2024 um 18:23 Uhr Marc Haber wrote:
Debian's release goal for Trixie is that no init scripts are used on a
systemd system. We (Debian) are just behind Red Hat a little less than
a decade in this regard.
How will stuff be handled that involves more that just starting a
daemon, e.g. preparing certain stuff?
Should that all be packed in ExecStart=?
You can either ship a systemd unit that calls the init script or use
ExecStart and ExecStartPre et al. The holy war against scripts and
shells is one of the favorite beefs that I have with systemd. It's a
sound point from the security point of view, but it reduces the
usability and readability of Unit Files.
The exim4 packages are a case of this. The maintainer¹ has resorted to (relevant parts only)
|Environment="EXIMSERVICE=-bdf -q30m" "UPEX4OPTS=" |EnvironmentFile=-/etc/default/exim4
|ExecStartPre=/usr/sbin/update-exim4.conf $UPEX4OPTS
|ExecStart=/usr/sbin/exim4 $EXIMSERVICE
|ExecReload=/usr/sbin/update-exim4.conf $UPEX4OPTS ; \
|kill -HUP $MAINPID
EnvironmentFile is something that the systemd people already wanted to
remove years ago (my opposition against this got me banned from
systemd-devel for some time), and I don't like the ExecReload part at
all. Sending a signal to the daemon and not waiting for confirmation
is explicitly not recommended in the systemd.service manual page, and
the fiddling with a MAINPID variable is something I don't like at all.
systemd can put all processes for a unit into its own cgroup and then
signal the cgroup, I would at least investigate this matter further.
Greetings
Marc
¹ I am still formally a member of this maintainer team but haven't
contributed in a decade.
--
---------------------------------------------------------------------------- Marc Haber | " Questions are the | Mailadresse im Header Rhein-Neckar, DE | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)