Hi!

Since I do not like UTC time (due to the minutes that are not all the same... details...), I made myself a TAI time zoneinfo file, so that my box is not so affected by those funny minutes... I have true SI seconds (not like Google's smeared time...).

svlogd is somehow a step back, because it uses UTC timestamps or no (human readable) timestamps...

Since the runit dev team is not fond of my idea, they suggested, that it would be u, who i ask, to add the attached patch (after thorough cross checking... i didn't even try to compile it... blush)...

Thx.

Bye.

ltime.patch.txt

Facts:

1. I had started dhcpcd too many times because my device names changed, and I was trying to get it working (yes, I should have killed or restarted the old dhcpcd instances instead of doing 'sudo dhcpcd')
2. I ran exactly: "sudo pkill -f dhcpcd"
3. The system immediately shut down (it did not reboot; it acted exactly as if I did "sudo shutdown -h now")
4. I saved everything in /var/log/socklog & faillog for later debugging

Any idea how this could have happened? Any idea where to look for clues?
Thanks!

The "sv shutdown" command does not work as expected, even while the "sv stop" command does. See the screenshot below:

Not only does the "sv shutdown" command return an error, but the service is still running. Note that the service was apparently stopped and then restarted (the process ID of the /usr/local/bin/houseportal application is different).

The "sv exit" command behaves in the same odd way, which is not surprising since the man page indicates that shutdown is based on exit..

I just downloaded, installed (and updated, as per the installation manual) void-live-x86_64-20230628-base.iso.

The Runit init scripts(/etc/runit/1, 2, 3) fail after a reboot after changing the coreutils for more POSIX ones. Examples of why is are using swapon(1) -a and halt -B. Those are not the only ones, I just don't remember more right now. This would be a huge milestone for making Void Linux embedded friendly, though I know this system does not cater to the embedded Linux community, I'd be very grateful if any core Void developer cared.

https://github.com/xplshn/AltSys contains a janky script that setups toybox+ubase+sbase(in that order) at /opt/ and changes the PATH variable in /etc/profile so that it works without breaking /etc/runit(unless you uninstall the coreutils).

We should mirror the release tags so that github will generate tarballs. This will make it easier to pull from this repo and build a binary.

sv(8) says:

The sv program can be sym-linked to /etc/init.d/ to provide an LSB init script interface. The service to be controlled then is specified by the base name of the "init script".

If sv is called with a base name other than sv: it exits 1 on timeout or trouble sending the command; if the command is status, it exits 3 if the service is down, and 4 if the status is unknown; it exits 2 on wrong usage, and 151 on error.

This isn't entirely true. If the service has a log, the exit code instead reflects the status of the log. In src/sv.c:154-176 you'll see rc updated if chdir("log") and svstatus_get() succeed, after which the if (lsb) branch to the switch will call done reflecting the log's status.

This strikes me as a bug in the code, not the man page.

https://github.com/sgn/orig-runit is a clone of the repo here -> https://www.mail-archive.com/[email protected]/msg01353.html

Should we move to it or keep the current version that's only the releases?

Another option is making a separate branch with it for historical purposes

LXC/LXD sends sigpwr signal to Pid 1 but it doesn‘t listen to it, thus stopping LXC/LXD from stopping the container correctly.

When the service's directory is removed and recreated, like during an xbps package reinstall, runsv will enter a broken state. Once in that state, a command to down the service will cause runsv to terminate the supervised process, but will fail to update the status file and possibly more, soft-locking.

The same bug happens for the log service if present, but presence of a log service is not needed.

Minimal reproducer

This can be done as a normal user

1. Have a <service> directory containing solely a run file and a supervise -> ../supervise symlink.

   #!/bin/sh
   
   exec 2>&1
   exec <some command here>

2. From the parent directory, run runsv <service>

3. Copy delete, and recreate <service>

4. From the same dir as step 2, run SVDIR=$(pwd) sv stop <service>

5. The supervised process will stop but the sv command will fail on timeout, reporting the supervised process' PID as the one it had before being terminated.
   Repeating the stop command will continue to fail and report that same invalid PID.
   Trying to start the service will immediately 'succeed', reporting the same PID.

I recommend using as the supervised process a program that outputs frequently, makes it easier to see when the supervised process is running/stopped. I using a simple binary that prints an incremented number each second.

I am going through the runit documentation, starting with the Q&A:

How do I make a service depend on another service
I have a service that needs another service to be available before it can start. How can I tell runit about this dependency?
Answer: Make sure in the ./run script of the dependant service that the service it depends on is available before the service daemon starts. The sv program can be used for that. E.g. the cron service wants the socklog-unix system logging service to be available before starting the cron service daemon, so no logs get lost:

$ cat /etc/sv/cron/run
#!/bin/sh
sv start socklog-unix || exit 1
exec cron -f
$
See also the documentation.

Following the "documentation" link above leads to this less clear description:

runit's service supervision resolves dependencies for service daemons designed to be run by a supervisor process automatically. The service daemon (or the corresponding run scripts) should behave as follows:
before providing the service, check if all services it depends on are available. If not, exit with an error, the supervisor will then try again.
write all logs through runit's logging facility. The runsv program takes care that all logs for the service are written safely to disk. Therefore there's no need to depend on a system logging service.
optionally when the service is told to become down, take down other services that depend on this one after disabling the service.
If you want to run service daemons that do not support service supervision as described above, please refer to this page about service dependencies I wrote some time ago.

I am not sure what "do not support service supervision" means. The service I depend on is also started through runit.

Following the this page link above leads to a third seemingly conflicting description:

Service dependency
If you really have a service that needs another service up and running before starting, you can use the svwaitup program included in the runit package.
Add a line like this to the service's run script:

#!/bin/sh
svwaitup 3 /service/tinydns /service/dnscache || exit 1
exec /example/service/startup
This will cause this service to start as soon as /service/tinydns and /service/dnscache were at least 3 seconds up and running.
For each service it depends on, add the corresponding service directory to the arguments of svwaitup.

Note that there is always a race condition, the service it depends on could die just in the moment it was 3 seconds up.

The svwaitup is nowhere to be found on a newly installed Void Linux (using void-live-x86_64-20230628-base.iso).

Which of these three pages should I believe?