il devuanizzato Steve Litt <sl...@troubleshooters.com> il 04-07-19 22:23:51 ha
scritto:
Hi viverna,
I have a very different viewpoint than most people, so the following is
*my opinion* and is not in the mainstream.
I think that, for both s6 and runit, run scripts (and any finish
scripts or environment files) should come from a small committee of
runit/s6 experts, NOT from the overworked "upstreams" who created the
software, nor the overworked distro-based maintainers who adapt the
software to the distro. During the Debian-User systemd war, one of the
greatest sources of resistance to multi-initism was "upstreams" and
maintainers who bitched about now having to take care of an extra set
of init scripts.
If each "upstream" simply documents:
1) How to run the software, in the foreground, without excessive
logging.
2) The preferred user and group to run the software.
3) What daemons should already be running before the software.
4) Any special state circumstances necessary to start the software. For
instance:
* Network up
* Such and such file with so and so permissions
* Etc.
5) Any cleanup that must be done after the software finishes or crashes.
6) Any environment vars the software is responsive to.
7) The software's response to any signals.
8) Any special logging the software does all by itself.
9) Does it require a "twin" daemon, like smbd and nmbd, and if so,
which should start first?
Possessing the preceding info, it's easy to make an s6 or runit run
script, finish script, and if necessary environment file. In most cases
only the first 4 are really necessary. If an "upstream" refuses to
answer the questions, the info can probably be gleaned from the
software's systemd unit file.
This list of questions could be sent to each "upstream", and the
answers will almost 1 for 1 correspond to the run script.
The runit package could install tree /etc/runit/scriptdirs and the
directory /etc/sv, and a daemon's (call it mydaemon) install could
include something like the following:
if -d /etc/runit/scriptdirs; then
ln -s /etc/runit/scriptdirs/mydaemon /etc/sv/mydaemon
fi
Uninstalling the mydaemon package would remove symlink /etc/sv/mydaemon.
My method runs counter to the way it's always been done, and I always
get a lot of pushback when suggesting it, but my way would probably
limit resistance from "upstreams" and maintainers, and would not
require those people to become runit and/or s6 experts. Meanwhile, it
would be trivial for a couple runit and s6 experts to write the actual
startup files, based on the "upstream"s answer to a few simple
questions.
SteveT
Steve Litt
July 2019 featured book: Troubleshooting Techniques
of the Successful Technologist
http://www.troubleshooters.com/techniques
_______________________________________________
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Sounds like a good solution to me, however the main problem remains; all
packaged daemon must implement (at install phase) the simple script you
specified above.
How to do? Devuan, if I'm not wrong, get packages from Debian for all
packages with no systemd hard dependency.
Devuan is a great distro and has excellent developers but limited
manpower.
I think that fork all daemon is not praticable. Instead it's possible
inject in all daemon's install a piece of posix shell?
Workaround script on event "DPkg::Post-Invoke" as I said in the previous
email? Else is better another strategy?
These are questions that I ask myself but it's important for the future
of Devuan and init systems diversity.
The choice of Debian is to follow freedesktop "fancy" guy. It is not
difficult to think of the day when Debian will remove completely
sysvinit script in all packages.
--
viverna
_______________________________________________
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
