Humm .. if with the last upgrade you have 2.1.2-47 there are few changes that might impact boot scripts like

runit (2.1.2-46) experimental; urgency=medium

  * ...
  * ...
  * Stage[1,3]: hook to experiment with alternative
     sets of boot scripts. Only initscript are packaged
     in Debian right now, but native sets of scripts
     can be found downstream or on github.
  * ...

but it's hard to trigger, you have to use an alternative set of boot scripts in the right directory and there must be a flag file..
I'm using initscript (from sysvinit package) to boot and shutdown the system: are you using a different set of scripts from somewhere else?
It might be that apparmor needs some initialization task or filesystem setup that are not done properly at boot.. just a random idea

Did you check the output of

/etc/init.d/apparmor status

?
and

/etc/init.d/apparmor start

or

/etc/init.d/apparmor restart

?

Hi,

I have tor running and it works as expected, but I don't have apparmor.
I tried to install apparmor and restart tor, and it seems to work so I can't reproduce.
( I can't reboot right now, will try later )

Do the following:
stop any running tor instance

update-service --remove /etc/sv/tor

/etc/init.d/tor stop

then try to start manually from  a root console

/usr/bin/aa-exec --profile=system_tor -- /usr/bin/tor --defaults-torrc /usr/share/tor/tor-service-defaults-torrc --Log 'notice stdout' --RunAsDaemon 0 --verify-config

/usr/bin/aa-exec --profile=system_tor -- /usr/bin/tor --defaults-torrc /usr/share/tor/tor-service-defaults-torrc --Log 'notice stdout' --RunAsDaemon 0

does it give any error?

Exactly

As for a dependency, I see that the Man page for sv says that sv start is the same as sv up but that it waits for the command to take effect, calling the check script if present. This would seem to mean that sv start dbus is the same as sv up dbus && sv check dbus. I assume that the || exit 1 will cause Runit to recognise that the dependency has not started and retry later (1s ?).

Yes, that's the idea.

the one that I linked in salsa.debian.org does

#!/bin/sh

test -S /var/run/dbus/system_bus_socket && exit 0

exit 1

both are fine according to my testing

Reports from tinkerers and users are very helpful to improve the package but sadly I get very few on Debian..
Also I read this forum rarely, so consider to use

reportbug runit

or send a ping if you want me to join a discussion

Lorenzo

Hi Geoff 42,

The two problems that you identified are somehow real bug in the runit package, but

I don't think this is a correct solution: especially with runit as init, if a user disables a service, it should not start. A native disabled service on a runit system should definitely not start automatically at boot (even with a sysv instance); it may be different in a sysv system that uses runit as a service manager.
So the bug here is that for now, there is no tool for the sysadmin to tell the system to disable a service with runit and also with sysv (and any other init supported): it would be a job for update-rc.d, I already sent patches but they were rejected for several reason and the bug report is stuck. I plan to fix this in runit 2.1.2-46 or maybe -47.

just use 'servicename-wip' and keep it disabled by default untill your service is ready for use.

According to my testing

sv start dbus  ||  exit 1

will do it, or alternatively you can

sv up dbus  &&  sv check dbus  ||  exit 1

but

sv check dbus >/dev/null || exit 1

will not always work as expected, because if the requested status is down sv check can exit 0,
so before you use check make sure to set the wanted status

Also, of all dependencies, dbus is not easy to get it right, because there is a relevant time since when it reports itself as 'up' and when
it actually finishes its initialization, so you need a check file, see
https://salsa.debian.org/runit-team/run … dbus/check

Also if you use dbus from there be aware that the exec line of dbus should be

exec dbus-daemon --system --nofork --nopidfile 

without chpst. It used to work with chpst but it's broken since a recent upgrade in Debian

Correct: my answer is to make native runit services available all at once, in a runit-services[1][2] package, especially services that are involved in a chain of dependency. Again, right now I'm stuck there too, but I hope it will get a sponsor in future. If not I may also consider a Devuan package if Devuan Devs allow me.

[1] https://bugs.debian.org/cgi-bin/bugrepo … bug=986656
[2] https://salsa.debian.org/runit-team/run … /tree/next   (watch out, very experimental!)
[3] https://bugs.debian.org/cgi-bin/bugrepo … ug=1005309

Lorenzo

As soon as I have some extra time I'll try to provide scripts for those too, except udevd because I'm not 100% sure that it's safe to do all stage 3 with udev not running

Lorenzo

Hi,

[ also looking at the other thread  https://dev1galaxy.org/viewtopic.php?id=3628&p=2 ]
The getty-run package ships with a getty-S0 on serial that is disabled by default. Enabling it is usually enough for other virtualization environment like Qemu or Docker, but I've never run Xen so I don't know.. is the getty on hvc0 a requirement for Xen, or anyway a commonly required feature?
If that is the case I can ship a getty on hvc0 too so that the only thing left to do is to enable it.
Let me know!

Thanks,
Lorenzo

also tried a service from collection : haveged (thought i pick a simple one for starters), but not working succesfully..
gets timeout,

    # sv start haveged
    timeout: down: haveged: 7s, normally up

log :

    2021-02-11_11:01:16.37237 invoke-run: ERROR -1 in haveged: runscript didn't exit normally
    2021-02-11_11:01:16.37276 invoke-run: haveged : run exit code is -1
    2021-02-11_11:01:16.37279 invoke-run: haveged stopped

Ah! I've squeezed my brain a over that -1 a little bit and I think i've found the culprit:

please remove the symlink and the diversion on the sysv script in /etc/init.d/haveged (restore the original script, no symlink to sv);

rm /etc/init.d/haveged

dpkg-divert --remove /etc/init.d/haveged

then restart haveged

sv e haveged

Is it working now?

Look carefully at the output: it says that cron is down since 24s; the appendant log service is running with PID 2038 since 24s.
when it's working sv will show the following

~# sv s cron
run: cron: (pid 6920) 969s; run: log: (pid 6919) 969s

'ps ax' shows the runsv monitor, but not the cron process. The correct output would be

~# ps ax | grep cron
[...]
 6918 ?        Ss     0:00 runsv cron
 6919 ?        S      0:00 logger -p daemon notice -t cron-run
 6920 ?        S      0:00 /usr/sbin/cron -f
[...]

So cron it's definitely not working for you ( the same script works for me so it's hard to tell what's wrong from here);
Anacron.. it's possibly working (see below)

If you have more time to spend in debugging I suggest the following:

Anacron:
it's a "one shot",  it goes up and looks if there are tasks to do; when it's done it goes down. To check if it's working look at the appendant log

# cat /var/log/runit/anacron/current

if it works you'll see output similar to

2021-02-10_09:11:23.94073 Invoke-run: Starting anacron
2021-02-10_09:11:23.94277 Anacron 2.3 started on 2021-02-10
2021-02-10_09:11:23.94715 Normal exit (0 jobs run)
2021-02-10_09:11:23.96108 invoke-run: anacron stopped
2021-02-11_07:02:16.02720 Invoke-run: Starting anacron
2021-02-11_07:02:16.03099 Anacron 2.3 started on 2021-02-11
2021-02-11_07:02:16.03300 Will run job `cron.daily' in 5 min.
2021-02-11_07:02:16.03301 Jobs will be executed sequentially
2021-02-11_07:07:15.56730 Job `cron.daily' started
2021-02-11_07:19:35.70168 Job `cron.daily' terminated
2021-02-11_07:19:35.70172 Normal exit (1 job run)
2021-02-11_07:19:35.70406 invoke-run: anacron stopped

Cron:

• try to comment the 'set -e' line in the run script and then do a full restart with

  sv e cron

  if it's working there is some command that is failing for you in the script, before the exec line.

• you can turn on the verbose and debug mode in /etc/default/runit
  verbose prints start and stop marker in logs (like 'invoke-run: starting cron');
  debug prints in log the exit status of the run script; it can be cron's exit status or an shell exist status, it depends if it reaches the exec line or fails earlier (search for 'invoke-run: cron : run exit code is ')
  Cron does not have it's own appendant log service because it only logs to syslog: search in the system log

• there is a 'supervision tree log'. text there does not mean necessary an error, and is about every supervised service, but
  it's worth looking

  ~# ps ax | grep runsvdir
   1781 ?        Ss     0:00 runsvdir -P /etc/service log: ...........................................................................................................................................................................................................................................................................................................................................................................................................

  look for text in the dots, there is none for me right now

• As a last resort try to run cron manually, to check if there is an issue with cron in your system

  # /usr/sbin/cron -f

For now i don't have other ideas..

Hi (runit maintainer here),

During boot it first run all sysv scripts in runlevel 2, but it skips those for which a native runscript that matches the basename exists.
Then it starts all native runscripts that are enabled.
For example if you have a /etc/sv/ssh runit service, than the SNNssh sysv service will be skipped.

those are quite old, but still a good starting point for experimenting.
I maintain a collection https://salsa.debian.org/runit-team/run … collection
but please everybody, CAUTION*, those are meant to be used with runit>=2.1.2-36 and anyway are somehow experimental.
I plan to upload a catchall package that will properly install those (and more) runscripts into the system, but
it's unrealistic to expect to see it land into unstable before summer 2021.

last thing, for the brave souls that are willing to experiment, i accept requests for adding new runscripts at the condition that the person that does the request is available to test and report if it's working

Best,
Lorenzo

*especially if you are running a desktop environment, you either want to have dbus, elogind and sddm|lightdm|slim|etc.. all as runscripts or all as sysv script. Mixing wont work an you'll end up with a VT login.

Hi,

For now no, in future will be probably needed to avoid systemd lockin on certain Debian packages.
There is a commit [1] recently merged (but not yet uploaded to Debian archives) that makes opetmpfiles a dropin replacement to systemd-tmpfiles, so each package that has a dependency on systemd because of tmpfiles can use tmpfiles instead of systemd, if someone convince the maintainer of such package to change the dependency from 'systemd' to  ' systemd | systemd-tmpfiles '.
Only example for now is the php7.x-fpm package that need a rebuild on Devuan right now, but will be installable once the new version of opentmpfiles will be uploaded.
Same goes for opensysusers package.

Regards,
Lorenzo

[1] https://salsa.debian.org/debian/opentmp … c0948a0974