Control: tags -1 moreinfo
I need more info to proceed with this bug
On Wed, 26 Oct 2022 18:26:02 +0200 Andras Korn
<korn-debb...@elan.rulez.org> wrote:
>
> Checking for /etc/sv/$name and skipping initscripts if those
> directories exist is wrong for two reasons:
>
> 1. /etc/sv/$name may not be symlinked into /etc/service (false
> positive);
>
> 2. /etc/service may contain a symlink to a service directory for
> this service that is elsewhere in the filesystem, not in /etc/sv
> (false negative).
>
Please clarify if this is a problem for rc2.d scripts only or for both
rc2.d and rcS.d scrips. Also I fail to see why one would want to have a
native runit service in /etc/sv and still want to run the correspondent
sysv scripts instead.
Overall for stage1 I think I'm going to revert an old change a go back
to a plain for loop without any check for /etc/service nor /etc/sv/ (see
#1023358).
For stage2/3, assuming my "sysv-2-runscript generator" proposal made you
go away in total despair, here is another (hopefully simpler) idea:
I can add a loop that runs scripts in a certain directory in
lexicographical order, without any policy applied.
You can disable the run_sysv_script with the no.emulate.sysv flag file
and manage scripts in such directory on your own.
I am also fine to add an extra check for /etc/service/name and/or
/etc/service/.name (but in addition, not as a replacement for the
/etc/sv/name).
let me know if one or a mix of the above can help.
For a rationale of this, see below
> Maybe we should start from a statement of the particular problems
> that need solving? Do you have such a document?
The reason for recent changes of stage[1,2,3] is the following: I want
to move to (and ideally reach) a state where runit is able to init and
run a system without using/depending on facilities that are specific to
other init systems.
To simplify
A. (starting point): runit is able to init the system, using initscripts
from sysv, but the user has to write native services ( the system
starts and provides only 6 getties)
B. (transition): add a run_sysv_script interface that starts
initscripts when a native runscript is missing, so that while
runscript are gradually added the system is usable by non expert
users. run_sysv_script uses the sysv order and the sysv convention
for enable/disable a service: this is a little problem at the
beginning, but the more runscripts are added, the less this is
convenient. runscripts starts to conflict/interact with sysv and
additional effort and layer are needed to keep the two system
together.
C. (end point): runit init and run the system without relying on any
interface specific to another init system. Enough runscripts and
oneshots are available. There is a native mechanism that
enable/disable and restarts services, that can be overriden by the
user. The sysv layer is dropped, sysv script are masked ( so that
maintainer scripts don't run them during upgrade)
We are now at B, and I'm preparing stage[1,2,3] for C, so there is the
maximum overhead because I'm adding stuff and retaining (for now) the
sysv compatibility. I'm not sure the package will ever reach a full C
stage, because I don't have enough resources (there are more than 1000
services in Debian packages). On the other hand if I made my
calculations right, knowledgeable users can customize the system and
downstreams can build extra packages on top of the Debian one without
the need to modify it.
The relevant question for me is what runit needs to provide in stage
[1,2,3] at C, I think roughly
1. (stage1) run tasks to initialize a base system
2. (stage2) provide a way to run oneshots tasks. I think run a set of
sh scripts or having oneshots expressed as runscripts are both valid
approach, it really depends on sysadmin preferences/needs
3 (stage 2) choose the directory for runsvchdir
4 (stage 2) start runsvdir
5 (stage3) provide a way to stop some selected services in
some ordered way
6 (stage3) stop all remaining services with no particular order
7 (stage 3) run tasks to shutdown the system
the current status is
1 uses scripts from initscripts, and is possible to run an
alternative set of scripts, which is not optimal but acceptable;
2 is missing, but there is a 2.1 (run_sysv_scripts), hence my above
proposal to add 2.
3,4,5 and 6 are already in place;
7 is a wierd mix, it run initscripts using the run_sysv_script
interface, but is possible to run an alternative 'native' sequence.
Not sure if I am forgetting something or the list above can be
simplified. Hope that at least one or part of a solution proposed so
far is acceptable to you, I'm running out of ideas otherwise.
Lorenzo
