Das PidFile-Verzeichnis von Apache wird bei jedem Start entfernt

Bei jedem Neustart des Servers wird das Verzeichnis / run / httpd entfernt. / run ist ein tmpfs-Dateisystem, das daher im RAM bereitgestellt wird.

/ run / httpd wird nur während der Installation erstellt. Wenn ich httpd nach dem Neustart starte, wird das Verzeichnis nicht neu erstellt.

Der Server hat CentOS 7 und das offizielle Repository-Apache-Paket (Version 2.4.6-18) installiert.

Nach der Installation und dem Start von Apache ist das Verzeichnis wie folgt:

# ls -alR /run/httpd/
/run/httpd/:
total 8
drwx--x---.  3 root   apache  120 Sep 30 08:39 .
drwxr-xr-x. 28 root   root   1020 Sep 30 08:37 ..
-rw-r--r--.  1 root   root      8 Sep 30 08:39 authdigest_shm.2953
drwx------.  2 apache apache   40 Jul 23 10:48 htcacheclean
-rw-r--r--.  1 root   root      5 Sep 30 08:39 httpd.pid
srwx------.  1 apache root      0 Sep 30 08:39 wsgi.2953.0.1.sock

/run/httpd/htcacheclean:
total 0
drwx------. 2 apache apache  40 Jul 23 10:48 .
drwx--x---. 3 root   apache 120 Sep 30 08:39 ..

Aber nach dem Neustart:

# ls -l /run/httpd
ls: cannot access /run/httpd: No such file or directory

Und hier sind die Protokolle beim Neustart von Apache:

/ var / log / httpd / error_log

[Tue Sep 30 09:30:32.310825 2014] [core:notice] [pid 3370] SELinux policy enabled; httpd running as context system_u:system_r:httpd_t:s0
[Tue Sep 30 09:30:32.312072 2014] [suexec:notice] [pid 3370] AH01232: suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)
[Tue Sep 30 09:30:32.330380 2014] [auth_digest:notice] [pid 3370] AH01757: generating secret for digest authentication ...
[Tue Sep 30 09:30:32.330421 2014] [auth_digest:error] [pid 3370] (2)No such file or directory: AH01762: Failed to create shared memory segment on file /run/httpd/authdigest_shm.3370
[Tue Sep 30 09:30:32.330440 2014] [auth_digest:error] [pid 3370] (2)No such file or directory: AH01760: failed to initialize shm - all nonce-count checking, one-time nonces, and MD5-sess algorithm disabled
[Tue Sep 30 09:30:32.330445 2014] [:emerg] [pid 3370] AH00020: Configuration Failed, exiting
Job for httpd.service failed. See 'systemctl status httpd.service' and 'journalctl -xn' for details.

/ var / log / message

Sep 30 08:56:09 brejetuba2 systemd: Starting The Apache HTTP Server...
Sep 30 08:56:09 brejetuba2 systemd: httpd.service: main process exited, code=exited, status=1/FAILURE
Job for httpd.service failed. See 'systemctl status httpd.service' and 'journalctl -xn' for details.
Sep 30 08:56:09 brejetuba2 systemd: Failed to start The Apache HTTP Server.
Sep 30 08:56:09 brejetuba2 systemd: Unit httpd.service entered failed state.

/var/log/audit/audit.log

Job for httpd.service failed. See 'systemctl status httpd.service' and 'journalctl -xn' for details.
type=SERVICE_START msg=audit(1412083740.602:469): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg=' comm="httpd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed'

Wenn ich das Verzeichnis manuell erstelle, startet Apache:

# mkdir /run/httpd
# systemctl restart httpd
# ls -lRa /run/httpd/
/run/httpd/:
total 8
drwxr-xr-x.  2 root   root  100 Sep 30 09:36 .
drwxr-xr-x. 28 root   root 1020 Sep 30 09:36 ..
-rw-r--r--.  1 root   root    8 Sep 30 09:36 authdigest_shm.3452
-rw-r--r--.  1 root   root    5 Sep 30 09:36 httpd.pid
srwx------.  1 apache root    0 Sep 30 09:36 wsgi.3452.0.1.sock

Und nach dem Neustart ist es wieder weg.

Irgendwelche Gedanken darüber, warum dies geschieht?

Das Problem war , dass, wenn Apache Installation Gruppe Apache wurde nicht erstellt werden.

# systemctl status systemd-tmpfiles-setup.service
systemd-tmpfiles-setup.service - Create Volatile Files and Directories
  Loaded: loaded (/usr/lib/systemd/system/systemd-tmpfiles-setup.service; static)
  Active: failed (Result: exit-code) since Tue 2014-09-30 09:40:30 EDT; 3h 24min ago
Docs: man:tmpfiles.d(5)
      man:systemd-tmpfiles(8)
  Process: 724 ExecStart=/usr/bin/systemd-tmpfiles --create --remove --boot --exclude-prefix=/dev (code=exited, status=1/FAILURE)
