Description of problem:

Sometimes systemd can't restart sendmail service: there the race between inotify_add_watch calls and /run/sendmail.pid creation/write.

Version-Release number of selected component (if applicable):
systemd-197-1.fc18.1.x86_64

How reproducible:
Depends on host CPU, approximately 1 of 1000 for Intel Core i5.


Steps to Reproduce:
1. Run the

while [ 1 -eq 1 ]; do systemctl restart sendmail; [ $? -ne 0 ] && break; sleep 2; done

script
2. Wait for a hour
3. See for

---
Job for sendmail.service failed. See 'systemctl status sendmail.service' and 'journalctl -xn' for details.
---
  
Actual results:
Fail

Expected results:
Starts OK

Additional info:

systemd debug logs diff for success/fail restart:

---
 sendmail.service changed start-pre -> start
-Child 927 belongs to sendmail.service
+Child 872 belongs to sendmail.service
 sendmail.service: control process exited, code=exited status=0
 sendmail.service got final SIGCHLD for state start
 PID file /run/sendmail.pid not readable (yet?) after start.
 Setting watch for sendmail.service's PID file /run/sendmail.pid
-inotify event for sendmail.service
-Main PID loaded: 928
+Got notification message for unit httpd.service
+httpd.service: Got message
+httpd.service: got STATUS=Total requests: 0; Current requests/sec: 0; Current traffic:   0 B/sec
+Got notification message for unit httpd.service
+httpd.service: Got message
+httpd.service: got STATUS=Total requests: 0; Current requests/sec: 0; Current traffic:   0 B/sec
+Got notification message for unit httpd.service
+httpd.service: Got message
+httpd.service: got STATUS=Total requests: 0; Current requests/sec: 0; Current traffic:   0 B/sec
+Got notification message for unit httpd.service
+httpd.service: Got message
+httpd.service: got STATUS=Total requests: 0; Current requests/sec: 0; Current traffic:   0 B/sec
+Got notification message for unit httpd.service
+httpd.service: Got message
+httpd.service: got STATUS=Total requests: 0; Current requests/sec: 0; Current traffic:   0 B/sec
+Got notification message for unit httpd.service
+httpd.service: Got message
+httpd.service: got STATUS=Total requests: 0; Current requests/sec: 0; Current traffic:   0 B/sec
+Got notification message for unit httpd.service
+httpd.service: Got message
+httpd.service: got STATUS=Total requests: 0; Current requests/sec: 0; Current traffic:   0 B/sec
+Got notification message for unit httpd.service
+httpd.service: Got message
+httpd.service: got STATUS=Total requests: 0; Current requests/sec: 0; Current traffic:   0 B/sec
+Got notification message for unit httpd.service
+httpd.service: Got message
+httpd.service: got STATUS=Total requests: 0; Current requests/sec: 0; Current traffic:   0 B/sec
+sendmail.service operation timed out. Terminating.
 Stopping watch for sendmail.service's PID file /run/sendmail.pid
-sendmail.service changed start -> running
-Job sendmail.service/start finished, result=done
---

As you can see, the inotify event for sendmail.pid is lost.

This caused by race in systemd path_spec_watch() function:

sendmail create the /run/sendmail.pid late and keeps it open. So, if the file created after the first inotify_add_watch() call from path_spec_watch(), but before second inotify_add_watch() and sendmail don't write the pid before path_spec_watch() and service_retry_pid_file() it will never catched.

Here is the patch, that fix it:

---
--- path.c.orig 2013-03-01 15:28:51.312575945 -0500
+++ path.c      2013-03-01 15:37:46.991450760 -0500
@@ -92,6 +92,9 @@
                 if (!exists)
                         flags |= IN_DELETE_SELF | IN_ATTRIB | IN_CREATE | IN_MOVED_TO;
 
+                if (s->type == PATH_MODIFIED)
+                        flags |= IN_MODIFY;
+
                 if (inotify_add_watch(s->inotify_fd, k, flags) >= 0)
                         exists = true;
         } while (slash != k);
---

Please, apply.