Re: Runit questions

[Colin Booth]

On Oct 20, 2016 12:40 AM, "Andy Mender"  wrote:
>
> Dear colleagues,
>
> I verified my svlogd logging problems on Debian/Devuan and it turned out
> that the error
> I was getting was non-specific and did not really interfere with either
> daemon supervision
> by runsv or generating logs via svlogd. Also, the error appears on my
> Gentoo boxen alike.
> Below, an example snippet:
> "runsvdir: log: 2: exec 2: ./run not found: exec 3: not found"
> Curiously, ./log/run exists and gets executed, in addition to "exec" being
> built in the Shell
> and also being executed. Not sure what's going on...
Are you calling 'exec 2&>1' or 'exec 2>&1'? The first is either trying to
background the 2 program and redirect it's output to a file called 1, or
exec into a program called 2 and redirect both stderr and stdout to a file
called one (behavior is shell dependent). The second is redirecting stderr
to the location stdout is pointing, and is the command you want.
>
> Secondly, what is really the default service directory per upstream -
> /service, /var/service,
> /etc/service or another directory? The official docs online mention
> /service in the sv(8)
> manpage, but Void Linux uses /var/service and Debian uses /etc/service.
The
> sv(8)
> manpage for Debian mentions /etc/service, but there are no dates anywhere
> to confirm
> when was this changed. What it means in practice is that when doing "sv
> 
> service", if sv tries to look for the service dir in the wrong main
> directory, it will return
> an error: "service directory does not exist". This can be circumvented by
> calling the
> service dir via sv directly, as in "sv  /path/to/service/".
> However, I would like
> to know what's the current "vanilla" upstream to help the Devuan people
> better.
Daemontools' svscan originally used /service, so the daemontools compatible
layout (and as such the normal supervision default) is /service. However,
there is no hard requirement on the directory used since scanners will run
against any directory you give them (or CWD if omitted). In the case of
runit, runsvdir is given a path via the script inittab calls and the search
path that the sv command uses is set at compile time. In Debian, that path
is /etc/service.
>
> Other than that I think runit is great and the more I learn about it, the
> more I feel it can be
> used as the go-to supervision suite for Unices :).
Runit is pretty nice and has the added benefit of having binary packages
available. It isn't pushing the state of the art forward, for that you need
s6 or nosh, but for basic supervision needs and as an entry point into
learning about process supervision runit works great.
>
> Best regards,
> Andrzej
>
Cheers!
>
>
> On 17 October 2016 at 06:09, Andy Mender  wrote:
>
> > Thank you for the links and the svlogd script. Great help indeed :).
> >
> > Best regards,
> > Andy
> >
> > On 16 Oct 2016 22:19, "Avery Payne"  wrote:
> >
> > I hate using webmail.  It always eats your formatting.
> >
> > The script shows up as a block of text in the mailing list because of
> > this; just click the link for the project and look for the run-svlogd
> > script.  You'll find what you need there.
> >
> > On Sun, Oct 16, 2016 at 1:16 PM, Avery Payne 
> > wrote:
> >
> >>
> >>
> >> On Sat, Oct 15, 2016 at 3:28 PM, Andy Mender 
> >> wrote:
> >>
> >>> Hello everyone,
> >>>
> >>> I managed to solve some of my problems. It turned out that my terminal
> >>> was
> >>> being spammed
> >>> with erroneous output, because I didn't add the "exec 2&>1"
redirection
> >>> to
> >>> my ./run files.
> >>>
> >>
> >> This behavior is fairly consistent among supervisors.  The use of
STDERR
> >> typically is left to the administrator to decide; more commonly, it's
> >> simply tied off into the STDOUT stream for ease of use.
> >>
> >>
> >>>
> >>> Another problem popped up on my Devuan box, though. I was trying to
add a
> >>> log directory with a ./run script inside to log dhcpcd per runit's
> >>> design.
> >>> However, runsvdir complaints that "exec: not found".
> >>>
> >>
> >> This is probably a problem with your shell.  The shebang specified
might
> >> point to an actual sh and not something like bash, ash, dash, etc.  I
don't
> >> have a reference handy but I suspect that you are seeing failure
messages
> >> for "exec" because the shell doesn't support that built-in.
> >>
> >> If you encounter this, change the first line to /bin/bash or /bin/ash
or
> >> /bin/dash and see if that resolves the issue.
> >>
> >>
> >>> The same run scripts work on Gentoo, which makes it even more
surprising.
> >>>
> >>
> >> Gentoo may be mapping /bin/sh to bash/ash/something  else, but I don't
> >> know.  I would suggest finding out.
> >>
> >>
> >>> Below the log/run script:
> >>> #!/bin/sh
> >>> exec chpst -u log svlogd -tt ./
> >>>
> >>
> >> I'll post a companion log script in a moment.
> >>
> >>
> >>> 