Main PID: 724 (code=exited, status=1/FAILURE)

Sep 30 09:40:30 servername systemd-tmpfiles[724]: [/usr/lib/tmpfiles.d/httpd.conf:1] Unknown group 'apache'.
Sep 30 09:40:30 servername systemd-tmpfiles[724]: [/usr/lib/tmpfiles.d/httpd.conf:2] Unknown user 'apache'.
Sep 30 09:40:30 servername systemd[1]: systemd-tmpfiles-setup.service: main process exited, code=exited, status=1/FAILURE
Sep 30 09:40:30 servername systemd[1]: Failed to start Create Volatile Files and Directories.
Sep 30 09:40:30 servername systemd[1]: Unit systemd-tmpfiles-setup.service entered failed state.

Das liegt daran, dass ich einen NIS-Server mit einem NIS- Apache- Benutzer konfiguriert habe . Da es einen Apache- Benutzer hat, erstellt die Apache-Installation keine Apache- Gruppe. Aber Apache Gruppe existiert auch auf NIS! Nun, NIS bringt die Dinge durcheinander.

Fazit: Ich muss ypbind stoppen, Apache installieren und dann ypbind neu starten (oder einfach manuell eine Apache- Gruppe in / etc / group erstellen ).

Ich hatte die gleiche Lösung für mein Problem wie @datakid mit dem Unterschied, dass der nach einem Neustart systemd-tmpfiles-setup.servicewieder tot war.

Für meine Lösung müssen Sie zuerst wissen, dass ich mein / var-Verzeichnis auf einer anderen Festplatte bereitgestellt habe. Und da war das Problem. Mein /etc/fstabfür das /varsah so aus:

/dev/xvdb1 /var ext4 defaults,noatime,_netdev,nofail 0 2

Das Problem war also das _netdev. Weil dies für ein NFS nützlich sein kann, wo Sie ein Netzwerk benötigen, aber nicht für meinen Fall mit dem /varVerzeichnis

Hier ist die Erklärung für _netdev:

Das Dateisystem befindet sich auf einem Gerät, für das ein Netzwerkzugriff erforderlich ist (um zu verhindern, dass das System versucht, diese Dateisysteme bereitzustellen, bis das Netzwerk auf dem System aktiviert wurde).

Nachdem ich das _netdev entfernt hatte, funktionierte alles wieder, auch nach dem Neustart

Ich hatte das gleiche Problem, aber mit einer etwas anderen Lösung.

Mit der Lösung von @joaoolavo habe ich versucht systemctl status systemd-tmpfiles-setup.service:

[root@server ~]# systemctl status systemd-tmpfiles-setup.service
● systemd-tmpfiles-setup.service - Create Volatile Files and Directories
   Loaded: loaded (/usr/lib/systemd/system/systemd-tmpfiles-setup.service; static; vendor preset: disabled)
   Active: inactive (dead)
     Docs: man:tmpfiles.d(5)
           man:systemd-tmpfiles(8)

Beachten Sie, dass Aktiv: Inaktiv (tot).

Beim Neustart von systemd-tmpfiles-setup wurden die Dateien erstellt, die ich in / run / benötigte, und der Status wurde in Active: active (beendet) geändert, obwohl httpd (und in meinem Fall postgresql) offensichtlich nicht geladen wurden:

[root@server ~]# systemctl start systemd-tmpfiles-setup.service
[root@server ~]# systemctl status systemd-tmpfiles-setup.service
● systemd-tmpfiles-setup.service - Create Volatile Files and Directories
   Loaded: loaded (/usr/lib/systemd/system/systemd-tmpfiles-setup.service; static; vendor preset: disabled)
   Active: active (exited) since Fri 2016-03-18 13:35:36 AEDT; 8s ago
     Docs: man:tmpfiles.d(5)
           man:systemd-tmpfiles(8)
  Process: 2551 ExecStart=/usr/bin/systemd-tmpfiles --create --remove --boot --exclude-prefix=/dev (code=exited, status=0/SUCCESS)
 Main PID: 2551 (code=exited, status=0/SUCCESS)

Mar 18 13:35:36 server.org systemd[1]: Starting Create Volatile Files and Directories...
Mar 18 13:35:36 server.org systemd[1]: Started Create Volatile Files and Directories.

Würde es einen Neustart überleben?

Ja tut es. Tatsächlich werden Neustarts jetzt wie erwartet ausgeführt - alle erstellten tmpfiles, httpd und postgresql werden ebenfalls gestartet.

Es scheint, dass der systemd-tmpfiles-setup.serviceStatus " Aktiv" (beendet) und nicht " Inaktiv" (tot) aktiviert sein muss, damit er nach dem Start ordnungsgemäß funktioniert.