| View previous topic :: View next topic |
| Author |
Message |
Andreas O.
Tux's lil' helper
Joined: 04 Jan 2003
Posts: 132
Location: Welthauptstadt der Biere
|
 Posted: Fri Mar 31, 2017 8:59 am Post subject: Einige Fehlermeldungen in rc.log beseitigen? |
 |
|
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:
| Code: | | rc-update add metalog boot |
dann noch in /etc/rc.conf
gesetzt.
Nach dem Neustart habe ich dann endlich eine /var/log/rc.log vorgefunden.
Hier also sind auszugsweise die Fehlermeldungen:
| Code: | * 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:
| Code: | 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:
| Code: | 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?
| Code: | * 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? |
|
| Back to top |
|
 |
mvaterlaus
Apprentice
Joined: 01 Oct 2010
Posts: 234
Location: Switzerland
|
| Posted: Fri Mar 31, 2017 1:28 pm Post subject: |
|
|
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
anstatt
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:
| Code: |
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
_________________
For calming down your eyes or clearing your mind: www.patrickwehli.ch |
|
| Back to top |
|
|
Josef.95
Advocate
Joined: 03 Sep 2007
Posts: 4553
Location: Germany
|
| Posted: Fri Mar 31, 2017 3:54 pm Post subject: |
|
|
| 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.
| Code: | | 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. |
|
| Back to top |
|
|
Andreas O.
Tux's lil' helper
Joined: 04 Jan 2003
Posts: 132
Location: Welthauptstadt der Biere
|
| Posted: Fri Mar 31, 2017 6:15 pm Post subject: |
|
|
Danke für Eure Antworten, jetzt bin ich wieder ein bischen schlauer 
| 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 
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 
Das ist mit ein Grund, warum ich Gentoo so liebe - Freiheit über alles |
|
| Back to top |
|
|
musv
Advocate
Joined: 01 Dec 2002
Posts: 3337
Location: de
|
| Posted: Fri Mar 31, 2017 7:33 pm Post subject: |
|
|
| Andreas O. wrote: | Hier also sind auszugsweise die Fehlermeldungen:
| Code: | * 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 |
|
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:
| Code: | 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? |
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. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Sat Apr 01, 2017 4:12 pm Post subject: Re: Einige Fehlermeldungen in rc.log beseitigen? |
|
|
| 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:
| Code: | | 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… |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Deutsches Forum (German)
