Hi folks,
Matthias, thanks for your work on this package :)
I'm attaching git patches to add sysv init scripts to seedfiles;
I can do a MR on salsa if you prefer that way.
the two scripts are a rework of my previous contributions to
opentmpfiles Debian package, when it was a thing.
Sorry this is long but I think is better to discuss in details:
* I've not included the *-dev scripts that create devices in /dev; IMHO, even if
something like seedfiles is used to create the devices, it's better to delegate
the task to each init system (for sysv it would be the initscripts package).
By the way on my system if I do
'seedfiles --dry-run --prefix=/dev --create --boot' it does nothing; I guess the
conf files for this are shipped by systemd ?
* even the setup script does not look safe to me, it removes stuff that I'm not sure
it's a good idea to remove at runtime, so I've restricted the actions to runlevel 0|6|S
'seedfiles --dry-run --create --remove --boot --exclude-prefix=/dev'
seedfiles: Would empty directory '/run/sudo'.
seedfiles: Would remove '/tmp/xauth_qsiNAb'.
seedfiles: Would remove '/tmp/xauth_QRWHsY'.
(maybe we could run this without '--remove' ?)
'seedfiles --clean --dry-run'
seedfiles: Would remove "/run/lirc/lircd".
seedfiles: Would remove "/run/lirc/lircd.pid".
(lircd is running here; also I have run mounted as tmpfs, what's the value of
cleaning there? systemd thinks that 'clean' is safe and there is a timer for
it.. maybe we can --exclude-prefix=/run for clean ?)
* also, maybe is better to make 'stop' a noop (currently is not) as
getting the order right at shutdown, considering the cleaup, is not
that simple
* on my system
'seedfiles --dry-run --create --remove --boot --exclude-prefix=/dev'
creates a lot of stuff under /run even for services that are disabled
seedfiles: Would create '/run/postgresql' (type d).
seedfiles: Would create '/run/proftpd' (type d).
seedfiles: Would create '/run/sddm' (type d).
seedfiles: Would create '/run/wdm' (type d).
seedfiles: Would create '/run/wdm/GNUstep' (type L).
I think maintainers are abusing tmpfiles for runtime dirs
even if systemd has directives for this in service files,
and I don't like /run to be flooded with dirs for disabled
services this way;
on the other hand I've already seen that sometimes when
a tmpfiles.conf is added it happens that code to create
those dirs is removed from the init script.
Also, more frequently, code to create dirs in /var/ is
removed from maintscripts so if we don't run this at boot,
some sysv service may fail to start in the near future
Thoughts ?
Best,
Lorenzo
Control: tag -1 upstream Thanks! Hm, I'm not that well versed with sysvinit, and I know for a fact that under openrc (which I use) the devfs service sets up /devtmpfs, and then udev mounts the /dev devices. That may very well be. I would suggest that you reach out to upstream; they have been very helpful in getting bugs fixed, and also state that they will merge any needed tmpfiles config. seedfiles is also still very new, so the issue with --clean in /run should best also be discussed upstream. Once those questions are resolved I am happy to include an init script. best, werdahias
Hi all,
I'm attaching an updated version of the patches where
stop actions are turned into no-op
I've checked all tmpfiles.conf in my system and I think seedfiles does
the right thing (given the tmpfiles.d format) so I don't know what to
report upstream.
My issues was more with tmpfiles.conf files shipped in Debian by
several packages and the idea was that we can slightly change the way
systemd-tmpfiles/seedfiles is called at boot to adjust the behavior
according to our preferences; IMHO this is a Debian discussion, not
an upstream one.
Sysvinit Maintainers, I think the following questions are open:
1. do we want to add a common boot script (will work for Sysvinit,
Openrc and runit) to seedfiles/standalone-tmpfiles or we prefer to
delegate this to each init package?
2. if 1=yes, do we agree on the set of options to use? for example,
exclude /dev ?
maybe exclude /run and /tmp from cleanup could be a thing?
If there is not agreement on 2. it's better to not ship the script in
seedfiles and delegate to each init package.
My preference as runit maintainer is:
- exclude /dev from files creation (delegate to each init);
- I don't like the flood on /run, but I can live with it;
- I don't see the use of cleaning in /run, it's a tmpfs here, but
maybe I'm missing something
- I suspect users can be surprised and very unhappy of
time-based (ie older that 10d or 20d) clean up in /tmp and I'm not
sure what to do with /tmp
If there is no interest in discussing this right now I suggest to either
won't fix it or leave it open until some service will start to fail due
to missing call of tmpfiles at boot, and restart the discussion then.
Best,
Lorenzo
Thanks for your work on this. ISTR that on GNU Hurd /run doesn't have to be a tmpfs as so it should be cleaned. We had a similar discussion relating to bin:initscripts and whether the /run cleaning code could be removed. I will try to find the reference. I think support for each init is better within the package. Yes Not sure what you mean by 'flood'? GNU Hurd? Please don't do time-based cleanup of /tmp. If a user wants it, there are easy ways to implement it. Cheers, Mark
Hi Lorenzo, Thanks for opening up discussion to the list! I attach initscripts I am using with systemd-standalone-tmpfiles which I would like to refine. Following your lead I also dropped the 'stop' action, although I am wondering if I should include the '0 6' stop runlevels anyway, at the expense of shutdown log noise, because just filling out the stop stub later is a lot easier than also changing the configured runlevels on existing installations? In this version, 'TYPE=oneshot' gives us a meaningful 'status' query at the expense of needing to use 'restart' instead of 'start' to reapply the operation. One question for Mark in relation to init-d-script(5) is that by using DAEMON=none, as required for this type of service, we lose the automatic "this package is still installed" check - what is the idiomatic way to reinstate that - would it be a 'start_pre' override to test for it? Should we also put drop-ins to /etc/insserv.conf.d of the form: $x-tmpfiles: seedfiles So that we can add an LSB dependency for scripts in packages which have decided to rely on tmpfiles for essential content? Thanks, Andrew
A quick update to close on my (rejected) foray into an equivalent solution for systemd-standalone-tmpfiles (#1139903): I opted to include the stop runlevels (like Lorenzo's seedfiles version) for the reason I stated above - ease of adding to later if needed. The answer is, just specify a value for DAEMON= as long as stop, start and status are all overriden (or defined by the TYPE=oneshot implementation) then it will do the right thing. No colon here. I decided this probably wasn't needed because runlevels 2-5 are already sequenced after this and the scripts in runlevel S tend not to rely on tmpfiles so it seemed over the top.