bruceg / daemontools-encore Goto Github PK

./compile chkshsgr.c
chkshsgr.c: In function 'main':
chkshsgr.c:12: warning: cast increases required alignment of target type
chkshsgr.c:12: warning: cast increases required alignment of target type
arm-arago-linux-gnueabi-gcc chkshsgr.o -o chkshsgr
./chkshsgr || ( cat warn-shsgr; exit 1 )
/bin/sh: ./chkshsgr: cannot execute binary file
Oops. Your getgroups() returned 0, and setgroups() failed; this means
that I can't reliably do my shsgr test. Please either make'' as root or make'' while you're in one or more supplementary groups.
make: *** [hasshsgr.h] Error 1

related:
https://forums.gentoo.org/viewtopic-p-8029772.html?sid=843d03e4757ea9e46317a5e3989f63da

We're migrating our systems to docker. We use daemontools-encore and currently have docker run svscan as the main process. That appears to work well until the container is stopped.

When a container is stopped docker sends the main process a SIGTERM then waits for 30 second for all the processes in the container to exit. Any processes still running after 30 seconds are sent a SIGKILL.

When using svscan as the main process the svscan gets the SIGTERM but doesn't propagate it to child supervise processes. So they're unaware of the desire to stop the system until they get terminated violently in bulk with a SIGKILL.

I'm likely to switch to using s6 as it handles this case well.

Hi,

Problems with the test-suite: sleeper.c writes are not atomic when reporting received signals

This issue is pretty consistent on FreeBSD - signal reports (writes) to stdout are intermingled - and makes the self-test-suite fail.

Currently the FreeBSD port (package) of daemontools-encore applies this patch as a workaround

Feel free to adopt it

http://svnweb.freebsd.org/ports/head/sysutils/daemontools-encore/files/patch-sleeper-c.diff?revision=363937&view=markup

--- sleeper.c.orig 2014-07-27 23:16:55.000000000 +0200
+++ sleeper.c 2014-07-27 23:18:11.000000000 +0200
@@ -8,20 +8,18 @@
const char *name;
int ignored;
switch (sig) {

• case SIGALRM: name = "ALRM"; break;
• case SIGCONT: name = "CONT"; break;
• case SIGHUP: name = "HUP"; break;
• case SIGINT: name = "INT"; break;
• case SIGQUIT: name = "QUIT"; break;
• case SIGTERM: name = "TERM"; break;
• case SIGUSR1: name = "USR1"; break;
• case SIGUSR2: name = "USR2"; break;
• case SIGWINCH: name = "WINCH"; break;
• default: name = "unknown signal";
• case SIGALRM: name = "Caught ALRM\n"; break;
• case SIGCONT: name = "Caught CONT\n"; break;
• case SIGHUP: name = "Caught HUP\n"; break;
• case SIGINT: name = "Caught INT\n"; break;
• case SIGQUIT: name = "Caught QUIT\n"; break;
• case SIGTERM: name = "Caught TERM\n"; break;
• case SIGUSR1: name = "Caught USR1\n"; break;
• case SIGUSR2: name = "Caught USR2\n"; break;
• case SIGWINCH: name = "Caught WINCH\n"; break;
• default: name = "unknown signal\n";
  }
• ignored = write(1, "Caught ", 7);
  ignored = write(1, name, str_len(name));
• ignored = write(1, "\n", 1);
  if (sig != SIGCONT)
  _exit(1);
  }

/Uffe

The prototype patch below adds displaying ', once' to the svstat output if svc -o /service/foo' is used instead ofsvc -u /service/foo'. Example:

# svc -u /service/rubygems/
# ./svstat /service/rubygems/
/service/rubygems/: up (pid 801) 4791279 seconds, running
# svc -o /service/rubygems/
# ./svstat /service/rubygems/
/service/rubygems/: up (pid 801) 4791288 seconds, running, once
# svc -u /service/rubygems/
# ./svstat /service/rubygems/
/service/rubygems/: up (pid 801) 4791294 seconds, running
#

Patch:

# git status
diff --git a/svstat.c b/svstat.c
index 03db0b8..09d2173 100644
--- a/svstat.c
+++ b/svstat.c
@@ -89,6 +89,8 @@ static void showstatus(const char status[19], int r, int normallyup)
     if (x)
       buffer_puts(&b,x);
   }
+  if (pid && (want == '\000'))
+    buffer_puts(&b,", once");
 }

 void doit(const char *dir)

As it stands, the unittest gives an error but should be easy to fix by changing it to support the svc -o' case in addition to thesvc -u' case.

