# Einige Fehlermeldungen in rc.log beseitigen?

## Andreas O.

Hallo, 

endlich habe ich es geschafft, die schnell vorbei huschenden Fehlermeldungen beim Booten in eine Log-Datei zu bringen:

Zuerst habe ich meinen Logger 'metalog' zum Boot-Level hinzugefügt:

```
rc-update add metalog boot
```

dann noch in /etc/rc.conf

```
 rc_logger="YES"
```

 gesetzt.

Nach dem Neustart habe ich dann endlich eine /var/log/rc.log vorgefunden.

Hier also sind auszugsweise die Fehlermeldungen:

```
* Starting metalog ...

 [ ok ]

 * Setting up tmpfiles.d entries ...

mkdir: das Verzeichnis „/run/apache2“ kann nicht angelegt werden: Die Datei existiert bereits

mkdir: das Verzeichnis „/run/apache_ssl_mutex“ kann nicht angelegt werden: Die Datei existiert bereits

mkdir: das Verzeichnis „/run/saslauthd“ kann nicht angelegt werden: Die Datei existiert bereits

mkdir: das Verzeichnis „/var/run/mysqld“ kann nicht angelegt werden: Die Datei existiert bereits
```

Ich habe mal geschaut, wo es solch ein tmpfiles.d gibt, da kamen aber leider zu viele Treffer:

```
locate tmpfiles.d

/etc/runlevels/sysinit/tmpfiles.dev

/portage/app-admin/puppet/files/tmpfiles.d

/portage/app-antivirus/clamav/files/tmpfiles.d

/portage/app-antivirus/clamav/files/tmpfiles.d/clamav.conf

/portage/net-ftp/proftpd/files/proftpd-tmpfiles.d.conf

/usr/lib64/tmpfiles.d

/usr/lib64/tmpfiles.d/apache.conf

/usr/lib64/tmpfiles.d/cyrus-sasl.conf

/usr/lib64/tmpfiles.d/eix.conf

/usr/lib64/tmpfiles.d/lvm2.conf

/usr/lib64/tmpfiles.d/man-db.conf

/usr/lib64/tmpfiles.d/mysql.conf

/usr/lib64/tmpfiles.d/revdep-rebuild.conf

/usr/portage/app-admin/puppet/files/tmpfiles.d

/usr/portage/app-antivirus/clamav/files/tmpfiles.d

/usr/portage/app-antivirus/clamav/files/tmpfiles.d/clamav.conf

/usr/portage/app-misc/elasticsearch/files/elasticsearch.tmpfiles.d

/usr/portage/dev-db/etcd/files/etcd.tmpfiles.d.conf

/usr/portage/net-analyzer/greenbone-security-assistant/files/gsad.tmpfiles.d

/usr/portage/net-analyzer/openvas-scanner/files/openvassd.tmpfiles.d

/usr/portage/net-ftp/proftpd/files/proftpd-tmpfiles.d.conf

/usr/portage/sys-fs/cachefilesd/files/cachefilesd-tmpfiles.d
```

Ich habe als Erstes also mal auf das /usr/lib64/tmpfiles.d/apache.conf  getippt und Folgendes drin gefunden:

```
d /run/apache2 710 root apache

d /run/apache_ssl_mutex
```

Da ich mich mit Skripten leider zu wenig auskenne: soll ich die beiden Einträge hier auskommentieren oder löschen, damit die Fehlermeldungen verschwinden?

Oder wo sonst kann ich das abstellen, dass hier keine neuen DIRs angelegt werden sollen?

```
* Starting DHCP Client Daemon ...

 [ ok ]

 * /etc/init.d/rpcbind uses runscript, please convert to openrc-run.

 * Starting rpcbind ...

 [ ok ]

 * /etc/init.d/rpc.statd uses runscript, please convert to openrc-run.

 * Starting NFS statd ...

 [ ok ]

 * /etc/init.d/rpc.pipefs uses runscript, please convert to openrc-run.

 * Setting up RPC pipefs ...

 [ ok ]

 * /etc/init.d/rpc.idmapd uses runscript, please convert to openrc-run.

 * Starting idmapd ...

 [ ok ]

 * /etc/init.d/nfsclient uses runscript, please convert to openrc-run.

```

Ich habe dazu u.a. Folgendes googeln können:

https://forums.gentoo.org/viewtopic-p-8048632.html oder:

https://forums.gentoo.org/viewtopic-t-1045350-start-0.html

Gut, ich könnte auf gut Glück die sed-Befehle ausführen oder versuchen, wie in diesen Beiträgen vorgeschlagen, auch einen Patch einspielen (dieser war aber noch für die openrc version 0.21, ich habe aber mittlerweile die Version 0.23.2).

Was ich einfach grundsätzlich nicht verstehe, ist, warum, wenn schon Änderungen von runscript auf openrc-run erfolgen, diese nicht automatisch beim Update durchgeführt werden?

