Sorry for the very long delay, i'm short on free time :(
Yes. Shipping 'down' file is nice idea, I like it. But it does not need
'runit-policy' layer.
I challenge this assumption. I believe native runit tristate is much
more logical -- service is either:
* disabled
* temporary stopped (down file)
* running
What is wrong with following logic (module sanity checking)
* invoke-rc.d <service> <action> := do
check_rc.policy()
sv <service> <action>
* update-rc.d <service> remove := do
clean-up symbolic links ; currently done in runit-helper
* update-rc.d <service> defaults|defaults-disable := noop
* update-rc.d <service> enable := ln -s /etc/sv/<service> /etc/service
* update-rc.d <service> disable := rm -f /etc/sv/<service>
== 72a3fa5 Add support for runit into service script
.......
+if [ -f /run/runit.stopit ] && [ -d "${RUNDIR}/${SERVICE}" ]; then
+ if update-service --check "${SERVICE}"; then
+ exec sv "${ACTION}" "${SERVICE}"
+ else
+ echo "Can't perform ${ACTION}, ${SERVICE} is disabled"
+ exit 1
I'd use [ test -e /etc/sv/${SERVICE} ] directly. Imho, it is much
simplier to understand. I needed to check manual for update-service(8)
to understand this code.
== 8079d0e Add support for runit into invoke-rc.d script
"/etc/sv/${INITSCRIPTID}" ]; then+ elif [ -f /run/runit.stopit ] && [ -d
${INITSCRIPTID}+ # fallback on sysv if there is no runit service for
"stop" ]; then+ # "$@" is always discarded unless is --force-sysv
+ if [ "x$@" = "x--force-sysv" ] && [ "${saction}" =
"x$@" feels wrong, since it can expand to multiple words. Maybe you
meant "x$1" or "x$*"?
exit 0+ "${INITDPREFIX}${INITSCRIPTID}" "${saction}" &&
exit 0+ fi
+ case $saction in
+ start|restart|try-restart|reload|force-reload)
+ #No-Op if the service is not enabled
+ update-service --check "${INITSCRIPTID}" ||
+ #No-Op is the service wanted status is 'down'
+ [ -f "/etc/sv/${INITSCRIPTID}/down" ] && exit 0
+ sv "${saction}" "${INITSCRIPTID}" && exit 0
Why `|| exit 0'?
[2019-03-13 18:43] Lorenz <lorenzo.ru.g@xxxxxxxxx>
Mmm, I should have spent more time in detailing my proposal: I think
if you look at the code it's quite simple to understand what i'm doing
but it's maybe more complex to understand why i'm doing this or that
thing. Lets try with more details:
It is easy understand what are you doing, but I failed to understand why.
Now I got better idea, thank you.
Wait. I believe that is what rc.policy for. Am I wrong?
I believe that rc.policy is for some extra policy layer; but there is
also an implicit policy layer applied in both 'invoke-rc.d' and
'update-rc.d':
what i'm trying to do with 'runit-policy' is to port that implicit layerdisabled; also
into runit.
The implicit layer does something like this:
* invoke-rc.d start|restart ... it's a No-Op if the service is
* update-rc.d foo defaults|default-disabled it's a No-Op if theservice
is
already disabled|enabled
Why do I need a dedicated script for that?
In Sysv i can tell if a serivce foo is disabled looking for a 'KNNfoo'tell
symlink;
in runit when the service is disabled, there is no link, so how can i
if it was a local
admin decision or not?
I would have to combine the absence of a link with a dpkg command like
to check if it's a new install or an upgrade, and then i have to use a
runit dedicated dh sequence..
Why do you need it? Maybe my image of world is totally inadequate, but I
see only one usage of all those init-system-helpers: to abstract
differences of multiple init systems from maintainer scripts.
What is wrong with following logic (module sanity checking)
* invoke-rc.d <service> <action> := do
check_rc.policy()
sv <service> <action>
* update-rc.d <service> remove := do
clean-up symbolic links ; currently done in runit-helper
* update-rc.d <service> defaults|defaults-disable := noop
* update-rc.d <service> enable := ln -s /etc/sv/<service> /etc/service
* update-rc.d <service> disable := rm -f /etc/sv/<service>
theNo. By default, services are started after installation.
Yes, i'm not changing that!
the reason why i want to ship service directory with a down file
is that, inside a postinst script, i want that 'update-rc.d' to enable
service without starting it, and only then, invoke-rc.d will remove the
down file and start or restart the service.
This contorted way allow us to reuse the dh_installinit postinstall as it
is with the 'default' behaviour, and with really small change also the
'default-disabled' sequence and the 'no-stop-on-upgrade' sequence.
This way we don't care of what code the maintainer insert between
update-rc.d and invoke-rc.d: that code may give for granted that the
service is enabled but not yet started|restarted..
I will write some sequence examples in another thread so that it's
easy to understand what i mean.
Yes. Shipping 'down' file is nice idea, I like it. But it does not need
'runit-policy' layer.
I do not understand. If service is disabled, /etc/service/{foo} is not
present, so you can't `sv up {foo}'. Why something else?
I have to account also for the down file: invoke-rc.d is executed in
maintscripts, so if a local admin declares that he/she doesn't want
a service to be automatically started ( update-service --noauto),
than it's not correct to start that service with invoke-rc.d.
Given that in `runit-policy' there is four files
<service>-{en,dis,up,down},
I believe you want to say, that service could be in four different
states [(x, y) ; x <- {en, dis}, y <- {up, down}]. So if
I understood you correctly this time, the whole `runit-policy` required
to make those 4 states distinguishable.
I challenge this assumption. I believe native runit tristate is much
more logical -- service is either:
* disabled
* temporary stopped (down file)
* running
init-system-helpers:PS. Did not look at code.
Let apart the change i proposed for runit and focus on
please, as you have some time, have a look at the code, starting with
'runit-policy', then 'update-rc.d' and 'invoke-rc.d'.
If you are busy with Buster release, there is no rush, but be sure you
really want to reject this design before uploading new version of
dh-runit and runit-helper to experimental, because otherwise we are
duplicating efforts.
dh_runit=2.8.9 in experimental with very minor fix, and I do not expect
(unless bugs discovered) make changes anytimes soon. I do not foresee
collisions here.
acceptThere is social issue. Every change to `init-system-helpers' is quite
slow and painful, at least for me.
Yes i will interact with init-system-helpers maintainers untill they
runit support, even if this require months of pressing, but first i needto
be able to claim that you are ok with the changes i'm proposing, and for
now you are not
Wonderful.
Commends regarding commits:
== a649bb2 Add runit-policy script
== ea4efba debian: install runit-policy in /usr/sbin
== 5142278 debian: install policy runit directory
== 9614a7d Add the manpage for runit-policy
As I wrote above, I challenge the very existence of this script. I will
not mention it in comments to rest of commits.
== 72a3fa5 Add support for runit into service script
Good, very good. Some minor tweak:
+#Runit-init
+# Only perform ${ACTION} when there is a runscript for
+# the service and ${SERVICE} is enabled.
+# If the service is disabled print a message
+# and do not perform ${ACTION}
+# If there is no runscript at all fallback on sysv.
+if [ -f /run/runit.stopit ] && [ -d "${RUNDIR}/${SERVICE}" ]; then
+ if update-service --check "${SERVICE}"; then
+ exec sv "${ACTION}" "${SERVICE}"
+ else
+ echo "Can't perform ${ACTION}, ${SERVICE} is disabled"
+ exit 1
+ fi
+fi
update_openrc_started_symlinks
run_via_sysvinit
I'd use [ test -e /etc/sv/${SERVICE} ] directly. Imho, it is much
simplier to understand. I needed to check manual for update-service(8)
to understand this code.
== 8079d0e Add support for runit into invoke-rc.d script
diff --git a/script/invoke-rc.d b/script/invoke-rc.d"/etc/sv/${INITSCRIPTID}" ]; then
index 27c045e..c6159f4 100755
--- a/script/invoke-rc.d
+++ b/script/invoke-rc.d
@@ -549,6 +549,37 @@ if test x${FORCE} != x || test ${RC} -eq 104 ; then
esac
elif [ -n "$is_openrc" ]; then
rc-service "${INITSCRIPTID}" "${saction}" && exit 0
+ elif [ -f /run/runit.stopit ] && [ -d
+ # fallback on sysv if there is no runit service for${INITSCRIPTID}
+ # "$@" is always discarded unless is --force-sysv"stop" ]; then
+ if [ "x$@" = "x--force-sysv" ] && [ "${saction}" =
"x$@" feels wrong, since it can expand to multiple words. Maybe you
meant "x$1" or "x$*"?
+ "${INITDPREFIX}${INITSCRIPTID}" "${saction}" &&exit 0
+ fiexit 0
+ case $saction in
+ start|restart|try-restart|reload|force-reload)
+ #No-Op if the service is not enabled
+ update-service --check "${INITSCRIPTID}" ||
+ #No-Op is the service wanted status is 'down'
+ [ -f "/etc/sv/${INITSCRIPTID}/down" ] && exit 0
+ sv "${saction}" "${INITSCRIPTID}" && exit 0
Why `|| exit 0'?
== 7a2a1c5 Add make_runit_links sub to update-rc.d
Good.
== 4ab6659 update-rc.d: add runit to the init sequence
Seems fine.
== 27d2bfb Runit: fix a typo in update-rc.d
Happens :) `git rebase -i` is our friend :)
== 88a329b invoke-rc.d/runit: rm down file on start
Fine.
--
Note, that I send and fetch email in batch, once every 24 hours.
If matter is urgent, try https://t.me/kaction
--