Re: Runit questions

[Andy Mender]

Dear colleagues,

I verified my svlogd logging problems on Debian/Devuan and it turned out
that the error
I was getting was non-specific and did not really interfere with either
daemon supervision
by runsv or generating logs via svlogd. Also, the error appears on my
Gentoo boxen alike.
Below, an example snippet:
"runsvdir: log: 2: exec 2: ./run not found: exec 3: not found"
Curiously, ./log/run exists and gets executed, in addition to "exec" being
built in the Shell
and also being executed. Not sure what's going on...

Secondly, what is really the default service directory per upstream -
/service, /var/service,
/etc/service or another directory? The official docs online mention
/service in the sv(8)
manpage, but Void Linux uses /var/service and Debian uses /etc/service. The
sv(8)
manpage for Debian mentions /etc/service, but there are no dates anywhere
to confirm
when was this changed. What it means in practice is that when doing "sv

service", if sv tries to look for the service dir in the wrong main
directory, it will return
an error: "service directory does not exist". This can be circumvented by
calling the
service dir via sv directly, as in "sv  /path/to/service/".
However, I would like
to know what's the current "vanilla" upstream to help the Devuan people
better.

Other than that I think runit is great and the more I learn about it, the
more I feel it can be
used as the go-to supervision suite for Unices :).

Best regards,
Andrzej



On 17 October 2016 at 06:09, Andy Mender  wrote:

> Thank you for the links and the svlogd script. Great help indeed :).
>
> Best regards,
> Andy
>
> On 16 Oct 2016 22:19, "Avery Payne"  wrote:
>
> I hate using webmail.  It always eats your formatting.
>
> The script shows up as a block of text in the mailing list because of
> this; just click the link for the project and look for the run-svlogd
> script.  You'll find what you need there.
>
> On Sun, Oct 16, 2016 at 1:16 PM, Avery Payne 
> wrote:
>
>>
>>
>> On Sat, Oct 15, 2016 at 3:28 PM, Andy Mender 
>> wrote:
>>
>>> Hello everyone,
>>>
>>> I managed to solve some of my problems. It turned out that my terminal
>>> was
>>> being spammed
>>> with erroneous output, because I didn't add the "exec 2&>1" redirection
>>> to
>>> my ./run files.
>>>
>>
>> This behavior is fairly consistent among supervisors.  The use of STDERR
>> typically is left to the administrator to decide; more commonly, it's
>> simply tied off into the STDOUT stream for ease of use.
>>
>>
>>>
>>> Another problem popped up on my Devuan box, though. I was trying to add a
>>> log directory with a ./run script inside to log dhcpcd per runit's
>>> design.
>>> However, runsvdir complaints that "exec: not found".
>>>
>>
>> This is probably a problem with your shell.  The shebang specified might
>> point to an actual sh and not something like bash, ash, dash, etc.  I don't
>> have a reference handy but I suspect that you are seeing failure messages
>> for "exec" because the shell doesn't support that built-in.
>>
>> If you encounter this, change the first line to /bin/bash or /bin/ash or
>> /bin/dash and see if that resolves the issue.
>>
>>
>>> The same run scripts work on Gentoo, which makes it even more surprising.
>>>
>>
>> Gentoo may be mapping /bin/sh to bash/ash/something  else, but I don't
>> know.  I would suggest finding out.
>>
>>
>>> Below the log/run script:
>>> #!/bin/sh
>>> exec chpst -u log svlogd -tt ./
>>>
>>
>> I'll post a companion log script in a moment.
>>
>>
>>> PS Earlier runsvdir was complaining that "log: user/group not found". I
>>> created the "log" group, thinking it might help somehow.
>>>
>>
>> You shouldn't need to create the group normally, which may indicate a
>> separate issue.
>>
>> Try this run script in your ./svcdef/dbus/log directory.  It's lifted
>> straight from the source at http://bitbucket.org/avery_pay
>> ne/supervision-scripts as the ./svcdef/.log/run-svlogd script.  Please
>> note that you may need to change the group name after chown, and the shell
>> in the first line to meet your needs:
>>
>> #!/bin/shexec 2>&1# determine our parent's nameSVNAME=$( basename $( echo 
>> `pwd` | sed 's/log//' ) )# bring up svlogd logging into a subdirectory that 
>> has the parent's name.[ -d /var/log/$SVNAME ] || mkdir -p /var/log/$SVNAME ; 
>> chown :adm /var/log/$SVNAME[ -d main ] || ln -s /var/log/$SVNAME mainexec 
>> /usr/bin/svlogd -tt main
>>
>> If you are using Gentoo, I would recommend looking at Toki Clover's
>> implementation at https://github.com/tokiclover/supervision.
>>
>> I hope this helps.
>>
>
>
>

