From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 21668 invoked from network); 4 Oct 2020 02:14:17 -0000 Received: from alyss.skarnet.org (95.142.172.232) by inbox.vuxu.org with ESMTPUTF8; 4 Oct 2020 02:14:17 -0000 Received: (qmail 14473 invoked by uid 89); 4 Oct 2020 02:14:41 -0000 Mailing-List: contact supervision-help@list.skarnet.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Received: (qmail 14466 invoked from network); 4 Oct 2020 02:14:41 -0000 From: "Laurent Bercot" To: "Dewayne Geraghty" , "supervision@list.skarnet.org" Subject: Re: s6-rc : Anomalies or normal behaviour Date: Sun, 04 Oct 2020 02:14:15 +0000 Message-Id: In-Reply-To: <780655eb-a904-8b29-b559-80a7a0abc9f1@heuristicsystems.com.au> References: <780655eb-a904-8b29-b559-80a7a0abc9f1@heuristicsystems.com.au> Reply-To: "Laurent Bercot" User-Agent: eM_Client/8.0.3385.0 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: -100 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedujedrfeelgdegiecutefuodetggdotffvucfrrhhofhhilhgvmecupfgfoffgtffkveetuefngfdpqfgfvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhephffvufffkfgjfhhrfgggtgfgsehtqhertddtreejnecuhfhrohhmpedfnfgruhhrvghnthcuuegvrhgtohhtfdcuoehskhgrqdhsuhhpvghrvhhishhiohhnsehskhgrrhhnvghtrdhorhhgqeenucggtffrrghtthgvrhhnpedvgfevffeuleegvdektdffteegvdeiieefkeetgfeuheffheelheejhfevueeijeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhhouggvpehsmhhtphhouhht >1. I expected to see the date in seconds since time epoch, but result is >variable name ># execlineb -Pc 'backtick D { date "+%s" } echo $D' >$D Normal behaviour, since there's no shell to interpret $D as the contents of variable D. Try using "importas D D" before the echo: it will read the value of D and substitute $D with this value, so echo will print the value. Yeah, execline is annoying like that, it's just a habit to take. Also, you generally want "backtick -n", to chomp the newline at the end of your input. >--- >2. When I use emptyenv within an execlineb script, I have a "defunct" >zombie process >89685 3 S< 0:00.01 |-- s6-supervise base:time-srv > 3020 - S-N -g -u ntpd --nofork > 3601 - Z< 0:00.00 | `-- > >The time server script is >#!/usr/local/bin/execlineb -P >emptyenv >multidefine -d " " "base time ntpd /usr/local/sbin/ntpd" { JAIL SERVICE >USER PROGRAM } >background { echo Starting service $SERVICE using $PROGRAM on $JAIL >under user $USER } >fdmove 2 1 >redirfd -w 1 /m/base:time/fifo >$PROGRAM -c /etc/ntp.conf -N -g -u $USER --nofork > >removing emptyenv, prevents the zombie from being created. Is this normal= ? The zombie is the echo program in your background block, since it's a direct child of your run script and there's nothing that reaps it after it's forked (fdmove, redirfd, ntpd - those programs don't expect to inherit a child). So the zombie is expected. To prevent that, use "background -d", which will doublefork your echo program, so it will be reparented to pid 1 which will reap it properly. The anomaly is that you *don't* have that zombie without emptyenv; my first guess is that there's something in your environment that=20 changes the behaviour of ntpd and makes it reap the zombie somehow. >--- >3. Is it normal/standard/good practice to include a dependency in a >bundle. For example, I have a "time" bundle whose contents are >time-srv. time-srv starts the ntpd service, and has as a dependency >time-log. > >Using "s6-rc -u change time", everything behaves as documented, ie >starts "time" which starts time-log, then time-srv. However > ># s6-rc -v 9 -d change base:time >s6-rc: info: bringing selected services down >s6-rc: info: processing service base:time-srv: stopping >s6-rc: info: service base:time-srv stopped successfully ># Starting logging service time for base with user s6log folder >/var/log/time > >and the time-log continues running. If you only have time-srv in your 'time' bundle, then time-srv and time are equivalent. Telling s6-rc to bring down time will do the exact same thing as telling it to bring down time-srv. time-log is not impacted. So the behaviour is expected. If you want "s6-rc -d change time" to also bring down time-log, then yes, you should add time-log to the time bundle. Then 'time' will address both time-srv and time-log. >y 6 seconds # This is time-srv >up (pid 85131) 6 seconds # This is time-log,so it >has been restarted If you're using a manually created named pipe to transmit data from time-srv to time-log, that pipe will close when time-srv exits, and your logger will get EOF and probably exit, which is why it stopped; but time-log's supervisor has received no instruction that it should stop, so it will restart it. This is also expected. The simplest way of achieving the behaviour you want is s6-rc's integrated pipeline feature. Get rid of your named pipe and of your stdout (for time-srv) and stdin (for time-log) redirections; get rid of your time bundle definition. Then declare time-log as a consumer for time-srv and time-srv as a producer for time-log. In the time-log source definition directory, write 'time' into the pipeline-name file. Then recompile your database. This will automatically create a pipe between time-srv and time-log; the pipe will be held open so it won't close even if one of the processes exits; and it will automatically create a 'time' bundle that contains both time-srv and time-log. You're on the right track. :) -- Laurent