1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
|
runit (2.2.0-4) unstable; urgency=medium
runsvchdir' s working directory is now configurable with the $RUNSVDIR
environment variable: the default is still /etc/runit/runsvdir.
This may be useful in nested runsvdir, such as user services instances.
Also, since this version, runsvchdir is installed in [/usr]/bin instead of
[/usr]/sbin; please remember to update local scripts, if any.
a series of old (~2014) unreleased patches from upstream has been
applied, affecting runsv and sv programs:
now 'sv check' properly checks that the service is in the requested state,
while before this change it always checked if the status was 'up', regardless
of the requested status.
This may break existing local scripts that rely on the previus behaviour,
please see sv(8) for details.
non root usage of update-service script is now possible and the script is
installed into [/usr]/bin instead of [/usr]/sbin; please remember to update
local scripts, if any.
-- Lorenzo Puliti <plorenzo@disroot.org> Mon, 15 Sep 2025 17:04:10 +0200
runit (2.1.2-61) unstable; urgency=medium
This version changes the way the policy-rc.d hack is integrated in runit: if you
don't have and use the /usr/sbin/policy-rc.d executable override mechanism
you are not affected by this.
Before this change, the policy-rc.d script was tested in invoke-run(8) so the
policy hack was effective for each runscript enabled either by a Debian
package installation or by a local script, at the only condition that the
invoke-run(8) interpreter was used.
Now invoke-run(8) no longer checks for policy-rc.d and the test has been
moved into scripts invoked only at Debian package intallation/upgrade
(/lib/runit/trigger_sv and /lib/runit-helper/runit-helper).
As a consequence the policy-rc.d hack can now prevent a runscript from
being enabled at package installation, even if the invoke-run interpreter
is not in use; on the other hand, if you enable a service with local scripts
or with update-service(8) the policy-rc.d hack is no longer effective in
denying such action.
In order to reduce the diff with upstream, the patch to move communication files
under /run has been dropped; the runit package now ships /etc/runit/stopit and
/etc/runit/reboot as symlinks with targets in /run.
The recommended way to test if runit is init now is
[ -f /etc/runit/stopit ];
previously was
[ -f /run/runit.stopit ];
the rest of the runit integration has been updated accordingly. Symlinks in
/etc/runit/ may be dangling in case runit is not init but this is not a mistake,
'stopit' and 'reboot' symlinks should never be removed.
For more details see https://smarden.org/runit/faq#readonlyfs .
-- Lorenzo Puliti <plorenzo@disroot.org> Wed, 30 Oct 2024 02:54:32 +0100
runit (2.1.2-60) unstable; urgency=medium
runit-init binary moved:
runit-init binary is now shipped in /usr/sbin/ , previously was under
[/usr]/lib/runit/ ; everything in package now refers to the new
location. To avoid breakage in custom configurations the package
temporarily ships a compatibility symlink, which will be removed after
Trixie release. Please make sure to update targets in scripts and
locally maintained symlinks, container entrypoints and the like:
the correct target now is [/usr]/sbin/runit-init.
/etc/service as symlink:
Since runit_2.1.2-7 /etc/service is shipped as symlink but before
2.1.2-5 it was shipped as directory; at the time there was no warning
to the user and no transition was arranged so old setups with /etc/service
as directory still exists today.
As other parts of the package may rely on /etc/service being a symlink, such
old setups are likely to become buggy in a way that is difficult or impossible
to fix.
Users with old installations are encouraged to convert /etc/service to a symlink
that points to /etc/runit/runsvdir/current; an example of code to perform the
conversion can be found at
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1069267
-- Lorenzo Puliti <plorenzo@disroot.org> Thu, 09 May 2024 23:24:51 +0200
runit (2.1.2-58) experimental; urgency=medium
Change in service layout:
Until now package and local services coexisted under /etc/sv/,
with dpkg handling services files as conffiles.
Since this version packages are allowed to ship their service under
/usr/share/runit/sv/; when they do so, /etc/sv/ becomes reserved for local
(supposedly modified) copy of that service.
When a service exists in both location, the copy in /etc/sv/ will have a higher
priority and tools such as update-service(8) and trigger_sv have been
updated to reflect this change.
update-service(8):
update-service(8) no longer requires full path of the service to add or
remove a service to system-wide supervision; first <service> is
searched in /etc/sv/<service>, then in /usr/share/runit/sv.current/<service>.
The full path is required only if <service> is in a different location.
-- Lorenzo Puliti <plorenzo@disroot.org> Fri, 08 Mar 2024 14:34:46 +0200
runit (2.1.2-51) experimental; urgency=medium
Invoke-run(8) now uses the env subdirectory to set variables for the
runscript with chpst's envdir; previously the subdirectory was conf.
This is documented in invoke-run manpage.
The cpsv(8) program shipped with this version of runit has a non
backward compatible change in the syntax in order to separate
option and commands.
-- Lorenzo Puliti <plorenzo@disroot.org> Sun, 04 Dec 2022 14:34:46 +0200
runit (2.1.2-50) unstable; urgency=medium
Deprecation of default/runit and $NAME:
* /etc/default/runit file is deprecated and will be removed in future,
equivalent settings can be obtained with 'verbose' and 'debug'
flag files.
* invoke-run will soon stop exporting the NAME variable for runscripts,
please see invoke-run(8) for details.
Flag Files:
* Several flag files that affect runit's behaviour can be placed under
/etc/runit/ directory; their name and effect is documented in the
/etc/runit/README file.
init-functions.d/40-runit and start-stop-daemon.runit wrapper:
* Since runit 2.1.2-49, when both a /etc/sv/foo runscript and a /etc/init.d/foo
sysv script exists, calls to the foo sysv script are masked and commands
are forwarded to the foo runscript. This is enabled by default and happens
not only during the boot sequence but also at runtime, because of the
40-runit lsb hijack. This behaviour is configurable with flag files.
* As an alternative to 40-runit, a start-stop-daemon zsh wrapper is available;
since init-functions are included in sysv scripts before start-stop-daemon
is called, in order to use the wrapper the 40-runit lsb hijack should be
disabled (it can be done with a flag file). The wrapper can be manually
enabled by diverting the real start-stop-daemon and replacing it with a
symlink to /lib/runit/start-stop-daemon.runit.
-- Lorenzo Puliti <plorenzo@disroot.org> Sun, 16 Oct 2022 17:29:28 +0200
runit (2.1.2-41exp1) experimental; urgency=medium
If you are using the policy-rc.d hack as a way to control systemd or sysv
services please be aware that runit's runscripts now check for the
/usr/sbin/policy-rc.d script via invoke-run(5) interpreter.
If the script returns 101 the service will be set down; this will prevent
services to start also during the boot process or when controlled via
sv program. See invoke-run(5) man page for more details.
-- Lorenzo Puliti <plorenzo@disroot.org> Wed, 31 Mar 2021 15:36:05 +0200
runit (2.1.2-38) unstable; urgency=medium
New runit-run package
Before runit 2.1.2-37 sysvinit and systemd integration were provided
as separate package ( runit-sysv and runit-systemd) but this design
proved to cause several RC bug (see #953875 and #934646):
all runit integrations are now merged into a new package called
runit-run that does not depends on any specific init.
This change only affects users that are using runit as supervision
suite under another init system.
Runit in container
You can now boot into a custom rundirectory by passing the
runitdir=yourcustomdir variable to the kernel command line.
The directory must exists under /etc/runit/runsvdir/ .
As a special case (mainly intended for containers), runit package
provides a 'solo' rundirectory: when this directory is selected, runit will
also skip all sysv instance of services: be aware that, if used as is, it will
start only a getty on tty1. This is documented in runit(8) manpage.
-- Lorenzo Puliti <plorenzo@disroot.org> Wed, 21 Oct 2020 18:32:31 +0200
runit (2.1.2-4) unstable; urgency=medium
Runit no longer provides /sbin/runsvdir-start symbolic link to
/etc/runit/2. Everything this package provides now directly
refers to /etc/runit/2, including systemd's service file, but
scripts and configuration outside may be need updated.
-- Dmitry Bogatov <KAction@gnu.org> Tue, 31 May 2016 21:51:28 +0300
runit (1.9.0-1) unstable; urgency=low
runit's default directory for services has been /var/service/ for
quite some years. The usage of the directory /var/service/ does
not comply with the Filesystem Hierarchy Standard (FHS) though,
and there are no signs that this will change.
With version 1.9.0 the runit upstream package switched from
/var/service/ to /service/ (which doesn't comply with the FHS
either).
The Debian package from now on uses /etc/service/, on upgrade from
previous versions of the runit Debian package, a compatibility
symlink /var/service -> /etc/service is retained. Nevertheless,
existing programs or scripts that deal with the contents of the
default directory for services should be adapted. Take a look at
the new update-service(8) program when doing so.
To be consistent with existing documentation, it is recommended to
create a compatibility symlink through
ln -s /etc/service /service
after installing the runit Debian package.
-- Gerrit Pape <pape@smarden.org> Thu, 08 May 2008 00:30:39 +0000
runit (1.4.1-1) unstable; urgency=low
With this version the runsvctrl, runsvstat, svwaitdown, and svwaitup
programs no longer are being installed, the functionality of these
programs has been incorporated into the sv program.
The documentation now suggest to put service directories by default
into the /etc/sv/ directory, and a list of frequently asked questions
with answers has been added.
-- Gerrit Pape <pape@smarden.org> Sat, 13 May 2006 14:55:09 +0000
|
