Le répertoire PidFile d'Apache est supprimé à chaque démarrage

À chaque redémarrage du serveur, le répertoire / run / httpd est supprimé. / run est un système de fichiers tmpfs, donc monté en RAM.

/ run / httpd est créé uniquement lors de l'installation. Lorsque je démarre httpd après le redémarrage, le répertoire n'est pas recréé.

Le serveur a installé CentOS 7 et le package Apache du référentiel officiel (v. 2.4.6-18).

Après l'installation et le démarrage d'Apache, le répertoire est le suivant:

# 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 ..

Mais après le redémarrage:

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

Et voici les journaux lorsque vous essayez de redémarrer 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'

Lorsque je crée le répertoire manuellement, Apache démarre:

# 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

Et après le redémarrage, c'est reparti.

Avez-vous une idée de la raison pour laquelle cela se produit?

Le problème était que, lors de l'installation d'Apache, le groupe apache n'était pas créé.

# 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.

C'est parce que j'ai un serveur NIS configuré, avec un utilisateur Apache NIS . Comme elle a un utilisateur apache , l'installation Apache ne crée pas de groupe apache . Mais le groupe apache existe aussi sur NIS! Eh bien, NIS gâche les choses.

En résumé, je dois arrêter ypbind, installer Apache puis redémarrer ypbind (ou simplement créer manuellement un groupe apache dans / etc / group).

J'avais la même solution à mon problème que @datakid, à la différence qu'après un redémarrage, le systemd-tmpfiles-setup.serviceétait à nouveau mort.

Pour ma solution, vous devez d'abord savoir que j'ai monté mon répertoire / var sur un disque différent. Et il y avait le problème. Mon /etc/fstabpour le /varressemblait à ceci:

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

Le problème était donc le _netdev. Parce que cela pourrait être utile pour un NFS, où vous avez besoin d'un réseau mais pas pour mon cas avec le /varrépertoire

Voici l'explication de _netdev:

Le système de fichiers réside sur un périphérique qui nécessite un accès réseau (utilisé pour empêcher le système de tenter de monter ces systèmes de fichiers jusqu'à ce que le réseau soit activé sur le système).

Après avoir supprimé le _netdev, tout fonctionnait à nouveau, également après le redémarrage

J'ai eu ce même problème mais avec une solution légèrement différente.

En utilisant la solution de @joaoolavo , j'ai essayé 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)

Notez que Actif: inactif (mort).

Le redémarrage de systemd-tmpfiles-setup a créé les fichiers dont j'avais besoin dans / run /, et le statut a été changé en Actif: actif (quitté), bien que, évidemment, httpd (et dans mon cas, postgresql) n'était pas chargé:

[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.

Survivrait-elle à un redémarrage?

Oui. En fait, les redémarrages se font maintenant comme prévu - tous les fichiers tmp créés, httpd et postgresql sont également démarrés.

Il semblerait que systemd-tmpfiles-setup.servicedoit être dans l'état actif actif (quitté) plutôt que inactif (mort) pour fonctionner correctement après le démarrage.