ubuntuusers.de

Hallo zusammen,

ich habe nach einem Reboot folgendes Problem festgestellt:

Diverse Dienste (Elasticsearch, Redis, Postgres) starteten nicht mehr bzw. wurden als FAILED gemeldet. Als Ursache konnte ich feststellen, dass die Rechte für die Dienstordner in /var/run auf root:root gesetzt waren. Daraufhin habe ich die Ordnerrechte geändert und die Dienste neu gestartet. Nach einem erneuten Reboot waren sie wieder auf root:root und ich habe gelernt dass die systemd Startscripte diese setzen sollen.

Im Log konnte ich folgende Einträge finden:

Nov 17 04:47:42 h2118376 systemd-tmpfiles[165]: fchownat() of /run/elasticsearch failed: Invalid argument
Nov 17 04:47:42 h2118376 systemd-tmpfiles[165]: fchownat() of /run/kopano failed: Invalid argument
Nov 17 04:47:42 h2118376 systemd-tmpfiles[165]: fchownat() of /run/kopano failed: Invalid argument
Nov 17 04:47:42 h2118376 systemd-tmpfiles[165]: fchownat() of /run/php failed: Invalid argument
Nov 17 04:47:42 h2118376 systemd-tmpfiles[165]: fchownat() of /run/postgresql failed: Invalid argument
Nov 17 04:47:42 h2118376 systemd-tmpfiles[165]: fchownat() of /run/redis failed: Invalid argument
Nov 17 04:47:42 h2118376 systemd-tmpfiles[165]: fchownat() of /run/screen failed: Invalid argument
Nov 17 04:47:42 h2118376 systemd-tmpfiles[165]: fchownat() of /run/utmp failed: Invalid argument
Nov 17 04:47:42 h2118376 systemd-tmpfiles[165]: fchownat() of /run/systemd/netif failed: Invalid argument
Nov 17 04:47:42 h2118376 systemd-tmpfiles[165]: fchownat() of /run/systemd/netif/links failed: Invalid argument
Nov 17 04:47:42 h2118376 systemd-tmpfiles[165]: fchownat() of /run/systemd/netif/leases failed: Invalid argument
Nov 17 04:47:42 h2118376 systemd-tmpfiles[165]: fchownat() of /run/log/journal failed: Invalid argument
Nov 17 04:47:42 h2118376 systemd-tmpfiles[165]: fchownat() of /run/log/journal/bbad3a438f4b4fb49e5d0700bd5981e8 failed: Invalid argument
Nov 17 04:47:42 h2118376 systemd-tmpfiles[165]: fchownat() of /run/log/journal/bbad3a438f4b4fb49e5d0700bd5981e8/system.journal failed: Invalid argument

Da liegt wohl das Problem. Leider habe ich keine Idee was ich da machen kann. Es lässt sich aber zuverlässig reproduzieren wenn ich systemd-tmpfiles wie folgt aufrufe:

1
2
3
4
5
6
7

/usr/lib/tmpfiles.d# SYSTEMD_LOG_LEVEL=debug systemd-tmpfiles --create elasticsearch.conf
Reading config file "elasticsearch.conf".
Running create action for entry d /var/run/elasticsearch
Found existing directory "/var/run/elasticsearch".
"/run/elasticsearch" has right mode 40755
chown "/run/elasticsearch" to 120.128
fchownat() of /run/elasticsearch failed: Invalid argument

Ich vermute das Problem begann mit dem gestrigen Update auf Systemd 229-4ubuntu21.8. Da es sich um einen Vserver handelt kann ich es nicht mit sicherheit sagen, da ich ihn nicht so häufig reboote. Sonst bin ich mir keiner Änderung bewusst die das beeinflußt haben könnte, v.a. auch weil es alle Dienste betrifft.

Kann mir dazu jemand helfen? Ist das bekannt ... ? Konnte im Internet nichts finden was mir wirklich weiterhilft. Keine Idee was ich prüfen/ändern könnte ...