Re: Runit questions

[Andy Mender]

Thank you for the links and the svlogd script. Great help indeed :).

Best regards,
Andy

On 16 Oct 2016 22:19, "Avery Payne"  wrote:

I hate using webmail.  It always eats your formatting.

The script shows up as a block of text in the mailing list because of this;
just click the link for the project and look for the run-svlogd script.
You'll find what you need there.

On Sun, Oct 16, 2016 at 1:16 PM, Avery Payne 
wrote:

>
>
> On Sat, Oct 15, 2016 at 3:28 PM, Andy Mender 
> wrote:
>
>> Hello everyone,
>>
>> I managed to solve some of my problems. It turned out that my terminal was
>> being spammed
>> with erroneous output, because I didn't add the "exec 2&>1" redirection to
>> my ./run files.
>>
>
> This behavior is fairly consistent among supervisors.  The use of STDERR
> typically is left to the administrator to decide; more commonly, it's
> simply tied off into the STDOUT stream for ease of use.
>
>
>>
>> Another problem popped up on my Devuan box, though. I was trying to add a
>> log directory with a ./run script inside to log dhcpcd per runit's design.
>> However, runsvdir complaints that "exec: not found".
>>
>
> This is probably a problem with your shell.  The shebang specified might
> point to an actual sh and not something like bash, ash, dash, etc.  I don't
> have a reference handy but I suspect that you are seeing failure messages
> for "exec" because the shell doesn't support that built-in.
>
> If you encounter this, change the first line to /bin/bash or /bin/ash or
> /bin/dash and see if that resolves the issue.
>
>
>> The same run scripts work on Gentoo, which makes it even more surprising.
>>
>
> Gentoo may be mapping /bin/sh to bash/ash/something  else, but I don't
> know.  I would suggest finding out.
>
>
>> Below the log/run script:
>> #!/bin/sh
>> exec chpst -u log svlogd -tt ./
>>
>
> I'll post a companion log script in a moment.
>
>
>> PS Earlier runsvdir was complaining that "log: user/group not found". I
>> created the "log" group, thinking it might help somehow.
>>
>
> You shouldn't need to create the group normally, which may indicate a
> separate issue.
>
> Try this run script in your ./svcdef/dbus/log directory.  It's lifted
> straight from the source at http://bitbucket.org/avery_pay
> ne/supervision-scripts as the ./svcdef/.log/run-svlogd script.  Please
> note that you may need to change the group name after chown, and the shell
> in the first line to meet your needs:
>
> #!/bin/shexec 2>&1# determine our parent's nameSVNAME=$( basename $( echo 
> `pwd` | sed 's/log//' ) )# bring up svlogd logging into a subdirectory that 
> has the parent's name.[ -d /var/log/$SVNAME ] || mkdir -p /var/log/$SVNAME ; 
> chown :adm /var/log/$SVNAME[ -d main ] || ln -s /var/log/$SVNAME mainexec 
> /usr/bin/svlogd -tt main
>
> If you are using Gentoo, I would recommend looking at Toki Clover's
> implementation at https://github.com/tokiclover/supervision.
>
> I hope this helps.
>

Re: Runit questions

[Avery Payne]

I hate using webmail.  It always eats your formatting.

The script shows up as a block of text in the mailing list because of this;
just click the link for the project and look for the run-svlogd script.
You'll find what you need there.

On Sun, Oct 16, 2016 at 1:16 PM, Avery Payne 
wrote:

>
>
> On Sat, Oct 15, 2016 at 3:28 PM, Andy Mender 
> wrote:
>
>> Hello everyone,
>>
>> I managed to solve some of my problems. It turned out that my terminal was
>> being spammed
>> with erroneous output, because I didn't add the "exec 2&>1" redirection to
>> my ./run files.
>>
>
> This behavior is fairly consistent among supervisors.  The use of STDERR
> typically is left to the administrator to decide; more commonly, it's
> simply tied off into the STDOUT stream for ease of use.
>
>
>>
>> Another problem popped up on my Devuan box, though. I was trying to add a
>> log directory with a ./run script inside to log dhcpcd per runit's design.
>> However, runsvdir complaints that "exec: not found".
>>
>
> This is probably a problem with your shell.  The shebang specified might
> point to an actual sh and not something like bash, ash, dash, etc.  I don't
> have a reference handy but I suspect that you are seeing failure messages
> for "exec" because the shell doesn't support that built-in.
>
> If you encounter this, change the first line to /bin/bash or /bin/ash or
> /bin/dash and see if that resolves the issue.
>
>
>> The same run scripts work on Gentoo, which makes it even more surprising.
>>
>
> Gentoo may be mapping /bin/sh to bash/ash/something  else, but I don't
> know.  I would suggest finding out.
>
>
>> Below the log/run script:
>> #!/bin/sh
>> exec chpst -u log svlogd -tt ./
>>
>
> I'll post a companion log script in a moment.
>
>
>> PS Earlier runsvdir was complaining that "log: user/group not found". I
>> created the "log" group, thinking it might help somehow.
>>
>
> You shouldn't need to create the group normally, which may indicate a
> separate issue.
>
> Try this run script in your ./svcdef/dbus/log directory.  It's lifted
> straight from the source at http://bitbucket.org/avery_
> payne/supervision-scripts as the ./svcdef/.log/run-svlogd script.  Please
> note that you may need to change the group name after chown, and the shell
> in the first line to meet your needs:
>
> #!/bin/shexec 2>&1# determine our parent's nameSVNAME=$( basename $( echo 
> `pwd` | sed 's/log//' ) )# bring up svlogd logging into a subdirectory that 
> has the parent's name.[ -d /var/log/$SVNAME ] || mkdir -p /var/log/$SVNAME ; 
> chown :adm /var/log/$SVNAME[ -d main ] || ln -s /var/log/$SVNAME mainexec 
> /usr/bin/svlogd -tt main
>
> If you are using Gentoo, I would recommend looking at Toki Clover's
> implementation at https://github.com/tokiclover/supervision.
>
> I hope this helps.
>

Re: Runit questions

[Avery Payne]

On Sat, Oct 15, 2016 at 3:28 PM, Andy Mender 
wrote:

> Hello everyone,
>
> I managed to solve some of my problems. It turned out that my terminal was
> being spammed
> with erroneous output, because I didn't add the "exec 2&>1" redirection to
> my ./run files.
>

This behavior is fairly consistent among supervisors.  The use of STDERR
typically is left to the administrator to decide; more commonly, it's
simply tied off into the STDOUT stream for ease of use.


>
> Another problem popped up on my Devuan box, though. I was trying to add a
> log directory with a ./run script inside to log dhcpcd per runit's design.
> However, runsvdir complaints that "exec: not found".
>

This is probably a problem with your shell.  The shebang specified might
point to an actual sh and not something like bash, ash, dash, etc.  I don't
have a reference handy but I suspect that you are seeing failure messages
for "exec" because the shell doesn't support that built-in.

If you encounter this, change the first line to /bin/bash or /bin/ash or
/bin/dash and see if that resolves the issue.


> The same run scripts work on Gentoo, which makes it even more surprising.
>

Gentoo may be mapping /bin/sh to bash/ash/something  else, but I don't
know.  I would suggest finding out.


> Below the log/run script:
> #!/bin/sh
> exec chpst -u log svlogd -tt ./
>

I'll post a companion log script in a moment.


> PS Earlier runsvdir was complaining that "log: user/group not found". I
> created the "log" group, thinking it might help somehow.
>

You shouldn't need to create the group normally, which may indicate a
separate issue.

Try this run script in your ./svcdef/dbus/log directory.  It's lifted
straight from the source at
http://bitbucket.org/avery_payne/supervision-scripts as the
./svcdef/.log/run-svlogd script.  Please note that you may need to change
the group name after chown, and the shell in the first line to meet your
needs:

#!/bin/shexec 2>&1# determine our parent's nameSVNAME=$( basename $(
echo `pwd` | sed 's/log//' ) )# bring up svlogd logging into a
subdirectory that has the parent's name.[ -d /var/log/$SVNAME ] ||
mkdir -p /var/log/$SVNAME ; chown :adm /var/log/$SVNAME[ -d main ] ||
ln -s /var/log/$SVNAME mainexec /usr/bin/svlogd -tt main

If you are using Gentoo, I would recommend looking at Toki Clover's
implementation at https://github.com/tokiclover/supervision.

I hope this helps.

Re: Runit questions

[Avery Payne]

On Tue, Oct 11, 2016 at 3:09 PM, Andy Mender 
wrote:

> Hello again,
>
> I'm rewriting some of the standard sysvinit and openrc scripts to ./run
> scripts
>

I would look around a bit.  There are little pockets of pre-written scripts
out there, you just need to dig them up.

Some of the scripts on smarden.org may have minor issues with the daemon
flags they use, so if it doesn't work, go read the man page and compare the
flags in the script to the flags for your installed daemon.


