As an aside, set -e is by no means unambiguously considered good practice.
See the list of exercises (below the allegory) in BashFAQ #105 at
http://mywiki.wooledge.org/BashFAQ/105 to see if you understand its
(extremely unintuitive) behavior in corner cases, and an extended listing
of the many incompatibilities between different shells' implementations of
set -e at
https://www.in-ulm.de/~mascheck/various/set-e/.
Generally, a well-behaved service script should just exec your service
(configured in such a way as to not self-daemonize) -- that way the service
itself owns the PID that previously belonged to the shell, and the
supervision system can determine whether the service exited by looking at
that PID itself.
On Sun, Dec 10, 2017 at 12:05 PM DGSJ <audobra_at_gmail.com> wrote:
> On Thu, Dec 07, 2017 at 06:09:08AM +0000, Colin Booth wrote:
> > On Wed, Dec 06, 2017 at 05:35:46PM +0100, DGSJ wrote:
> > > Hallo.
> > > In order to migrate my SistemV to Runit, I'm writing the service
> scripts,
> > > but I'm having a problem I can't solve.
> > All right, lets take a look!
> > >
> > > First, lest see an example that works well. The run file for the
> > > touchpad mouse:
> > >
> > > #!/bin/bash
> > > [ -f /etc/sysconfig/mouse ] && . /etc/sysconfig/mouse
> > > echo -e "Mouse working (ratonpad)..."
> > > exec /usr/sbin/gpm -D -m "${MDEVICE}" -t "${PROTOCOL}" ${GPMOPTS} >
> /dev/null 2>&1
> > >
> > > An this is how the processes and PID's look like.
> > > # ps -fx
> > > 1 ? Ss 0:00 runit
> > > 192 ? Ss 0:00 runsvdir -P /service log: ..................
> > > .....................................................................
> > > 194 ? Ss 0:00 \_ runsv ratonpad
> > > 198 ? S 0:00 | \_ /usr/sbin/gpm -D -m /dev/input/mice
> -t imps2
> > >
> > > This kind of run file seems to work fine with daemons like gpm,
> sysklogd
> > > syslogd...
> > >
> > > But when I try to make the same with other services like udev,
> something
> > > goes wrong.
> > >
> > > This is the run file:
> > > #!/bin/bash -e
> > > echo "daemon udevd"
> > > exec 2>&1
> > > exec /sbin/udevd --daemon
> > >
> > > And this is what happens:
> > > 466 ? Ss 0:00 /sbin/udevd --daemon
> > > 470 ? Ss 0:00 /sbin/udevd --daemon
> > > 474 ? Ss 0:00 /sbin/udevd --daemon
> > > 478 ? Ss 0:00 /sbin/udevd --daemon
> > > 484 ? Ss 0:00 /sbin/udevd --daemon
> > > 488 ? Ss 0:00 /sbin/udevd --daemon
> > > 492 ? Ss 0:00 /sbin/udevd --daemon
> > > 496 ? Ss 0:00 /sbin/udevd --daemon
> > >
> > > The processes doesn't fit into the typical runsv tree, and every one
> second
> > > a new PID is created on and on.
> > >
> > > What can be wrong?
> > systemd-udevd(8) says: --daemon Detach and run in the background.
> >
> > The main thing about supervision is that things shouldn't background
> > themselves, otherwise the supervisor loses track of it and spawns a new
> > copy. Dropping the `--daemon' should fix it.
>
> Yes, fixed as you said.
>
> > >
> > > With other more elaborated run files, for services different than
> daemons,
> > > it happens more or less the same. Let see the behaviour of this
> > > interesting template I have found.
> > >
> > > This is the run file.
> > > #!/bin/bash -e
> > > echo -e "-------------"
> > > exec 2>&1
> > > exec /opt/example2/foo-service.sh
> > >
> > > This is the script for the foo-service.sh
> > > #!/bin/bash -e
> > > echo "Empieza el servicio...root (service begins)"
> > > for i in {1..2}
> > > do
> > > echo "haciendo cosas...root (making things...)"
> > > sleep 1
> > > done
> > >
> > > It doesn't matter if you end the script with exit 1 o 0, the result,
> > > regarding the uncontrolled creation of PID's is the same.
> > >
> > > This is the output of ps -fx
> > >
> > > 197 ? Ss 0:00 \_ runsv example2
> > > 820 ? S 0:00 \_ /bin/bash -e
> /opt/example2/foo-service.sh
> > > 821 ? S 0:00 \_ sleep 1
> > >
> > > It looks nice, but after a while:
> > > 197 ? Ss 0:00 \_ runsv example2
> > > 989 ? S 0:00 \_ /bin/bash -e
> /opt/example2/foo-service.sh
> > > 991 ? S 0:00 \_ sleep 1
> > This is a matter of confusion on the part of the user. ./run is being
> > replaced via exec with foo-service.sh, a program that does three things:
> > echoes some stuff, forks a one-second sleep, and then exits. Once it
> > exits, the supervisor (runsv) will re-launch it.
> > >
> > > Old processes are killed, and new ones created every second
> > > 820 - 821 --> 989 - 991.
> > >
> > > Another view with pstree.
> > > |-runsvdir-+-runsv---login---bash---
> > > | |
> > > | |-runsv---gpm
> > > | |-runsv---syslogd
> > > | |-runsv-+-klogd
> > > | | `-run---svlogd
> > > | `-runsv---foo-service.sh---sleep
> > >
> > >
> > > Well, I think I've missed something...
> > >
> > > It seems that every time the service is controlled, at the same time
> the
> > > process is recreated again and again with increasing PIDs.
> > > What am I doing wrong?
> > In your test case, the design of foo-service.sh is the problem. If you
> > replaced `for i in {1..2} ; do' with `while : ; do' the script will
> > never actually terminate and foo-service.sh will be properly supervised.
> > >
> I've tried infinite loops like `while : ; do' to prevent the script from
> ending,
> but surprisingly (in my case) it consumes a high amount of CPU. Using
> kill -stop $$ seems to be a good way to stop the process. I've made some
> tests with foo-service.sh scripts like this:
>
> #!/bin/bash -e
>
> ...service script...
>
> kill -stop $$
>
> So far, they run apparently well.
>
> Thank you!
>
> > > I'm very interested in using runit for controlling other services
> different
> > > than daemons, so any help will be welcomed.
> > The only rules are: it has to not background/detatch/whatever, and when
> > it terminates it'll get re-launched.
> > >
> > > Thank you in advance for your help.
> > Cheers!
> > > --
> > > -------------------------
> > > Daniel Gutiérrez San José
> >
> > --
> > Colin Booth
>
> --
> -------------------------
> Daniel Gutiérrez San José
>
Received on Sun Dec 10 2017 - 19:33:26 UTC