Bin um jeden Tipp dankbar!

Schöne Grüße

Ein kleines Update, ich habe mir die Quellen des Paket Systemd heruntergeladen und festgestellt, dass "fchownat()" tatsächlich mit dem letzten update eingeführt wurde.

alt:

/.../
                        if (chown(fn,
                                  i->uid_set ? i->uid : UID_INVALID,
                                  i->gid_set ? i->gid : GID_INVALID) < 0)
                                return log_error_errno(errno, "chown(%s) failed: %m", path);
}
/.../

neu:

/.../
    if (fchownat(fd,
                             "",
                             i->uid_set ? i->uid : UID_INVALID,
                             i->gid_set ? i->gid : GID_INVALID,
                             AT_EMPTY_PATH) < 0)
return log_error_errno(errno, "fchownat() of %s failed: %m", path);
/.../

Nun ist die Frage wohl warum fchownat() nicht funktioniert? Hat jemand ein Idee was man da prüfen könnte?

Hallo,

vermutlich hast du auch einen Ubuntu 16.04 Strato-VServer (bzw. allgemeiner: ein OpenVZ-/Virtuozzo-System), wie ich?

In meinen Log-Dateien finden sich nun (mit systemd 229-4ubuntu21.8) folgende Zeilen:

systemd-tmpfiles[134]: fchownat() of /run/systemd/netif/leases failed: Invalid argument
systemd-tmpfiles[134]: fchownat() of /run/systemd/netif/links failed: Invalid argument
systemd-tmpfiles[134]: fchownat() of /run/systemd/netif failed: Invalid argument
systemd-tmpfiles[134]: fchownat() of /run/utmp failed: Invalid argument
systemd-tmpfiles[134]: fchownat() of /run/screen failed: Invalid argument
systemd-tmpfiles[134]: fchownat() of /run/redis failed: Invalid argument
systemd-tmpfiles[134]: fchownat() of /run/postgresql failed: Invalid argument
systemd-tmpfiles[134]: fchownat() of /run/php failed: Invalid argument

Die Fehler haben bei mir allerdings keine erkennbaren negativen Auswirkungen verursacht.

Mit systemd 229-4ubuntu21.9 gab es noch wesentlich schwerwiegendere Fehler: Verschiedene temporäre Ordner wurden beim Boot nicht angelegt, sodass auch SSHD nicht startete:

systemd-tmpfiles[137]: Failed to validate path /var/run/sshd: Too many levels of symbolic links
...
sshd[380]: Missing privilege separation directory: /var/run/sshd

Ich habe die alten Paketversionen 229-4ubuntu21.8 von LaunchPad heruntergeladen, installiert und mit apt-mark von Updates ausgeschlossen:

1
2

dpkg -i libpam-systemd_229-4ubuntu21.8_amd64.deb systemd_229-4ubuntu21.8_amd64.deb libsystemd0_229-4ubuntu21.8_amd64.deb
apt-mark hold systemd libsystemd0 libpam-systemd

Da geht’s zu den Download-Links:

• https://launchpad.net/ubuntu/xenial/amd64/systemd/229-4ubuntu21.8

• https://launchpad.net/ubuntu/xenial/amd64/libpam-systemd/229-4ubuntu21.8

• https://launchpad.net/ubuntu/xenial/amd64/libsystemd0/229-4ubuntu21.8

Das ist allerdings auch nur eine provisorische Lösung. Auf meinem NetCup-VServer gibt es solche Probleme nicht.

Es zeigt sich, dass die Fehlemeldungen bei

fchownat()

auch auf meinem Server auch nicht harmlos sind/waren. Dort legen sie zur Zeit PostgreSQL lahm:

postgresql@9.5-main[259]: ... [338-1] FATAL:  could not create lock file "/var/run/postgresql/.s.PGSQL.5432.lock": Permission denied