Ich finde es einfach eine Zumutung für einen normaler User, der vom Programmieren wenig oder gar keine Ahnung hat, dass hier mit kryptischen "sed-Befehlen" manuell "nachgebessert" werden soll und auch noch manuell ein backup von den geänderten System-Skripten gemacht werden soll!? Es wäre doch für einen Programmierer ein Leichtes, ein Umwandlungs-Skript zu schreiben, das auch noch ein kleines Backup-Skript enthält, wenn das System dadurch nicht mehr bootbar ist, also z. B. automatisch eine rpc.statd.bak erzeugt.

Ehrlich gesagt, traue ich diesen partiellen Lösungen nicht ganz, und, soweit ich mitbekommen habe, sind die Änderungen bei einem Update doch sowieso wieder weg, oder?

Gibt es hier mittlerweile eine elegantere Lösung?

----------

## mvaterlaus

hi,

ich habe zwar nicht so viel Erfahrung mit tmpfiles.d, jedoch denke ich, dass du die entsprechenden Zeilen ausklammern kannst. Falls der Apache dann mal nicht startet, könnte es sein, dass er diese Dateien vermisst --> einfach daran denken.

 *Andreas O. wrote:*   

> 
> 
> Es wäre doch für einen Programmierer ein Leichtes, ein Umwandlungs-Skript zu schreiben, das auch noch ein kleines Backup-Skript enthält, wenn das System dadurch nicht mehr bootbar ist, also z. B. automatisch eine rpc.statd.bak erzeugt.
> 
> 

 

So einfach ist das nicht. Das Problem hierbei ist, dass die Init Scripts der Daemons am Anfang des Scripts die Zeile

```
#!/sbin/runscript
```

anstatt

```
#!/sbin/openrc-run
```

stehen haben. Dies führt nicht zu einem Fehler, jedoch nerven die Warnungen. Wenn du nun ein Script hast, welches das ändert, musst du dieses auch wieder ausführen, wenn du z. B. Apache neu installierts (muss kein Upgrade sein). Somit wird die Installation das Init Script überschreiben und die Meldung erscheint erneut. Folglich müsste jeder Daemon ein entsprechendes Script haben, welches prüft, welche open-rc Version installiert ist, und gegebenenfalls dann die erste Zeile ersetzt. Wie gesagt, es ist nur eine Warnung, da openrc-run und runscript nur Symlinks auf /sbin/openrc sind:

```

ls -lah /sbin/

...

lrwxrwxrwx  1 root root   12 26. Jan 2016  openrc-run -> /sbin/openrc

...

lrwxrwxrwx  1 root root   12 26. Jan 2016  runscript -> /sbin/openrc

...

```

Falls dir die Meldungen wirklich auf den Sack gehen, kannst du auch ein Script [1] nach der Ausführung eines jeden emerge Befehls aufrufen, welches alle Dateien in /etc/init.d/ prüft, ob sie die alte Version haben, und diese dann auch ersetzen.

[1]https://forums-web2.gentoo.org/viewtopic-t-964252-start-0.html

----------

## Josef.95

 *Quote:*   

> [...] uses runscript, please convert to openrc-run.

  Inzwischen sollten eigentlich alle Initscripte auf openrc-run migriert worden sein. Dies geschah aber meist ohne Version-Bump

sprich, man bekommt die Neuerung erst mit einer neuen Version, oder einem rebuild.

```
emerge -1av $(qfile -Cq $(grep -FrH "/sbin/runscript" /etc/init.d/ | cut -d ":" -f 1) | sort -u)
```

 (das Kommando stammt von Poly-C) (app-portage/portage-utils sollte installiert sein)

^ Damit kann ein rebuild aller noch nicht migrierten Initscripte-Pakete vorgenommen werden.

----------

## Andreas O.

Danke für Eure Antworten, jetzt bin ich wieder ein bischen schlauer   :Very Happy: 

 *Quote:*   

> Es wäre doch für einen Programmierer ein Leichtes, ein Umwandlungs-Skript zu schreiben, das auch noch ein kleines Backup-Skript enthält, wenn das System dadurch nicht mehr bootbar ist, also z. B. automatisch eine rpc.statd.bak erzeugt. 

 

Und übrigens nichts für ungut, wenn sich hier ein Maintainer von openrc angegriffen fühlen sollte, das war keineswegs meine Absicht   :Embarassed: 

Ich bin halt kein Fan von einem für mich "proprietären" systemd (das m.E. u.a. von Red Hat entwickelt wurde), aber das muss eben jeder für sich selbst entscheiden   :Wink: 

Das ist mit ein Grund, warum ich Gentoo so liebe - Freiheit über alles   :Very Happy: 

----------

## musv

 *Andreas O. wrote:*   