> and I have some problems with dbus. I took the ./run script from Void Linux
> as the original runit documentation doesn't have an exemplary dbus script.
> Whenever I check the status of dbus via "sv status dbus", I get the
> following
> error: "warning: dbus: unable to open supervise/ok: file does not exist".
> This
> makes no sense, as both /etc/sv/dbus/supervise/ and
> /var/service/dbus/supervise/
> contain the "ok" file. Below the run script from Void Linux:
> #!/bin/sh
> [ ! -d /run/dbus ] && install -m755 -g 22 -o 22 -d /run/dbus
> exec dbus-daemon --system --nofork --nopidfile
>

Here is a hacked-up copy of my ./run script.  Be sure to change the
"messagebus" user name after the setuidgid to the proper daemon account for
your installation.  Sorry for the backslash, the word-wrap in the posting
would otherwise kill any formatting.


#!/bin/sh
exec 2>&1
PATH=/sbin:/bin:/usr/sbin:/usr/bin

# must have a valid procfs
mountpoint -q /proc/ || exit 1

# create a unique identifier on each startup
dbus-uuidgen --ensure || exit 1

# start the service
exec pgrphack setuidgid messagebus \
   dbus-daemon --nofork --system --nopidfile



>
> Not sure what's wrong and why this run script needs to contain so many
> operands.
>

The daemon's runtime directory needs to exist before it is launched.  The
first line after the shebang basically does that.

Re: Runit questions

[Steve Litt]

On Thu, 13 Oct 2016 12:16:52 +0200
Andy Mender  wrote:

> I was recently trying to convert my OpenRC-based Gentoo installation
> into one based on runit. However, I noticed that it's quite easy to
> send runsvdir or runsvchdir into an infinite loop when there is
> something wrong with a service directory or the runlevel dir selected
> through runsvchdir is missing.
> Is there something potentially wrong with my setup or is this normal?

I know nothing about runsvchdir, but with runsvdir, well, it's
*supposed* to be an infinite loop. It loops the service directory
forever, starting what needs to be started.

Could you please elaborate on the symptom that happens to you when
there's something wrong with a service directory, and if possible
articulate on the flaw in that service directory?

Thanks,

SteveT

Steve Litt 
September 2016 featured book: Twenty Eight Tales of Troubleshooting
http://www.troubleshooters.com/28

Re: Runit questions

[Andy Mender]

I was recently trying to convert my OpenRC-based Gentoo installation into
one based on runit. However, I noticed that it's quite easy to send runsvdir
or runsvchdir into an infinite loop when there is something wrong with a
service directory or the runlevel dir selected through runsvchdir is
missing.
Is there something potentially wrong with my setup or is this normal?

Best regards,
Andy Mender

On 12 October 2016 at 20:03, Colin Booth  wrote:

> On Tue, Oct 11, 2016 at 9:11 PM, Jonathan de Boyne Pollard
>  wrote:
> > Colin Booth:
> >>
> >> --system loads the system defaults.
> >
> > Actually, it tells it that it is a system-wide broker rather than a
> > per-session or per-user broker.
>
> Interesting. Then the manpage is lying:
>--system
>Use the standard configuration file for the systemwide message
> bus.
>
> From my reading of that, --system isn't needed to run a system-wide
> broker if you pass it an alternate config file with the configs needed
> to run as a system-wide broker. Either way, --system is generally
> needed to have dbus do the right thing for overall system tasks.
>
> Cheers!
>
> --
> "If the doors of perception were cleansed every thing would appear to
> man as it is, infinite. For man has closed himself up, till he sees
> all things thru' narrow chinks of his cavern."
>   --  William Blake
>

Re: Runit questions

[Colin Booth]

On Oct 11, 2016 4:07 PM, "Steve Litt"  wrote:
>
> On Wed, 12 Oct 2016 00:09:02 +0200
> Andy Mender  wrote:
>
> > Hello again,
> >
> > I'm rewriting some of the standard sysvinit and openrc scripts
> > to ./run scripts
> > and I have some problems with dbus. I took the ./run script from Void
> > Linux as the original runit documentation doesn't have an exemplary
> > dbus script. Whenever I check the status of dbus via "sv status
> > dbus", I get the following
> > error: "warning: dbus: unable to open supervise/ok: file does not
> > exist". This
> > makes no sense, as both /etc/sv/dbus/supervise/ and
> > /var/service/dbus/supervise/
> > contain the "ok" file. Below the run script from Void Linux:
> > #!/bin/sh
> > [ ! -d /run/dbus ] && install -m755 -g 22 -o 22 -d /run/dbus
> > exec dbus-daemon --system --nofork --nopidfile
>
> The idiomatic way to troubleshoot this is to get to a command prompt,
> as root, and run /etc/sv/dbus/run
>
> Watch the messages as they scroll up, and fix any problems.
No.
>
> If running it from the command prompt works, from the command prompt
> try:
>
> sv start dbus
Fine.
>
> See what happens. Also see what happens when you run:
>
> runsv dbus
Also no.
>
> If some ways to run it work and others don't, continue to exploit the
> differences.
The idiomatic way to troubleshoot things in supervision land is to read
your logs, add debug logging if needed, lsof processes, and maybe strace
something. It is not to run things as root and see what happens. One of the
major tenants of supervision is to run with a consistent environment and
"just call a run script as root and see what happens" is completely
antithetical to that.