Das Problem ist auch auf LaunchPad bekannt: https://answers.launchpad.net/ubuntu/+source/systemd/+question/676237

Mit der Version 229-4ubuntu21.6 von systemd funktioniert alles. Die Links zu den Paketen sind entsprechend:

• https://launchpad.net/ubuntu/xenial/amd64/systemd/229-4ubuntu21.6

• https://launchpad.net/ubuntu/xenial/amd64/libpam-systemd/229-4ubuntu21.6

• https://launchpad.net/ubuntu/xenial/amd64/libsystemd0/229-4ubuntu21.6

Dauerhaft möchte ich das jedoch so nicht behalten, da mit den neuen Versionen kritische Sicherheitslücken beseitigt werden, siehe: http://changelogs.ubuntu.com/changelogs/pool/main/s/systemd/systemd_229-4ubuntu21.9/changelog

Hi Libro,

danke für die Links/Info. Ich hatte ehrlich gesagt etwas Bedenken downzugraden, da ich zusätzliche Probleme befürchtet habe und der Server/Dienste zumindest läuft wenn man die Rechte manuell (habe ein Startscript eingerichtet) setzt. Werde es versuchen, hoffe es klappt bei mir auch.

Wir sitzen da wohl im gleichem Boot, ebenfalls Strato-VPS - bin dort seit ~6 Jahren, 5 Jahre nie ein Problem, dieses Jahr ist wohl nicht meins. V 229-4ubuntu21.9 hatte ich auch installiert, mit dem selben Ergebnis. Strato hat mir zurückgemeldet, dass es in ihren Testumgebungen den gleichen Effekt gibt und man auf ein Update seitens Virtuozzo/Ubuntu warten müsste.

Hallo Zusammen,

ich bin auf diesen Thread gestoßen, nachdem mein Ubuntu 16.04 Server bei Strato nach dem Update (unter anderem) dieser Paketen:

libsystemd0/xenial-updates,xenial-security 229-4ubuntu21.9 amd64 [aktualisierbar von: 229-4ubuntu21.6]
libudev1/xenial-updates,xenial-security 229-4ubuntu21.9 amd64 [aktualisierbar von: 229-4ubuntu21.6]
systemd/xenial-updates,xenial-security 229-4ubuntu21.9 amd64 [aktualisierbar von: 229-4ubuntu21.6]
systemd-sysv/xenial-updates,xenial-security 229-4ubuntu21.9 amd64 [aktualisierbar von: 229-4ubuntu21.6]
udev/xenial-updates,xenial-security 229-4ubuntu21.9 amd64 [aktualisierbar von: 229-4ubuntu21.6]

der openssh-server nicht mehr funktionierte. Im syslog steht nur:

Nov 22 12:49:24 h2xxxxxx systemd-tmpfiles[131]: Failed to validate path /var/run/sshd: Too many levels of symbolic links
Nov 22 12:49:24 h2xxxxxx sshd[309]: Missing privilege separation directory: /var/run/sshd
Nov 22 12:49:24 h2xxxxxx sshd[537]: Missing privilege separation directory: /var/run/sshd
Nov 22 12:49:25 h2xxxxxx sshd[540]: Missing privilege separation directory: /var/run/sshd
Nov 22 12:49:25 h2xxxxxx sshd[558]: Missing privilege separation directory: /var/run/sshd
Nov 22 12:49:26 h2xxxxxx sshd[566]: Missing privilege separation directory: /var/run/sshd

Nun habe ich einen Snapshot von vor dem Update wieder eingespielt, weiss aber nicht wie ich weitermachen soll. Was meint ihr? Soll ich warten bis 229-4ubuntu21.10 zur Verfügung steht, oder die 229-4ubuntu21.9 installieren und den Fehler irgendwie beheben? Ich habe es nicht hinbekommen open-ssh zum laufen zu bekommen mit 229-4ubuntu21.9, hauptsächlich weil ich ja über das Rescue System zwar ans Dateisystem komme, aber mehr auch nicht. Und das Verzeichnis /var/run/sshd ist auf der Platte. Zwar leer, aber es ist da.