# make
env - /bin/sh rts.sh 2>&1 | cat -v > rts
diff -u rts.exp rts
--- rts.exp 2013-10-14 16:50:05.051427273 -0700
+++ rts 2013-10-14 16:51:49.236428375 -0700
@@ -187,12 +187,12 @@
 100
 0
 --- svstat and svup work for logged services
-.: up (pid x) x seconds, normally down, running
-. log: up (pid x) x seconds, normally down, running
+.: up (pid x) x seconds, normally down, running, once
+. log: up (pid x) x seconds, normally down, running, once
 0
-.: up (pid x) x seconds, normally down, running
+.: up (pid x) x seconds, normally down, running, once
 0
-. log: up (pid x) x seconds, normally down, running
+. log: up (pid x) x seconds, normally down, running, once
 0
 0
 0
make: *** [rts] Error 1
#

What do you think?

$ cd daemontools-encore-1.11
$ sh makemake
...
$ make
...
$ mkdir empty-dir
$ time ./svscan empty-dir
./svscan empty-dir  0.00s user 0.00s system 0% cpu 0.001 total

daemontools 0.76 and daemontools-encore-1.03 are no problem.

The Changes for daemontools-encore-1.02 says:

If a supervise is managing both a main and log service,
issuing "svc -dx" on the service will cause the log to stop
after the main service exits.

This doesn't seem to be the case.

I've a standard log/run script that does exec multilog .... When I do svc -dx foo on the parent the multilog exits after reading eof on stdin, but the log supervise restarts it (and keeps on restarting it because the multilog exits immediately due to end on stdin).

Using strace on the multilog and the parent log supervise process I can see that the multilog exits on eof, as expected. The parent log supervise process however doesn't get told how to act. The svc -dx foo on the parent has no effect on the log supervise, so naturally it restarts the multilog when it exits.