Supervision isn't a license to be sloppy. You already have all the tools
needed to debug this, use them without running things in an altered context.

Cheers!

Re: Runit questions

[Colin Booth]

On Oct 11, 2016 3:09 PM, "Andy Mender"  wrote:
>
> Hello again,
>
> I'm rewriting some of the standard sysvinit and openrc scripts to ./run
> scripts
> and I have some problems with dbus. I took the ./run script from Void
Linux
> as the original runit documentation doesn't have an exemplary dbus script.
> Whenever I check the status of dbus via "sv status dbus", I get the
> following
> error: "warning: dbus: unable to open supervise/ok: file does not exist".
I know this sounds cheesy, but try giving the full path to your dbus
supervision directory (if the scan dir is /etc/service, pass
/etc/service/dbus). Runit has a compiled in default service dir, but if
runsvdir is pointing somewhere else then sv won't find it without some
help. Last I checked, the upstream default is /service, and the Debian
default is /etc/service.

> This
> makes no sense, as both /etc/sv/dbus/supervise/ and
> /var/service/dbus/supervise/
> contain the "ok" file. Below the run script from Void Linux:
> #!/bin/sh
> [ ! -d /run/dbus ] && install -m755 -g 22 -o 22 -d /run/dbus
> exec dbus-daemon --system --nofork --nopidfile
>
> Not sure what's wrong and why this run script needs to contain so many
> operands.
dbus doesn't provide a service managed option so you need the --no* set to
have it do the right thing. --nofork keeps it from backgrounding,
--nopidfile keeps it from dropping a pid, and --system loads the system
defaults.

Cheers!
-Colin

Re: Runit questions

[Andy Mender]

Hello again,

I'm rewriting some of the standard sysvinit and openrc scripts to ./run
scripts
and I have some problems with dbus. I took the ./run script from Void Linux
as the original runit documentation doesn't have an exemplary dbus script.
Whenever I check the status of dbus via "sv status dbus", I get the
following
error: "warning: dbus: unable to open supervise/ok: file does not exist".
This
makes no sense, as both /etc/sv/dbus/supervise/ and
/var/service/dbus/supervise/
contain the "ok" file. Below the run script from Void Linux:
#!/bin/sh
[ ! -d /run/dbus ] && install -m755 -g 22 -o 22 -d /run/dbus
exec dbus-daemon --system --nofork --nopidfile

Not sure what's wrong and why this run script needs to contain so many
operands.

Best regards,
Andy

On 11 October 2016 at 21:24, Andy Mender  wrote:

> > Andy, one more observation: I'd think twice about letting the systemd
> > project set your expectations for init system requirements. They use
> > cgroups for certain things, and advertise that as a great benefit. It's
> > not. They make up the term "socket activation" and advertise that if
> > an init system doesn't have it, that init system is ineffective. This
> > is false. Follow the money: Plenty of people benefit from systemd
> > displacing all other init systems, even if systemd is ineffective or
> > effective only as long as programmers are given a million or so dollars
> > a year to keep it running despite its crushing complexity. Do not let
> > the systemd talking points influence the features YOU want in an init
> > system.
>
> It's quite difficult not to get phased by something that's been all the
> talk
> for some years now. The pressure from the so-called majority is strong
> after all...
>
> I personally prefer very minimalist approaches to init and system process
> supervision, much like the ones used by CRUX Linux. However, I do
> understand that bare Shell scripts are difficult to maintain and proper
> supervisors are "there to be used". That's why these discussions, tons of
> reading and a newly kindled fancy for runit and s6. For my personal use
> it's enough that runit manages the most essential system daemons so that
> I don't have to call "shutdown" or "reboot" from a terminal emulator :P.
>
> For testing the bare essentials, Gentoo serves me quite nicely. With USE
> flags I have a good idea of what features are needed by which programs.
>
> Best regards,
> Andy
>
> On 11 October 2016 at 18:15, Steve Litt  wrote:
>
>> On Tue, 11 Oct 2016 11:53:38 +0200
>> Jan Bramkamp  wrote:
>>
>>
>> > Runit doesn't track dependencies directly, but it can handle them.
>> > This is done by calling sv start $DEP_1 $DEP_2 etc. in the ./run
>> > script.
>>
>> I've always done it differently, as shown in this run script:
>>
>> 
>> #!/bin/sh
>> if test_of_readiness_of_dep1; then
>>   exec this_daemon
>> fi
>> sleep 1
>> 
>>
>> So if $DEP_1 isn't ready, $THIS_DAEMON waits a second and then fails
>> and is soon tried again. For a dependency that takes huge amounts of
>> time, like dhcpcd, that sleep might be 15 instead of 1.
>>
>> Your method is obviously more efficient and straightforward than mine.
>> My method theoretically could act like a bunch of ping pong balls on a
>> bunch of set mousetraps, although in practice I've never seen any
>> evidence of that. Your method sets off dependencies consecutively
>> rather than trial and error, and would seem to be superior, with two
>> exceptions:
>>
>> 1) My method can be used to test for any arbitrary definition of the
>>dependency being "ready". For instance, my sshd service could run
>>only after a successful ping of 8.8.8.8 or of google.com, thereby
>>proving the network is up all the way to the Internet. This is much
>>more specific than merely testing whether the networking system is
>>running.
>>
>> 2) My method refuses to run $THIS_DAEMON if $DEP_1 is not functional,
>>rather than starting $DEP_1 and assuming it will start correctly,
>>instantly. My method refuses to run a daemon when its dependencies
>>have serious problems.
>>
>> I'm wondering if our methods could be combined:
>>
>> 
>> #!/bin/sh
>> sv start $DEP_1
>> sleep $APPROPRIATE_SECONDS
>> if test_of_readiness_of_dep1; then
>>   exec this_daemon
>> fi
>> sleep 1
>> 
>>
>> In the preceding, $APPROPRIATE_SECONDS is probably a small fraction
>> like 0.1: Just enough time for $DEP_1 to become ready to do its job.
>>
>> SteveT
>>
>> Steve Litt
>> September 2016 featured book: Twenty Eight Tales of Troubleshooting
>> http://www.troubleshooters.com/28
>>
>>
>>
>

Re: Re[2]: Runit questions

[Charles Duffy]

Correct, cgroups can be used from any process supervision system.

As for socket activation, this too can be implemented on top of a
traditional supervision system, with no need for it to be baked into the
core. See http://smarden.org/ipsvd/ for an example implementation. Granted,
this one doesn't have pre-spawning support as systemd's socket activation
does, but there's no reason someone couldn't write a similar shim that did
-- frankly, there's just not a lot of call for the feature.


I do a great deal of work with systemd shop in my day job -- and while it
works reasonably well in the basic cases, I've also hit far more than my
share of bugs and bizarre corner cases. One of the beautiful things about
systemd is its simplicity: It promises a very small number of behaviors,
implements them well, and lets anything additional be implemented
out-of-band.

On Tue, Oct 11, 2016 at 9:36 AM Andy Mender 
wrote:

