From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.sysutils.supervision.general/2293 Path: news.gmane.org!.POSTED!not-for-mail From: Charles Duffy Newsgroups: gmane.comp.sysutils.supervision.general Subject: Re: Uncontrolled generation of new processes Date: Sun, 10 Dec 2017 19:33:26 +0000 Message-ID: References: <20171206163546.GA1084@lucu> <20171207060908.5oeazyhpcikiuxa4@cathexis.xen.prgmr.com> <20171210190714.GA444@lucu> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a1143f21c85e1d20560017e90" X-Trace: blaine.gmane.org 1512934418 2979 195.159.176.226 (10 Dec 2017 19:33:38 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 10 Dec 2017 19:33:38 +0000 (UTC) Cc: supervision@list.skarnet.org To: DGSJ Original-X-From: supervision-return-1884-gcsg-supervision=m.gmane.org@list.skarnet.org Sun Dec 10 20:33:33 2017 Return-path: Envelope-to: gcsg-supervision@m.gmane.org Original-Received: from alyss.skarnet.org ([95.142.172.232]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1eO7Lx-0000Tj-D7 for gcsg-supervision@m.gmane.org; Sun, 10 Dec 2017 20:33:33 +0100 Original-Received: (qmail 16636 invoked by uid 89); 10 Dec 2017 19:34:05 -0000 Mailing-List: contact supervision-help@list.skarnet.org; run by ezmlm Original-Sender: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 16629 invoked from network); 10 Dec 2017 19:34:05 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dyfis.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KWsS4G4ewhQwkmQuX2D23iyl5Kv112Qt6v3sNhH7gR8=; b=Md5YE68gcCvfVPQ6D0JK3velANzdT0sazWVMoWUYVG0Ywk6iVq2eJyzGnKfd7OlS02 i6NYVlG/j42WYDNceu5MIx4fiB70hRZjogCypTYaPY/O+bRsrtq9ALflagtJYDTC7lvV +CBz+mw2UM1wCVF96oKlucfV3pI9Gaeq/Q+sE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KWsS4G4ewhQwkmQuX2D23iyl5Kv112Qt6v3sNhH7gR8=; b=Aa402jMkQbFtW/TZQL4aWSdB/XKxkvjzZIjbJWIdgdpXC9gsC2yLalUB3iee2ghKBj K5ZeRNH6wrqrEwIY5c9QedR+y2NeB075bJIt9v/eHaDYOESSE/rjkoyu5gkux5/WHRLK ARRqndHk2wTuctRx2IZFhagB4HhHKqzumBzShTkwcEhDCNRSVRZa9MoAOW4tkuC/jOFi 0mz2uu6BZvdjK2yMOYqE9jmHnRySuIUeMMuwR5fi9/2X4mqXE5Pvh67moWSbZzTOS9BP TUb/x+xMifsPtLs5umkRd8jAU54mGYTaUPJdPxW2bN1+7wz8qVrahntK2yhR/2tnYpRF xe6Q== X-Gm-Message-State: AKGB3mJsl/43OPeMbjb8m8FoyTwhfMmLd2nlegYHZMXs9q5AdHCEFBiC VKs2SqrvuoHZSLALRFG6JrxzQc4u7OLpuaBfiOfIkg== X-Google-Smtp-Source: AGs4zMZdqCdARwKftbJ+hQFcmNe5DitRkEYIcNm+6dL3qjnTxDXQKYbZSTZ4GYdtyVsYxOCZJf6akHw2AEnmYgvWR8Q= X-Received: by 10.36.84.69 with SMTP id t66mr15800722ita.102.1512934417484; Sun, 10 Dec 2017 11:33:37 -0800 (PST) In-Reply-To: <20171210190714.GA444@lucu> Xref: news.gmane.org gmane.comp.sysutils.supervision.general:2293 Archived-At: --001a1143f21c85e1d20560017e90 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 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=C3=A9rrez San Jos=C3=A9 > > > > -- > > Colin Booth > > -- > ------------------------- > Daniel Guti=C3=A9rrez San Jos=C3=A9 > --001a1143f21c85e1d20560017e90--