I forked this repo assuming it would be very similar to the original 0.76 daemontools distribution (which I tweaked several years ago - now I'm in the mood to share), but I'm not seeing Makefile anywhere.

How then can "make" to work as indicated in the README?

Not sure if this is a feature or a bug, but, with the original daemontools i was able to do svc -du /service/blah and it would both stop and start the service in one command line.

I'm not sure if this is related to issue #20; it might be.

The last release was a year ago.
Much good work as been done since 1.06 was released.
Any chance an official release could be made soon?

What's left to do?
Review the docs to check they're in sync with the changes?
Anything else?

How about a supervise flag file named 'killpg' that causes svc to default to sending a signal to the service process group by default? This would only be set for processes that do not clean up their children properly.

Initial patch below. This is largely inspired by the no-setsid change but it splits this feature off into its own flag, because they are orthogonal ideas.

--- a/supervise.8.in
+++ b/supervise.8.in
@@ -40,6 +40,12 @@ exists,
 .B supervise
 will run subordinate processes in a new process group.

+If the file
+.B ./killpg
+exists, all signals requested by the
+.BR svc (8)
+program will be sent to the process group instead of the process.
+
 If
 .B ./log
 is an executable file,
diff --git a/supervise.c b/supervise.c
index a792f66..e4f21c8 100644
--- a/supervise.c
+++ b/supervise.c
@@ -326,6 +326,7 @@ void doit(void)

     svc = &svcmain;
     killpid = svc->pid;
+    if (stat_exists("killpg")==0) killpid = -killpid;
     while (read(fdcontrol,&ch,1) == 1)
       switch(ch) {
       case '+':
@@ -340,6 +341,7 @@ void doit(void)
       break;
       case 'l':
       svc = &svcmain;
 +     if (stat_exists("killpg")==0) killpid = -killpid;
       killpid = svc->pid;
       break;
       case 'd':
diff --git a/svc.8.in b/svc.8.in
index 8e2e2b6..582821e 100644
--- a/svc.8.in
+++ b/svc.8.in
@@ -25,7 +25,10 @@ process group. This is the default.
 .TP
 .B \-\+
 Send all subsequent signals to the entire process group instead of just
-the parent process.
+the parent process. This is the default if the file
+.IB s/killpg
+is present.
+
 .TP
 .B \-L
 Send all subsequent signals to the running

Basically, envuidgid should setup the env to not break apps running as another user similar but lighter than sudo. At a minimum, setting HOME and USER from struct passwd fields from getpwname(). Not doing this most likely inherits the environment from root, which is likely bad news.

HN discussion

I'm getting an odd failure when trying to compile setlock.c using my old Makefile (I still can't get ./makemake to work):

$ make setlock
./compile setlock.c
In file included from setlock.c:8:
strerr.h:6:26: error: hasattribute.h: No such file or directory
make: *** [setlock.o] Error 1

Indeed, strerr.h includes hasattribute.h on line 6:

/* Public domain. */

#ifndef STRERR_H
#define STRERR_H

#include "hasattribute.h"

but I don't see hasattribute.h anywhere in daemontools-encore.
Is it supposed to be a C standard library header?

make install doesn't error out, but neither does it create a /service directory. Then it won't start of course without creating the /service directory. Creating that by hand, then starting it, it doesn't end up starting a simple service from a run file there. The original daemontools, also built from source, same system, does not have these problems -- but of course not the extra features either. There was no problem with encore on Ubuntu 16.

This is incompatible with original daemontools behavior.

When running lsof on a supervise'd process, I see something like this:

jsvc.amd6 25438 root 5w REG 8,1 20 3802558 /var/lib/service/datanode/supervise/status

It seems a `closeonexec(fdstatus);' needs to be added after supervise.c:433 to keep this filedescriptor from leaking into the child:

--- a/supervise.c
+++ b/supervise.c
@@ -427,6 +427,7 @@ int main(int argc,char **argv)
   fdstatus = open_trunc(fntemp);
   if (fdstatus == -1)
      strerr_die4sys(111,FATAL,"unable to open ",fntemp," for writing: ");
+  closeonexec(fdstatus);
   if ((fntemp = svpath_make("/lock")) == 0) die_nomem();
   fdlock = open_append(fntemp);
   if ((fdlock == -1) || (lock_exnb(fdlock) == -1))

Sometimes works for me, sometimes fails. Might be a timing issue. This happened on Ubuntu 14.04 and HEAD = 5526cf4.

--- rts.exp 2015-04-27 00:09:11.979474999 +0000
+++ rts     2015-04-27 00:09:44.419246346 +0000
@@ -269,7 +269,6 @@
 in stop

 --- supervise stops log after main
-Caught CONT
 Caught TERM

 --- svc sends right signals
@@ -282,7 +281,6 @@
 Caught USR1
 Caught USR2
 Caught WINCH
-Caught CONT
 Caught TERM
 ==> svc0/output <==
 svc0 ran
make[1]: *** [rts] Error 1

In some wrapper scripts I had to replace "svc -d .; svc -u ." with "svc -t ." since bringing a certain kind of service down and then up when the run script hasn't exited yet causes the up to be ignored.
The issue seems to be that supervise thinks it's in start mode (firstrun == 1)
and doesn't restart the service if it exited > 0.
Specifically, in supervise.c the following condition is triggered:

firstrun == 1 and wait_crashed(wstat) == 15

  if ((firstrun && (wait_crashed(wstat) || wait_exitcode(wstat) != 0))
|| (!wait_crashed(wstat) && wait_exitcode(wstat) == 100)) {
          svc->flagwantup = 0;
          svc->flagstatus = svstatus_failed;
  }

Repro: create a service which doesn't exit right away when running 'svc -d .; svc -u .';
svstat will show 'failed' in the status message, and the service will be left down.

The underlying problem seems to be that firstrun is set when it should not (it
should only be set if the start file exists). Maybe the following assignment
in handling 'u' in doit is wrong:

        firstrun = !svcmain.flagwantup;

Hi Bruce,

I believe your daemontools-encore-1.11.tar.gz (md5 c44f99c8bd3921642b7a54742ebf1363) missing setuser.8 or related files as I encountered the following installer error:

./installer head -n 1 conf-bin <BIN
./installer head -n 1 conf-man <MAN
installer: fatal: unable to read setuser.8: file does not exist
make: *** [install] Error 111

Makefile also missing setuser.8 in man target I guess.

Correct me if I am wrong.

Thanks.

Kindest regards,
Giam Teck Choon

If a service directory has "start" and "down", the first svc -o service does
NOT start the service.

How to reproduce:

# mkdir t
# cd t
# (echo '#!/bin/sh'; echo exit 0) >start
# (echo '#!/bin/sh'; echo 'while :; do sleep 999; done') >run
# chmod +x start run
# touch down
# ln -s $PWD/t /service
# svstat .
.: down 2 seconds
# svc -o .
# svstat .
.: down 2 seconds
# svstat .
.: down 5 seconds
# svc -o .
# svstat .
.: up (pid 3830) 2 seconds, normally down
# svstat .
.: up (pid 3830) 4 seconds, normally down