supervision - discussion about system services, daemon supervision, init, runlevel management, and tools such as s6 and runit
 help / color / mirror / Atom feed
* Uncontrolled generation of new processes
@ 2017-12-06 16:35 DGSJ
  2017-12-07  6:09 ` Colin Booth
  0 siblings, 1 reply; 4+ messages in thread
From: DGSJ @ 2017-12-06 16:35 UTC (permalink / raw)
  To: supervision

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.

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?

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

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?

I'm very interested in using runit for controlling other services different
than daemons, so any help will be welcomed.

Thank you in advance for your help.
-- 
-------------------------
Daniel Gutiérrez San José


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Uncontrolled generation of new processes
  2017-12-06 16:35 Uncontrolled generation of new processes DGSJ
@ 2017-12-07  6:09 ` Colin Booth
  2017-12-10 19:07   ` DGSJ
  0 siblings, 1 reply; 4+ messages in thread
From: Colin Booth @ 2017-12-07  6:09 UTC (permalink / raw)
  To: supervision

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.
> 
> 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'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


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Uncontrolled generation of new processes
  2017-12-07  6:09 ` Colin Booth
@ 2017-12-10 19:07   ` DGSJ
  2017-12-10 19:33     ` Charles Duffy
  0 siblings, 1 reply; 4+ messages in thread
From: DGSJ @ 2017-12-10 19:07 UTC (permalink / raw)
  To: supervision

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é


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Uncontrolled generation of new processes
  2017-12-10 19:07   ` DGSJ
@ 2017-12-10 19:33     ` Charles Duffy
  0 siblings, 0 replies; 4+ messages in thread
From: Charles Duffy @ 2017-12-10 19:33 UTC (permalink / raw)
  To: DGSJ; +Cc: supervision

[-- Attachment #1: Type: text/plain, Size: 6494 bytes --]

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@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é
>

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2017-12-10 19:33 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-12-06 16:35 Uncontrolled generation of new processes DGSJ
2017-12-07  6:09 ` Colin Booth
2017-12-10 19:07   ` DGSJ
2017-12-10 19:33     ` Charles Duffy

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).