From: Leah Neukirchen
Date: Sun, 03 Nov 2024 17:26:54 +0100
> Yes, if each service of your supervision tree has a $service/log
> service, you don't need anything global else.
I can remove socklog-void and disable socklog-unix and nanoklogd;
correct?
Then focus on the daemon and logging specific
nabled socklog-unix and nanoklogd.
> "Enabled" within the limits of my understanding.
>
> Susequently found
> https://smarden.org/runit/dependencies stating "write all logs through
> runit's logging facility. ... Therefore there's no need to depend on a
>
thin the limits of my understanding.
Susequently found
https://smarden.org/runit/dependencies stating "write all logs through
runit's logging facility. ... Therefore there's no need to depend on a
system logging service." nanoklogd and svlogtail aren't needed to
monitor
Hi, version 2.2.0 of the runit package is available through
https://smarden.org/runit/
Thanks to the community, and especially to Alex Efros and Z. Liu for
recently consolidating a great set of commits, this version includes
patches from Gentoo, Debian, and Void Linux to properly build with
Get and confirm it, thanks for the reply.
On Wed, Sep 4, 2024 at 7:56 PM Leah Neukirchen wrote:
>
> Zhixu Liu writes:
>
> > Hi,
> >
> > I'm trying to keep runit remaining available in gentoo's official portage
> > tree,
> > see https://
Zhixu Liu writes:
> Hi,
>
> I'm trying to keep runit remaining available in gentoo's official portage
> tree,
> see https://bugs.gentoo.org/938282 . I setup a github repo at
> https://github.com/clan/runit/ for this purpose, following is what I'm doing
> now
Hi,
I'm trying to keep runit remaining available in gentoo's official portage tree,
see https://bugs.gentoo.org/938282 . I setup a github repo at
https://github.com/clan/runit/ for this purpose, following is what I'm doing
now:
1. fix all the compilation error(s)
2. eliminate
On Thu, 22 Aug 2024 16:01:12 +0200
"Lorenzo via supervision" wrote:
> Hello,
>
> On Thu, 22 Aug 2024 15:54:47 +0300
> "Alex Efros via supervision" wrote:
>
> > Hi!
> >
> > Now, 10 years later, it looks like some maintenance is needed
&g
Hello,
On Thu, 22 Aug 2024 15:54:47 +0300
"Alex Efros via supervision" wrote:
> Hi!
>
> Now, 10 years later, it looks like some maintenance is needed because
> of GCC changes. Otherwise chances are runit will eventually die.
>
> See https://bugs.gentoo.org/938282
Hi!
Now, 10 years later, it looks like some maintenance is needed because of
GCC changes. Otherwise chances are runit will eventually die.
See https://bugs.gentoo.org/938282 for more details.
--
WBR, Alex.
> > effectively prevents svlogd from deleting the file its about to
> > process,
> > which can happen when system time is far behind. Cheers.
>
> You might like to also consider opening a PR in Void's 'runit'
> repo:
>
> https://github.com/void-linux/runit
>
>
> Alexis.
>
--
Andrew AV. Stiegmann
. Cheers.
You might like to also consider opening a PR in Void's 'runit'
repo:
https://github.com/void-linux/runit
Alexis.
Evening folks. Wanted to share a patch I recently put together to prevent
a runaway busyloop in svlogd when system time is far behind. It
effectively prevents svlogd from deleting the file its about to process,
which can happen when system time is far behind. Cheers.
diff --git a/src/svlogd.c b
Laurent Bercot schrob:
> IIRC, 1. is intrinsic to runit, there is no way to redirect the default
> logging, [...]
There is: the default logging simply goes to runsvdir's stdout. You can
connect that in /etc/runit/2 to wherever you like.
> a runit service should use the runit lo
Hi, I am using the Artix Linux runit service for OpenVPN, available here:
https://gitea.artixlinux.org/packages/openvpn-runit
Sounds like two compounding problems:
1. the default logging place for the runit supervision tree is the same
terminal you're using to log in
2. there
Hi, I am using the Artix Linux runit service for OpenVPN, available here:
https://gitea.artixlinux.org/packages/openvpn-runit
However, at boot time the service is throwing a huge output to the tty and
I have to wait it to finish to get to the login prompt (I'm not using a
display manager).
On 2023-07-31 17:14:16-0400, Steve Litt wrote:
> Referring to http://smarden.org/runit/runscripts.html , some of the run
> scripts have a note saying "This service needs a log service to be set
> up" and some don't. With run scripts not at that URL and not available
> t
Hi all,
Referring to http://smarden.org/runit/runscripts.html , some of the run
scripts are marked "This service needs a log service to be set up", and
others aren't. When making my own run scripts, how do I know whether
the daemon requires a log service?
Thanks,
SteveT
Steve Li
Hello,
if you're still interested in this, I added the essential stage 1 boot scripts
to my repo: https://codeberg.org/AwesomeAdam54321/LL_Runit_Scripts
Hi,
On Sat, 1 Oct 2022 06:07:28 +0200
Paul Gerdes wrote:
> Hello everyone. I am trying to get a minimal ubuntu desktop
> installation without systemd.
> Do you know if there is a way to get runit, openrc or sysvinit
> running as an init replacement on modern ubuntu? Could you please
ding the
> init=/sbin/runit-init parameter to the GRUB config, specifically the
> list of parameters that are given to the kernel.
>
> The init could also be set by changing the /sbin/init symlink to
> point to runit-init.
Before doing that you need to make sure that your system w
On 1 October 2022 04:07:28 UTC, Paul Gerdes wrote:
>Hello everyone. I am trying to get a minimal ubuntu desktop installation
>without systemd.
>Do you know if there is a way to get runit, openrc or sysvinit running as
>an init replacement on modern ubuntu? Could you please give me a G
Hello everyone. I am trying to get a minimal ubuntu desktop installation
without systemd.
Do you know if there is a way to get runit, openrc or sysvinit running as
an init replacement on modern ubuntu? Could you please give me a Guide on
how to install it and set it up?
Runit Packages are already
Hello Alexis,
On Thu, Sep 29, 2022 at 10:12:49PM +1000, Alexis wrote:
> João writes:
>
> > The Void linux manual shows gpg-agent running as an example, but they
> > don't show
> > the run script, so I don't know how they set it up.
> > https://docs.voidlinux.org/config/services/user-services.htm
Guillermo writes:
The combination of Duncaen's run script, and the Void Handbook's
example /etc/sv/runsvdir-/run script, at least if used
verbatim, does not appear to set up GPG_TTY. gpg-agent might
start,
but I'm not sure if things will work well if, e.g., it wants to
run
the pinentry pr
El jue, 29 sept 2022 a las 9:22, Alexis escribió:
>
> João Pedro Malhado writes:
>
> > The Void linux manual shows gpg-agent running as an example, but
> > they
> > don't show
> > the run script, so I don't know how they set it up.
> > https://docs.voidlinux.org/config/services/user-services.html
>
João Pedro Malhado writes:
The Void linux manual shows gpg-agent running as an example, but
they
don't show
the run script, so I don't know how they set it up.
https://docs.voidlinux.org/config/services/user-services.html
Duncaen's run script for gpg-agent is here:
https://github.com/Dunc
Hello Guillermo,
On Wed, Sep 28, 2022 at 03:46:01PM -0300, Guillermo wrote:
> El mar, 20 sept 2022 a las 18:51, João escribió:
> >
> > I would like to have gpg-agent running under runit supervision on a user
> > runsvdir, but I have been unable to write a run script that wo
I'd have to assume that it would be achievable by patching the support
back in, but at that point you are effectively maintaining your own fork
of GPG-Agent.
On 9/29/22 09:20, João wrote:
Hello Alyssa,
On Mon, Sep 26, 2022 at 05:04:08PM +, Alyssa Ross wrote:
Not an answer to your questio
Hello Alyssa,
On Mon, Sep 26, 2022 at 05:04:08PM +, Alyssa Ross wrote:
> Not an answer to your question, but you might be interested to know
> before you spend too much time on it that GnuPG is removing support for
> running gpg-agent supervised:
>
> https://dev.gnupg.org/rGca5d5142c6d6eaba45
El mar, 20 sept 2022 a las 18:51, João escribió:
>
> I would like to have gpg-agent running under runit supervision on a user
> runsvdir, but I have been unable to write a run script that works.
> Would anyone have an example run script for gpg-agent, or be able to offer any
>
João writes:
> I would like to have gpg-agent running under runit supervision on a user
> runsvdir, but I have been unable to write a run script that works.
> Would anyone have an example run script for gpg-agent, or be able to offer any
> pointers?
Not an answer to your question, b
Hello everyone,
I would like to have gpg-agent running under runit supervision on a user
runsvdir, but I have been unable to write a run script that works.
Would anyone have an example run script for gpg-agent, or be able to offer any
pointers?
Many thanks,
João
Hi all,
I'm maintaining runit in Debian and I have a bug report [1] on the
customized control of runsv.
The standard behavior appears to be that first, files in
service/control/ are checked and then, only if they don't exists or
return nonzero runsv proceeds to send the appropri
Guillermo said on Sat, 27 Nov 2021 17:05:14 -0300
>This was meant for the mailing list. I accidentally replied to the
>author instead. Sorry Leah!
>
>El mar, 23 nov 2021 a las 9:18, Leah Neukirchen escribió:
>>
>> [...] This seems to be due to runit(8) before ex
This was meant for the mailing list. I accidentally replied to the
author instead. Sorry Leah!
El mar, 23 nov 2021 a las 9:18, Leah Neukirchen escribió:
>
> [...] This seems to be due to runit(8) before execing
> into the stages:
>
> sig_unblock(sig_cont);
> s
Leah Neukirchen said on Tue, 23 Nov 2021 13:17:58 +0100
>Hello,
>
>During debugging a ksh issue (https://github.com/ksh93/ksh/issues/301),
>we noticed that many processes on a Void Linux system booted with runit
>are ignoring SIGCONT. This seems to be due to runit(8) before ex
Hello,
During debugging a ksh issue (https://github.com/ksh93/ksh/issues/301),
we noticed that many processes on a Void Linux system booted with runit
are ignoring SIGCONT. This seems to be due to runit(8) before execing
into the stages:
sig_unblock(sig_cont);
sig_ignore(sig_cont
Am 27.11.19 um 21:33 schrieb J. Lewis Muir:
> On 11/25, J. Lewis Muir wrote:
>> Is runit hosted in a public source code repo? If so, where?
>>
>> Are patches to fix runit compiler warnings on RHEL 7 welcome?
>
> I have patches now. Is there a public source code repo
Am 02.12.19 um 22:58 schrieb Laurent Bercot:
>> I see something called sdnotify-wrapper, so maybe I should have a look
>> at that? (It was mentioned to me off-list.)
>
> sdnotify-wrapper will only be useful if your daemon is using the
> NOTIFY_SOCKET mechanism (aka sd_notify()) to tell systemd wh
t and converting it using the
nosh toolset's convert-systemd-units command
(http://jdebp.uk./Softwares/nosh/guide/commands/convert-systemd-units.xml),
one obtains the following, which demonstrates that there are extra steps
involved and provides at least a pointer to how a "run"
On Fri Oct 16, 2020 at 2:35 PM -03, Kian Kasad wrote:
> I'm trying to have a runit service spawn `/usr/bin/ly` in a certain tty
> (tty2). I've tried redirecting std{in,out,err} to the tty:
>
> exec /usr/bin/ly /dev/tty2 2>&1
>
> but this didn't work.
>
I'm trying to have a runit service spawn `/usr/bin/ly` in a certain tty
(tty2). I've tried redirecting std{in,out,err} to the tty:
exec /usr/bin/ly /dev/tty2 2>&1
but this didn't work.
I tried the openvt(1) program, which has a flag `-e` to exec the program
instead of for
Hello,
I was trying to get runit-init working inside a docker container as PID 1. The
problem I'm running into is shutting down runit. I have the ctrlaltdel handler
configured to `touch /etc/runint/stopit` && chmod 100. This causes runit to
execute stage 3, and then try to `
On Mon Aug 17, 2020 at 9:46 AM -03, Guillermo wrote:
> El dom., 16 ago. 2020 a las 11:56, Érico Nogueira escribió:
> >
> > I was looking into runit version history, and was wondering if there's
> > anywhere I could access actual version control of its source.
>
There is a Git repository, actually:
git clone http://smarden.org/git/runit.git/
Source: https://www.mail-archive.com/supervision@list.skarnet.org/msg01353.html
Oh, thanks for the archeological find! I had completely forgotten
about it. Sorry.
--
Laurent
El dom., 16 ago. 2020 a las 11:56, Érico Nogueira escribió:
>
> I was looking into runit version history, and was wondering if there's
> anywhere I could access actual version control of its source.
There is a Git repository, actually:
git clone http://smarden.org/git/runit.git/
On Sun Aug 16, 2020 at 12:22 PM -03, Laurent Bercot wrote:
> >I was looking into runit version history, and was wondering if there's
> >anywhere I could access actual version control of its source. It is
> >possible to assemble a rough history by fetching all the releases
I was looking into runit version history, and was wondering if there's
anywhere I could access actual version control of its source. It is
possible to assemble a rough history by fetching all the releases, such
as done in [1], but it would be nice to have an actual complete history,
if s
Hi!
I was looking into runit version history, and was wondering if there's
anywhere I could access actual version control of its source. It is
possible to assemble a rough history by fetching all the releases, such
as done in [1], but it would be nice to have an actual complete history,
if s
I was wondering if it is possible to get a silent boot without having to
modify runit itself. With systemd, the `quiet` kernel parameter acheives
this. Is there anything similar for runit to prevent messages being
displayed to the tty?
No, runit hardcodes stdout and stderr to /dev/console. In
I was wondering if it is possible to get a silent boot without having to
modify runit itself. With systemd, the `quiet` kernel parameter acheives
this. Is there anything similar for runit to prevent messages being
displayed to the tty?
Also I tried looking in the mailing list archives, but
I patched runit-2.1.2 (ALTLinux build) to handle SIGPWR on systems which
support it.
SIGPWR cause immediate system shutdown just like SIGCONT with executable
/etc/runit/stopit present in system.
It works with LXD for me.
mx
---
diff -Naur --new-file a/runit-2.1.2/man/runit.8 b/runit-2.1.2/man
will the setting achieved by this very ioctl() call survive after
exec()ing into another binary (s6-svscan/stage 2) ?
Testing on s6-linux-init 1.0.4.0 shows that a SIGWINCH is sent to
s6-svscan on kbrequest after s6-linux-init has performed the ioctl.
So, the answer seems to be yes.
Having
25.02.2020, 10:08, "Jonathan de Boyne Pollard"
:
> Yes. First: This is a kernel virtual terminal thing not a console
> thing. Strictly speaking, it is doing it wrongly to access it through
> the console device, which is not necessarily a KVT. Second: The
> mechanism does not require an open file d
25.02.2020, 10:08, "Jonathan de Boyne Pollard"
:
>> Of course, but once the fd is closed, /dev/console should not have
>> any impact on the process, so would a kbrequest still reach it?
>
> Yes. First: This is a kernel virtual terminal thing not a console
> thing. Strictly speaking, it is doing
24.02.2020, 23:25, "Laurent Bercot" :
> However, I was not aware that kbrequest needed a special ioctl call
> before it can be accepted, so thank you for that; I'll add the call
> to s6-l-i.
will the setting achieved by this very ioctl() call survive after
exec()ing into another binary (s6-svscan/
On 29.02.2020 21:20, Guillermo wrote:
El mié., 26 feb. 2020 a las 5:07, innerspacepilot escribió:
I have checked openrc and busybox - both support SIGPWR.
BusyBox init does support SIGPWR, it is equivalent to SIGUSR1, the
signal sent by the 'halt' applet. However, if by "openrc" you mean
openrc
So, I have created a patch for runit to support SIGPWR.
https://pastebin.com/PXhUp5B9
Laurent & others, please review.
It is not for mainline, it is a patch for linux only (no defines needed).
I will offer it to linux distributions based on runit, If no errors found.
El mié., 26 feb. 2020 a las 5:07, innerspacepilot escribió:
>
> I have checked openrc and busybox - both support SIGPWR.
BusyBox init does support SIGPWR, it is equivalent to SIGUSR1, the
signal sent by the 'halt' applet. However, if by "openrc" you mean
openrc-init running as process 1, then no,
ns that you'll get the last power change event set
by the person that *did* use the signal properly.
Moreover, not only is there an existing mechanism in such programs,
there are *several* existing mechanisms. And they don't even all use
signals. The program being run could be anythi
It might be plain ignorance on my side but is there a possibility
that some malicious outsider's intent be able to induce a SIGPWR
signal just to fool the system to shut down? If so then hardcoding
it as an autoresponse would be perceived as a weakness. The choice
for any sysadmin to use the kern
Fri, Feb 28, 2020 at 07:39:47AM +0100, Jan Braun wrote:
> The Linux kernel uses SIGPWR to tell init "there's a power failure
> imminent". There's a difference to "please shutdown the system", even if
> (current versions of) busybox and openrc choose to shutdown the system
> when told about an immi
innerspacepilot schrob:
> I have checked openrc and busybox - both support SIGPWR.
>
> So I see no reason to change lxd behaviour, unless some realworld
> software uses SIGPWR.
*sigh* We've been here before.
The Linux kernel uses SIGPWR to tell init "there's a power failure
imminent". There's a d
I have checked openrc and busybox - both support SIGPWR.
So I see no reason to change lxd behaviour, unless some realworld
software uses SIGPWR.
On 24.02.2020 18:26, Serge E. Hallyn wrote:
On Mon, Feb 24, 2020 at 04:12:31PM +0300, innerspacepilot wrote:
On 24.02.2020 13:23, Laurent Bercot wrot
El mar., 25 feb. 2020 a las 6:08, Jonathan de Boyne Pollard escribió:
>
> Laurent Bercot:
> > Of course, but once the fd is closed, /dev/console should not have
> > any impact on the process, so would a kbrequest still reach it?
>
> Yes.
Also, I tested it :) I added an open2("/dev/tty0", O_RDONLY
Laurent Bercot:
Of course, but once the fd is closed, /dev/console should not have
any impact on the process, so would a kbrequest still reach it?
Yes. First: This is a kernel virtual terminal thing not a console
thing. Strictly speaking, it is doing it wrongly to access it through
the con
Laurent Bercot:
What piece of software sends SIGRTMIN+3 to pid 1 when you're not
running systemd?
*
http://jdebp.uk./Softwares/nosh/guide/commands/system-control.xml#SYSTEMCONTROL
(-:
s6-linux-init has a suitable open file descriptor. It is its standard
input, before it closes it to do the slashdev test.
Of course, but once the fd is closed, /dev/console should not have any
impact on the process, so would a kbrequest still reach it?
--
Laurent
El lun., 24 feb. 2020 a las 19:49, Laurent Bercot escribió:
>
> So there is no fd to call the ioctl on, and no way for a user to trigger
> a kbrequest.
s6-linux-init has a suitable open file descriptor. It is its standard
input, before it closes it to do the slashdev test.
G.
El lun., 24 feb. 2020 a las 19:25, Laurent Bercot escribió:
>
> I purposefully did not add a default SIGWINCH handler, because
> sysvinit does not come with a default kbrequest in /etc/inittab.
> I added a SIGPWR handler that performs a regular poweroff because
> it sounds like a sane default for
However, I was not aware that kbrequest needed a special ioctl call
before it can be accepted, so thank you for that; I'll add the call
to s6-l-i.
Scratch that. s6 never uses /dev/console as input: s6-l-i redirects
stdin to /dev/null. (This is intentional, and is not changing.)
So there is no
I purposefully did not add a default SIGWINCH handler, because
sysvinit does not come with a default kbrequest in /etc/inittab.
I added a SIGPWR handler that performs a regular poweroff because
it sounds like a sane default for a power failure.
I suppose I could add an empty SIGWINCH script by
The keyboard signal can actually be set to any signal less than or
equal to NSIG with the KDSIGACCEPT ioctl. sysvinit just happened to
pick SIGWINCH for that, and so did systemd and nosh, presumably for
compatibility.
El dom., 23 feb. 2020 a las 20:53, Laurent Bercot escribió:
>
> Both SIGPWR an
in this case systemd compatibility can be trivially achieved,
so there is no real reason to abstain from it.
"systemd compatibility" makes no sense here. We are talking about
runit or s6 as an init system: by definition, in that context, there
is no systemd, no interaction wi
On Mon, Feb 24, 2020 at 04:12:31PM +0300, innerspacepilot wrote:
> On 24.02.2020 13:23, Laurent Bercot wrote:
> > > SIGRTMIN+3 should also be caught and processed.
> >
> > What piece of software sends SIGRTMIN+3 to pid 1 when you're not
> > running systemd?
> >
> > --
> > Laurent
> >
> Looking
On 24.02.2020 13:23, Laurent Bercot wrote:
SIGRTMIN+3 should also be caught and processed.
What piece of software sends SIGRTMIN+3 to pid 1 when you're not
running systemd?
--
Laurent
Looking at lxc sources (src/lxc/lxccontainer.c:2084) nothing will, until
you block SIGRTMIN+3 signal.
Eve
24.02.2020, 11:23, "Laurent Bercot" :
>> SIGRTMIN+3 should also be caught and processed.
why only this one and not ALL of the real time signals ?
> What piece of software sends SIGRTMIN+3 to pid 1 when you're not
> running systemd?
in this case systemd compatibility can be trivially achieved,
so
SIGRTMIN+3 should also be caught and processed.
What piece of software sends SIGRTMIN+3 to pid 1 when you're not
running systemd?
--
Laurent
On 24.02.2020 02:53, Laurent Bercot wrote:
s6 should also catch SIGWINCH (keyboard request) and let the user handle
it via a hook executable if the signal exists btw. dunno if it
already does so.
Both SIGPWR and SIGWINCH are caught in the latest s6 git head.
Release coming whenever real li
have you ever used s6 as process #1 on any other platform than Linux ?
i bet you have not even tried to do so on any of the BSDs.
The BSDs are a different kind of beast: they're much more tightly
integrated than your run-of-the-mill Linux distro, and you can't
easily switch out one of the compon
s6 should also catch SIGWINCH (keyboard request) and let the user handle
it via a hook executable if the signal exists btw. dunno if it already does so.
Both SIGPWR and SIGWINCH are caught in the latest s6 git head.
Release coming whenever real life stop throwing things at me and I
can act
18.02.2020, 10:39, "Laurent Bercot" :
> you're telling me that s6-svscan needs to understand SIGPWR in case the
> kernel wants to signal a power failure, you actually have a good point,
> and yes, I should implement SIGPWR support when this signal exists.
BTW:
have you ever used s6 as process #1
18.02.2020, 10:39, "Laurent Bercot" :
> An additional reason is that signaling init is not a casual operation;
> instead it's part of a very limited API between the kernel and user
> space, to be used in very controlled, exhaustively listed, situations.
right.
> Now, *as a separate conversation*,
> Most init systems allow the SIGPWR behavior to be configured.
> This includes Upstart, systemd, and my own "little init":
>
> https://gitlab.com/chinstrap/linit#configuration
>
> I provide a guide for using linit with runit here, but the process is
> exper
On Tue, Feb 18, 2020 at 09:39:14AM +, Laurent Bercot wrote:
> In the former case, lxd *emulates* a kernel, and is supposed to adapt
> to every kind of init that runs in a container, so it should follow
> existing conventions and be able to adapt to every init. And that's
> exactly why the lxc.s
at we were talking about. We were talking about using
runit as pid 1 in a container. I just used s6 and SIGPWR-as-sent-by-lxd
as an illustration of why patching software is always more complicated
than using configuration switches. And I stand by my point.
Now, *as a separate conversation*, you can s
ost init systems allow the SIGPWR behavior to be configured.
> > This includes Upstart, systemd, and my own "little init":
> >
> > https://gitlab.com/chinstrap/linit#configuration
> >
> > I provide a guide for using linit with runit here, but the process is
> &g
17.02.2020, 11:00, "innerspacepilot" :
> Just as a thought: You have implemented signal diversion, but limited to
> known signals. Why not just pass unknown signals as numbers or something
> like (S6SIG55011), so they can be diverted by user? You wouldn't have to
> catalogue them.
absolutely right
17.02.2020, 15:45, "Jeff" :
> what about SIGINT and SIGWINCH ? are they required by the POSIX
> standard ? if not why does runit handle both ?
oh no, i just saw that it "POSIX-correctly" ignores SIGWINCH ...
the BSD kernels do not send SIGWINCH to process #1, so (ab)u
12.02.2020, 22:54, "Colin Booth" :
> far as I know SIGPWR is a Linux-specific signal so services that are
> aiming for portability will either need to have special handling for
> that in the linux case or need to ignore it. Ergo, runit (and all other
> POSIX-compliant in
way
since that signal is sent by the kernel in powerfail situations
(Linux and System V unices), it also makes sense to abuse it to
shutdown a container, so i cannot understand why runit just ignores it.
;t have to
catalogue them.
We need good, flexible and user-friendly init alternatives for linux
(other systems have their own).
So, I just want to make user experience of new runit or s6 users who use
LXD more comfortable, apologies if this hurts someone.
Have a good day!
On 14.02.2020 2
Jeff:
>
> you should patch the code, runit is dead anyway.
> try something along this lines in the source:
>
> #ifdef SIGPWR
> /* handle that one */
> ...
> #endif
>
> i can't see the problem, you have to patch the runit sources to
> fulfil your requi
way to run
your stage 1, and also your stage 3 when shutting down the container.
Stages 1 and 3 are an integral part of using runit as an init system
instead of just a supervision mechanism (which the runsvdir invocation
in stage 2 is), so if you can't run them because you can't run the
Good Day,
On Fri, Feb 14, 2020 at 3:18 PM Laurent Bercot
wrote:
> >That's a win-win
>
> Lengthening the supervision tree in the container and using more RAM
> just to save writing one line in a configuration file does not seem
> like a win to me.
>
> ... Besides
That's a win-win
Lengthening the supervision tree in the container and using more RAM
just to save writing one line in a configuration file does not seem
like a win to me.
... Besides, runit will refuse to run if it's not pid 1, so that
wouldn't work.
--
Laurent
Good Day,
On Wed, Feb 12, 2020 at 6:26 AM innerspacepilot
wrote:
>
> Why not just make runit systems run inside containers out of the box?
> We are talking about one/two lines of code.
>
>
The much better option here (in terms of playing well with others) would be
this
https://
You mean that adding few lines of code in one place is worse than many
users of many distros must configure their containers?
I can configure that myself, but I don't want every user of runit driven
container to walk this path. Is it necessary?
As counterintuitive as it may seem at first g
On Fri, Feb 14, 2020 at 05:06:40PM +0300, innerspacepilot wrote:
> If you read it carefully, there is NO signal for shutdown.
> Or lxd should also create file /etc/runit/stopit and set permissions for
> that?
Here runit provided a small machanism, and you also need a policy, like
those
1 - 100 of 420 matches
Mail list logo
