service: a cgroup empty notification isn't reason enough to go down
authorLennart Poettering <lennart@poettering.net>
Wed, 27 Sep 2017 17:56:57 +0000 (19:56 +0200)
committerLennart Poettering <lennart@poettering.net>
Mon, 2 Oct 2017 10:58:42 +0000 (12:58 +0200)
The processes associated with a service are not just the ones in its
cgroup, but also the control and main processes, which might possibly
live outside of it, for example if they transitioned into their own
cgroups because they registered a PAM session of their own. Hence, if we
get a cgroup empty notification always check if the main PID is still
around before taking action too eagerly.

Fixes: #6045

src/core/service.c

index 56e07de..82d9bb5 100644 (file)
@@ -2871,7 +2871,9 @@ static void service_notify_cgroup_empty_event(Unit *u) {
                  * SIGCHLD for. */
 
         case SERVICE_START:
-                if (s->type == SERVICE_NOTIFY) {
+                if (s->type == SERVICE_NOTIFY &&
+                    main_pid_good(s) == 0 &&
+                    control_pid_good(s) == 0) {
                         /* No chance of getting a ready notification anymore */
                         service_enter_stop_post(s, SERVICE_FAILURE_PROTOCOL);
                         break;
@@ -2880,7 +2882,10 @@ static void service_notify_cgroup_empty_event(Unit *u) {
                 /* Fall through */
 
         case SERVICE_START_POST:
-                if (s->pid_file_pathspec) {
+                if (s->pid_file_pathspec &&
+                    main_pid_good(s) == 0 &&
+                    control_pid_good(s) == 0) {
+
                         /* Give up hoping for the daemon to write its PID file */
                         log_unit_warning(u, "Daemon never wrote its PID file. Failing.");