> Hier also sind auszugsweise die Fehlermeldungen:
> 
> ```
> * Starting metalog ...
> 
> ...

 

Das ist ja erst mal kein Fehler.

 *Andreas O. wrote:*   

> Ich habe als Erstes also mal auf das /usr/lib64/tmpfiles.d/apache.conf  getippt und Folgendes drin gefunden:
> 
> ```
> d /run/apache2 710 root apache
> 
> ...

 

tmpfiles.d kam im Zuge von Systemd mal nebenbei mit reingeflattert. Ob das jetzt gut oder schlecht ist, lass ich mal dahingestellt. Sinn des Ganzen ist es, temporäre Verzeichnisse zu erzeugen, die dann auch in bestimmten Abständen automatisch gelöscht werden können. 

Die Hauptanwendung ist allerdings die Erstellung von Verzeichnissen in /run (oder /var/run, was im Endeffekt ein Symlink auf /run ist), um dort das Ablegen von Pid-Files mit User-Rechten zu ermöglichen. Unter Systemd kann man beim Start eines Daemons angeben, unter welchem Systemuser, z.B. Apache, Mysql, Pyload usw. das Programm dann läuft. Dummerweise haben diese User normalerweise keine Schreibrechte in /run, weswegen es bei Systemd dann beim Start des Daemons knallt. Und dafür legt halt tmpfiles.d die entsprechenden Verzeichnisse mit den speziell zugewiesenen Rechten, Eigentümern und Gruppen dort hab. 

Jetzt weiß ich nicht mehr, wie das unter openrc gemacht wird. Mysql unterstützt z.B. die Übergabe des Users als Parameter. Der Mysql-Daemon wird zwar als root gestartet, taucht dann aber in der Prozessliste unter dem Nutzer mysql auf. Bei Apache2 dürfte das ebenso gewesen sein. Viele andere Daemons haben diese Möglichkeiten allerdings nicht. Insofern hat tmpfiles.d durchaus seine Berechtigung.

(Manpage)

Ergänzung:

Nach Systemd-Philosophie stehen die Default-Scripte in /usr/lib64/tmpfiles.d, wo du die ja auch schon gefunden hast. Willst du die Dinger modifizieren, dann kopierst du die entsprechenden Dateien nach /etc/tmpfiles.d und änderst die dort ab. Die Dateien in /etc/tmpfiles.d überdecken dann die in /usr/lib64/tmpfiles.d. Das hat den Sinn, dass Deine Änderungen bei einem Paketupdate erhalten bleiben und du außerdem nicht im Lib-Verzeichnis rumeditieren musst.

----------

## mv

 *Andreas O. wrote:*   

> Es wäre doch für einen Programmierer ein Leichtes, ein Umwandlungs-Skript zu schreiben

 

Es ist die Aufgabe des Skriptautors, dieses anzupassen. Ich würde mich "bedanken", wenn das Initsystem auf die Idee käme, meine Config-Files einfach zu editieren, wie es glaubt, dass sie "richtig" zu sein hätten:

Die unangenehmen Wirkungen gingen dann schon damit los, dass dann die Prüfsummen der Dateien dadurch nicht mehr mit den von portage gespeicherten übereinstimmen. Wer möglicherweise noch andere Systeme mit Prüfsummentests fährt, etwa um Angriffe potentieller rootkits zu entdecken, bekommt möglicherweise sogar ein unbootbares System, wenn dieser Sicherheitsmechanismus einen vermeinlichen "Angriff" durch diesen Automatismus erkennt.

Nein, eine einfache Meldung auszugeben, die keine negativen Nebenwirkungen hat, und den Autor des Skripts Monate/Jahre im voraus warnt, dass das Skript geändert werden müsste, ist schon der richtige Weg.

Das eigentliche Problem ist, dass es Jahre gedauert hat, bis sich jemand aus Gentoo dieser Fehlermeldungen mal angenommen hat: Dies zeigt, dass sich die Maintainer einer großen Anzahl von Paketen jahrelang nicht um ihre Pakete kümmern.

Zu dem anderen Problem: Die eigentliche Frage ist hier, warum die Directories bereits existieren. Liegt bei Dir /run nicht auf einer ramdisk? Und/oder ist /var/run kein symbolischer Link auf /run?

Diejenigen tmpfiles, die z.B. /run/apache2 anlegen, solltest Du so herausfinden können:

```
grep run/apache2 /usr/lib/tmpfiles.d/* /etc/tmpfiles.d/* /run/tmpfiles.d/*
```

Wenn da apache2 nur einmal auftaucht, legt irgendetwas das Directory /run/apache2 an, noch bevor /etc/init.d/opentmpfiles-setup ausgeführt wird. Du solltest herausfinden, was das ist. Falls es apache selbst sein sollte, fehlt da mit Sicherheit eine Abhängigkeit…

----------