Servus,

das erste Problem, fchownat, ist nun ein Bug geworden: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1804847

Das "Too many levels of symbolic links" ist m.E. ein neues Problem mit 21.9.

Vermute dein /var/run/sshd Verzeichnis gehört zum Rescuesystem wenn du damit angemeldet bist. Nach meinem Verständnis wird das erst beim Start erstellt und beim Shutdown gelöscht weil es auf temp liegt:

/# mount |grep /run
 tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755)

/var/run ist ein Link auf /run:

/var# dir run
 lrwxrwxrwx 1 root root 4 Apr  1  2018 run -> /run

Du müsstest sicherstellen, dass /var/run/sshd vor dem Start von SSHD vorhanden ist und die Rechte entsprechend gesetzt sind. Habe bei mir erst ein Startscript erstellt, dass die Berechtigungen manuell setzt. Bin dann aber Libros Vorschlag gefolgt und habe 21.6 installiert und updates zurückgehalten, damit läuft es wieder. Somit gibt es zumindest einen Workaround.

Hallo zusammen, habe dasselbe Problem wie Bernd. Nach einem Reboot des Server kommt man nicht mehr per SSH drauf. Funktioniert bei euch das Plesk noch? Denn bei mir gibts den PLESK 500 Error. Webseiten etc. funktionierten noch. Für alle die dasselbe Problem mit dem SSH haben und dem Plesk hab ich wie folgt gelöst. So kann ich zumindest wieder konnekten und Plesk geht au. Backup wieder eingespielt. Zuerst muss man Plesk wieder so einrichten das die Rechte passen. Solltest du gar kein Backup / SNapshot / rescue system haben solltest du dich an deinen hoster wenden der kann das sicherlich auch richten. also zu plesk hier der link was bei mir funktioniert hat. hier der Link: https://support.plesk.com/hc/en-us/articles/115000224773-Plesk-is-not-accessible-Can-t-open-or-create-shared-memory-by-shm-name

nun:

1
2
3
4
5
6

root@mail:~# cp -a /usr/lib/tmpfiles.d/{courier-authdaemon,screen-cleanup,sshd,sudo}.conf /etc/tmpfiles.d/
root@mail:~# sed -i s#\ /var/run/#\ /run/#g /etc/tmpfiles.d/{courier-authdaemon,screen-cleanup,sshd,sudo}.conf
root@mail:~# mkdir /run/sshd
mkdir: cannot create directory ‘/run/sshd’: File exists
root@mail:~# /etc/init.d/ssh restart
[ ok ] Restarting ssh (via systemctl): ssh.service.

im falle das die /rund/sshd nicht existiert muss man diese neu anlegen. (im meinem fall was diese vorhanden)

ich hoffe damit einigen helfen zu können. Zumindest bei mir hats geholfen,

Mein System:

1
2
3
4
5
6
7
8

System: 
Distributor ID:	Ubuntu
Description:	Ubuntu 16.04.5 LTS
Release:	16.04
Codename:	xenial
root@mail:~# uname -a
Linux mail.xxxx 4.4.0-042stab133.2 #1 SMP Mon Aug 27 21:07:08 MSK 2018 x86_64 x86_64 x86_64 GNU/Linux
root@mail:~#

Übrigens das systemd hab ich heute per apt-get update und upgrade eingespielt. Hoffentlich gibts bald eine aktualisierte...

Viele Grüße Luke

Ich habe das gleiche Problem aber kein Plesk, nur den Recoverymode von Strato. Leider ist mir unklar, wie ich das Problem in diesem Modus lösen kann. Hat einer bitte einen Tip für mich.

Gruß Christian