> Dear Jan, Laurent,
>
> Thank you kindly for answering my questions and clarifications :). I'm
> slowly starting to have a general idea of how to use runit,
> but I will definitely have streams of questions in the nearest future. As
> far as I understood, the point is to avoid extensive scripting hodgepodge
> within run scripts to avoid replicating System V init limitations, correct?
>
> Since dependency resolution is not done by runit, any inter-daemon
> communication is down to the capabilities of individual daemons, right?
> Case in point, if a specific daemon "talks" to another daemon via dbus,
> none of the runit programs care about this, because the daemon
> should know how to "do the talking" itself, right?
>
>
> Finally, in the systemd-sphere there is some emphasis on cgroups and socket
> activation. How relevant are those features in your opinion?
> Within the articles I read it was pointed out that cgroups are a kernel
> feature and there is a sizeable section of the kernel .config devoted to
> that.
> Thereby, in theory any init can take advantage of that. Is that correct?
> What about socket activation?
>
> Best regards,
> Andy
>
> On 11 October 2016 at 13:33, Laurent Bercot 
> wrote:
>
> >
> > >> 2. If several services rely on a common daemon, like dbus or
> > udev/eudev, is
> > >> the said daemon launched multiple times?
> >
> >  No. One service directory = one daemon instance. If you have a service
> > directory for dbus-daemon, it will be launched once, no matter how many
> > times you "sv up" that service directory.
> >
> >
> > Runit doesn't track dependencies directly, but it can handle them. This
> is
> >> done by calling sv start $DEP_1 $DEP_2 etc. in the ./run script.
> >>
> >
> >  I would advise against starting dependencies in a run script.
> > Idiomatically,
> > a run script should only impact the service it's representing, and
> nothing
> > else; baking in dependencies into run scripts is a slippery slope leading
> > to more problems.
> >
> >  The two common approaches to dependencies in supervision suites are:
> >
> >  - Do nothing. If all dependencies of a service are up, the service will
> > start normally. If they aren't, the service will fail to start, and the
> > supervisor will automatically make another attempt shortly after.
> > Eventually everything will be up.
> >  This approach is reasonable when all dependencies are longrun services
> > (processes that can be supervised) and restarting the processes isn't
> > too costly.
> >
> >  - Having a real service manager - like s6-rc, anopa, or OpenRC - handle
> > dependency management. This works in every case, but is the heavier
> > approach.
> >
> >
> > 3. I noticed the ./run scripts are essentially Shell scripts by default.
> >>> Does this resolve the commonly perceived
> >>> limitations of System V init scripts?
> >>>
> >>
> >  The limitations of System V scripts does not come from the fact that
> > they're
> > shell scripts. They come from the fact that they don't have a supervision
> > framework to start their daemons in, and thus have to resort to ugly
> hacks
> > to perform what is essentially free with a supervision suite:
> > backgrounding,
> > logging, storing the pid to find the daemon later, etc. Also, they have
> > to work both in the boot scripts' environment and a root shell's
> > environment,
> > and must not inherit anything from that root shell, which leads to a lot
> of
> > dirty boilerplate.
> >
> >  All those concerns disappear in a run script, because you don't need a
> pid
> > file, you don't need to background, you don't need to do anything except
> > put your current process into the desired state and execute into your
> > long-running program. The environment a run script is launched in is
> > always the same and there's a lot of infrastructure already in place, so
> > most of the boilerplate disappears. As Jan says, what remains is very
> > simple and very repetitive - it's just about setting the right process
> > state.
> >
> > --
> >  

Re[2]: Runit questions

[Laurent Bercot]

>> 2. If several services rely on a common daemon, like dbus or 
udev/eudev, is

>> the said daemon launched multiple times?

 No. One service directory = one daemon instance. If you have a service
directory for dbus-daemon, it will be launched once, no matter how many
times you "sv up" that service directory.


Runit doesn't track dependencies directly, but it can handle them. This 
is done by calling sv start $DEP_1 $DEP_2 etc. in the ./run script.


 I would advise against starting dependencies in a run script. 
Idiomatically,
a run script should only impact the service it's representing, and 
nothing
else; baking in dependencies into run scripts is a slippery slope 
leading

to more problems.

 The two common approaches to dependencies in supervision suites are:

 - Do nothing. If all dependencies of a service are up, the service will
start normally. If they aren't, the service will fail to start, and the
supervisor will automatically make another attempt shortly after.
Eventually everything will be up.
 This approach is reasonable when all dependencies are longrun services
(processes that can be supervised) and restarting the processes isn't
too costly.

 - Having a real service manager - like s6-rc, anopa, or OpenRC - handle
dependency management. This works in every case, but is the heavier
approach.


3. I noticed the ./run scripts are essentially Shell scripts by 
default.

Does this resolve the commonly perceived
limitations of System V init scripts?


 The limitations of System V scripts does not come from the fact that 
they're
shell scripts. They come from the fact that they don't have a 
supervision
framework to start their daemons in, and thus have to resort to ugly 
hacks
to perform what is essentially free with a supervision suite: 
backgrounding,

logging, storing the pid to find the daemon later, etc. Also, they have
to work both in the boot scripts' environment and a root shell's 
environment,
and must not inherit anything from that root shell, which leads to a lot 
of

dirty boilerplate.

 All those concerns disappear in a run script, because you don't need a 
pid

file, you don't need to background, you don't need to do anything except
put your current process into the desired state and execute into your
long-running program. The environment a run script is launched in is
always the same and there's a lot of infrastructure already in place, so
most of the boilerplate disappears. As Jan says, what remains is very
simple and very repetitive - it's just about setting the right process 
state.


--
 Laurent

Runit questions

[Andy Mender]

Hello,

I am a "journeyman" UNIX user, currently trying to implement runit
as a substitute for systemd on a number of GNU/Linux distributions.
I already have the ./run service scripts per the original documentation for
runit (http://smarden.org/runit/).
However, I don't fully understand how logging and dependency resolution
works.

1. When running several services with the service script as ./run and the
logging daemon's service as ./log/run,
does it mean that there are several instances/PIDs of the logging daemon?
Each attached to the service
it monitors?

2. If several services rely on a common daemon, like dbus or udev/eudev, is
the said daemon launched multiple times?

3. I noticed the ./run scripts are essentially Shell scripts by default.
Does this resolve the commonly perceived
limitations of System V init scripts?

Best regards,
Andy Mender