When using runit-user-session, I cannot squelch verbose logging for a script that wants to be run repeatedly because there is no user-controlled path checked for this. Even if there were, the idiom would be unclear because does one naturally want to override it on or off? Another approach might be for an individual runscript to be able to do it when it's not appropriate for that service, but that is not obviously how to implement either. (My example is mbsync from the isync package. I have not investigated runit-cron-snooze but it would not be suitable for me because I do not wish to replace proper cron!) Minor issue. Thanks!
Hi Andrew, is this about "invoke-run: starting foo" message from invoke-run or something else? Do you have /etc/runit/verbose file? If so, invoke-run can be changed so that a different path (inside /home/$user/) is tested for user services for system-wide services the default is not verbose, one has to touch the file to get the "invoke-run: starting foo" message I don't know the isync package but, in case it helps, you can use snooze + runit to get a "timer-like" service without the runit-cron-snooze package. Best, Lorenzo
Hi Andrew, is this about "invoke-run: starting foo" message from invoke-run or something else? Do you have /etc/runit/verbose file? If so, invoke-run can be changed so that a different path (inside /home/$user/) is tested for user services for system-wide services the default is not verbose, one has to touch the file to get the "invoke-run: starting foo" message I don't know the isync package but, in case it helps, you can use snooze + runit to get a "timer-like" service without the runit-cron-snooze package. Best, Lorenzo
ping did I understand your issue, or it was something else? if it's the invoke-run message, this patch could fix it--- /lib/runit/invoke-run 2026-05-16 01:58:01.000000000 +0200 +++ /lib/runit/invoke-run-new 2026-08-14 09:07:51.911557587 +0200 @@ -91,17 +91,19 @@ fi fi
ping did I understand your issue, or it was something else? if it's the invoke-run message, this patch could fix it--- /lib/runit/invoke-run 2026-05-16 01:58:01.000000000 +0200 +++ /lib/runit/invoke-run-new 2026-08-14 09:07:51.911557587 +0200 @@ -91,17 +91,19 @@ fi fi
Hi Lorenzo,
Sorry, have been on holiday!
This is exactly the issue, yes!
I'm not a big fan of the code dupliction there, I'd rather an RETC
variable were used to define the config directory, so the output could
be defined only once, and/or a helper function like is_verbose()
although also without duplicate user-service detection logic.
I also just noticed this:
if [ "$(id -u)" -ge 1000 ] && [ -d /home/"$(id -u -n)" ] ; then
I don't think that's a sound way of detecting invocation for non-system
service. To understand if the user is a system user requires parsing
/etc/login.defs, UID_MIN may not be 1000. Is it enough to detect != 0?
Secondly, the home directory could be anywhere.
How about something like this?
RETC=/etc/runit
IFS=: read -r RUSER pw uid gid gecos home shell <<EOF
$(getent passwd "$(id -u)" 2>/dev/null)
EOF
if [ "${uid:-0}" -ne 0 ] && [ -d "$home" ]; then
RETC="$home"/.runit
else
unset RUSER
fi
unset pw uid gid gecos home shell
I think a various error cases get indirect detection here, so we can
keep it readable.
Then read "$RETC/verbose" to test verbosity. There may be other things
that could benefit from this snippet.
Hi Lorenzo,
Sorry, have been on holiday!
This is exactly the issue, yes!
I'm not a big fan of the code dupliction there, I'd rather an RETC
variable were used to define the config directory, so the output could
be defined only once, and/or a helper function like is_verbose()
although also without duplicate user-service detection logic.
I also just noticed this:
if [ "$(id -u)" -ge 1000 ] && [ -d /home/"$(id -u -n)" ] ; then
I don't think that's a sound way of detecting invocation for non-system
service. To understand if the user is a system user requires parsing
/etc/login.defs, UID_MIN may not be 1000. Is it enough to detect != 0?
Secondly, the home directory could be anywhere.
How about something like this?
RETC=/etc/runit
IFS=: read -r RUSER pw uid gid gecos home shell <<EOF
$(getent passwd "$(id -u)" 2>/dev/null)
EOF
if [ "${uid:-0}" -ne 0 ] && [ -d "$home" ]; then
RETC="$home"/.runit
else
unset RUSER
fi
unset pw uid gid gecos home shell
I think a various error cases get indirect detection here, so we can
keep it readable.
Then read "$RETC/verbose" to test verbosity. There may be other things
that could benefit from this snippet.
Hi Andrew, I agree that invoke-run could benefit from being polished and rationalized, but I'll do that in a later stage: first I want to finish missing/wip features (cgroups, user services, maybe socket activation), then I'll consider invoke-run finished and I'll start working on refining code In principle, yes, but practically this looks a slippery-slope that may end in a can of worms: * systemd-sysusers ignore SYS_UID_MIN/MAX (last time I checked, it used 'r' lines in sysusers.conf files) * adduser can be forced to create a human user with a UID < UID_MIN * UID_MIN/SYS_UID_MIN/MAX can be changed after the system is installed, new limits are effective only for packages installed later * redefining non-system services in runit requires changes in several places (at least cpsv, update-service, trigger_sv, runit-user-session) we don't want to start a user session for a system user, I think; apparently systemd uses uid >= 1000 but it starts a user session also for root, but I don't think it starts one for system users (not sure about this). I think runit's current uid >=1000 is a semplification but a reasonable one and I'm not sure it's feasible to change it. I'm open to not hardcode home to /home/username in future, but I see this as an enhancement, first let me complete the support for user session with uid>=1000 and home=/home/username Right now I'm going to quickly fix the issue reported and take note of the rest for future development Best, Lorenzo
Hello, Bug #1143778 in runit reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/debian/runit/-/commit/1785ac2262357dddbfe98ff50f2d1b421dac1c34 ------------------------------------------------------------------------ invoke-run: allow to control verbosity for user services use a "/home/$user/.runit/verbose" flag file instead of the system-wide /etc/runit/verbose flag file Closes: #1143778 ------------------------------------------------------------------------ (this message was generated automatically) -- Greetings https://bugs.debian.org/1143778
Hello, Bug #1143778 in runit reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/debian/runit/-/commit/1785ac2262357dddbfe98ff50f2d1b421dac1c34 ------------------------------------------------------------------------ invoke-run: allow to control verbosity for user services use a "/home/$user/.runit/verbose" flag file instead of the system-wide /etc/runit/verbose flag file Closes: #1143778 ------------------------------------------------------------------------ (this message was generated automatically) -- Greetings https://bugs.debian.org/1143778
We believe that the bug you reported is fixed in the latest version of
runit, which is due to be installed in the Debian FTP archive.
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to 1143778@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Lorenzo Puliti <plorenzo@disroot.org> (supplier of updated runit package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Fri, 02 Oct 2026 16:19:22 +0200
Source: runit
Architecture: source
Version: 2.3.1-5
Distribution: unstable
Urgency: medium
Maintainer: Lorenzo Puliti <plorenzo@disroot.org>
Changed-By: Lorenzo Puliti <plorenzo@disroot.org>
Closes: 923449 1105907 1143778 1144866
Changes:
runit (2.3.1-5) unstable; urgency=medium
.
* default-syslog: silence socklog-check output
* add runsv-cg for setting up cgroups on runit
* stage 1: setup (mount) cgroup2
* add a manpage for runsv-cg
* runsv-cg:
- fix typo
- do not require runit as init
* use /sys/fs/cgroup/runit for runit's services cgroups
* invoke-run, finish-exec: add optional cgroup support (Closes: #923449)
* invoke-run:
- update manpage for cgroups
- allow users to control verbosity for user services (Closes: #1143778)
- clarify home directory for user services in manpage
* runit-run: fix race at systemd shutdown.
+ thanks to Jan Braun <janbraun@gmx.de> (Closes: #1144866)
* getty-run: always test for fuser before calling it (Closes: #1105907)
* d/control: use dh-sequence for dh_runit and dh_sysuser
* d/control: drop {runit:Breaks} and {runit:Conflicts} for runit
* d/control (runit-run): drop ancient Breaks and Replaces
* bump S-V to 4.7.4, no changes required
Checksums-Sha1:
8b86709175d2df04fa1cccd7452c10b8a6d24deb 2265 runit_2.3.1-5.dsc
4d5550a17d5ffb8d9270bb139549e2a7125a2a41 90448 runit_2.3.1-5.debian.tar.xz
bc4b5c13462a9f9fcd420ac476b071a85cee09c9 6934 runit_2.3.1-5_amd64.buildinfo
Checksums-Sha256:
538a06cba27ef5f51e6e48b49d5bfaf98789a2ee635fda439d4bc53e590230f0 2265 runit_2.3.1-5.dsc
4a13705a96dd79d19555584242ba51420b1e871da76ae07dd25845f2a5ed1a21 90448 runit_2.3.1-5.debian.tar.xz
4ee723a42e71c06cbfe1953006b92280cb0ed43b8c499e376c20b0306a7a43ac 6934 runit_2.3.1-5_amd64.buildinfo
Files:
f33ea6456a4991f34f5d4a7dd1cc03ef 2265 admin optional runit_2.3.1-5.dsc
4a1892bbd1e1c971bcc40c39cab9baf3 90448 admin optional runit_2.3.1-5.debian.tar.xz
99e305bf0d8d87105b3ed75831c6ef6b 6934 admin optional runit_2.3.1-5_amd64.buildinfo
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEE2ji91PGnrxOd1bVNxxYb07RU7gMFAmrBSAYACgkQxxYb07RU
7gNgaQ//V9hWXyGgsIvtwkn6jdgFmptQJxKNtJMsGSPJLGLDWg5uUfYqtycc5FQi
JwsG4xNckWwnqQB0RiBIVDL3YlxWYf0paZYIjNLoquBtFJZt0WrpYqgmSYJM+Hnj
Tv7rle73pS8i6KzGtu0zkC02M6U/06oCYHEcqRiKlbxlnVfUpqKUb4rAzYQj+BW5
OZSZONKNPBt1EKKY3YCUYCltLvpss6CnGod8lOQZ1nqi52Tugupi+9Rk7UvM5hOy
i+zQA3GbfDyaFO5tE4vRc0dWyQsFhtKim5tXBGPmrhU8KecUuXGr4DClVbOSddqC
lrwm8LzFUdkzzd/tCpDcGUcaQIpiFbx+ojcd24oDBc9G+evgzmgW1r6fjOT57ZXu
zqRSGptKaUQrJijI9ZzerpUtT2xvK9HP/diC14RQhguvZZk5K7pe4lNKgS6rYChu
q7k7xsURuzz4/SavuX3N+zTfRiWWU8g0e/aahQHCIiUkwDIH2IFDYkjxJUM/oy2R
McYp1iOV6SMss8ePikjrqZmkowvCipGqV7PzzwYB/KrQX7doHZY6EiV4fGnUzev5
Tme5wvuz5L/VvwhZ0FsyS4NUIPT0V5oEI0MfomyzdjpvsFZlRZO+NgZtCRez6HCw
aGvo2fYYOud0F56kWLmbuXnzRQfiZld3p2z60wq+mZF7s62zDdc=
=XwEp
-----END PGP SIGNATURE-----