Hey Christian, hier musst du definitiv an strato schreiben damit die sich dort einloggen und dir wieder das ssh öffnen. ansonsten sieht es nicht so gut aus leider ☹ beim ersten mal konnte mir nur mein hoster helfen. Viele Grüße Luke

p.s. eventuell über das Virtuozzo PowerPanel probieren einzuloggen.glaube das müsste der port 4643 sein. Dort müsste es auch ein SSH geben. Aber keine Ahnung ob strato sowas hat. Schreib einfach mal an strato sie sollen sich einloggen über den rechner direkt und dir das wieder frei schalten. viel erfolg !

Weniger schön. Aber vielen Dank mastaluke.

gruß christian

@riffraff99: Ich hatte schon unter /repair nachgesehen. Hatte mir auch den Output gespeichert:

root@h27xxxxx:~# cd /repair/var/run/
root@h27xxxxx:/repair/var/run# ll
total 24
drwxr-xr-x 14 root root  440 Nov 22 13:59 ./
drwxr-xr-x 23 root root 4096 Nov 22 13:54 ../
-rw-------  1 root root    0 Nov 22 13:54 agetty.reload
-rw-r--r--  1 root root    4 Nov 22 13:54 crond.pid
----------  1 root root    0 Nov 22 13:54 crond.reboot
lrwxrwxrwx  1 root root   25 Nov 22 13:54 initctl -> /run/systemd/initctl/fifo|
drwxrwxrwt  3 root root   60 Nov 22 13:54 lock/
drwxr-xr-x  3 root root   60 Nov 22 13:54 log/
-rw-r--r--  1 root root  211 Nov 22 13:59 motd.dynamic
drwxr-xr-x  2 root root   60 Nov 22 13:54 mount/
drwxr-xr-x  2 root root  140 Nov 22 13:54 network/
-rw-r--r--  1 root root    3 Nov 22 13:54 rsyslogd.pid
drwxrwxr-x  2 root utmp   40 Nov 22 13:54 screen/
drwxr-xr-x  2 root root   40 Nov 22 13:54 sendsigs.omit.d/
drwxrwxrwt  2 root root   40 Nov 22 13:54 shm/
drwxr-xr-x  2 root root   40 Nov 22 13:54 sshd/
-rw-r--r--  1 root root    4 Nov 22 13:54 sshd.pid
drwx--x--x  3 root root   60 Nov 22 13:54 sudo/
drwxr-xr-x 15 root root  360 Nov 22 13:54 systemd/
drwxr-xr-x  4 root root  100 Nov 22 13:54 udev/
drwxr-xr-x  2 root root   40 Nov 22 13:54 user/
-rw-rw-r--  1 root utmp 1920 Nov 22 13:55 utmp
root@h27xxxxx:/repair/var/run# 

@mastaluke: Aber wie gesagt, ich habe einen Rollback mit dem Snapshot vom Vortag gemacht.

Ich habe eben nachgesehen, und Strato hat wohl die 21.9 auch vom Update-repo genommen. Ein "apt list --upgradable" gibt nun kein systemd mehr aus zum updaten. Also erst mal abwarten und die Situation im Auge behalten.

PS: Plesk habe ich nicht...

Ach ist das "schön"... 👿

Gleiches Problem bei VServern von Server4you (Host Europe). Konnte nur über ein Backup wiederbelebt werden. Die vergangenen zwei Monate waren nicht mein Ding. Erst brach mir aus nicht erklärbaren Gründen immer wieder der Bind weg, dann wollte ClamAV plötzlich nicht mehr, nach Update verabschiedete sich Spamassassin und nun der Obergau das der SSH-Zugang wegbrach. Komm mir vor als hätte ich nen Windows am laufen.

Sorry, mein Beitrag war jetzt nicht gerade produktiv, aber wenn das Vertrauen in die Stabilität von Updates innerhalb so kurzer Zeit mehrfach erschüttert wird, kommt man ins grübeln.