Siduction Forum
Siduction Forum => Upgrade Warnings => Topic started by: hsp on 2015/05/11, 08:46:27
-
Ich hab hier schon seit einiger Zeit folgende Meldung im Journal zu rpcbind, man sieht sie auch kurz beim booten. Die folge ist das der nfs-server nicht ordnungsgemäss startet. Erst nach dem er manuell restartet wurde funktioniert er korrekt.
Jemand ne Idee was da los ist?
systemd[1]: ^[[1;39mFound ordering cycle on basic.target/start
systemd[1]: ^[[1;39mFound dependency on sysinit.target/start
systemd[1]: ^[[1;39mFound dependency on rpcbind.service/start
systemd[1]: ^[[1;39mFound dependency on network-online.target/start
systemd[1]: ^[[1;39mFound dependency on network.target/start
systemd[1]: ^[[1;39mFound dependency on wpa_supplicant.service/start
systemd[1]: ^[[1;39mFound dependency on basic.target/start
systemd[1]: ^[[1;39mBreaking ordering cycle by deleting job rpcbind.service/start
systemd[1]: Job rpcbind.service/start deleted to break ordering cycle starting with basic.target/start
danke...
-
Hallo hsp,
anscheinend wird der rpcbind.service zu früh gestartet, noch bevor das Netzwerk initialisiert werden kann.
Gruß
musca
-
Naja, ich nutze den Network-Manager wie viel andere auch. Wenn ich es per interfaces mache ändert das auch nix, die Meldung bleib und die nfs-shares funktionieren erst, wie schon erwähnt. nach einem manuellen restart.
...
-
Hi hsp,
zeig mal die Ausgabe von systemctl status rpcbind.service. Irgendetwas verändert an den Servicedateien (rpcbind.service)?
Was sagt systemd-analyze blame?
-
Moin bluelupo, bitteschön.
Ich hab nix verändert oder editiert. Mittlerweile habe ich was per Google gefunden.
Mit dem Problem bin ich nicht allein, ne Lösung hat aber keiner. Das hier zum Beispiel. Verstehen tu ich aber nix.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=763315
● rpcbind.service - LSB: RPC portmapper replacement
Loaded: loaded (/etc/init.d/rpcbind)
Drop-In: /run/systemd/generator/rpcbind.service.d
└─50-rpcbind-$portmap.conf
Active: active (running) since Mo 2015-05-11 17:05:36 CEST; 2min 25s ago
Process: 820 ExecStart=/etc/init.d/rpcbind start (code=exited, status=0/SUCCESS)
CGroup: /system.slice/rpcbind.service
└─869 /sbin/rpcbind -w
-
Hi hsp,
hmmm, ich hab' gerade mal an zwei Geräten bei mir das Journal überprüft keine Fehlermeldungen vom rpcbind. Hast du schon mal einen reconfigure von rpcbind versucht?
-
Ich hab sogar schon ein kommplettes Reinstall der NFS-Geschichte gemacht. Bisher hat nix geholfen. Selbst ein downgrade nach Jessie geht nicht, weil da noch die gleichen Pakete sind wie in SID. In Jessie ist allerdings das Problem nicht!
...
-
Ist bei Dir der NetworkManager-wait-online.service enabled? (systemctl enable $foo)
If experiencing any issues with the mount failing due to the network not being up/available, enable NetworkManager-wait-online.service. It will ensure that network.target has all the links available prior to being active.
-
Der Service ist bei mir aus (disabled). Aktivieren ändert an der Geschichte auch nix. wäre ja auch zu schön gewesen :)
...
-
Bist nicht der Einzige der sich seit einigen Tagen mit den frühen Start von Netzwerkabhängegen Appz rumärgert.
Hier Spinnt ddclient & CO obwohl sie warten sollten
After=network.target
Nun langsam nervt diese Beta Hure >:(
In Jessie ist allerdings das Problem nicht!
SID Halt! und schaue dir einfach mal die Unterschiede zu Testing/Stable an
NM ? Freiwillig niemals ;D
-
Ich habe eben mal fix ein nfs-server in der Vbox eingerichtet. Exakt das gleiche Verhalten. Die Shares sind erst nach einem manuellen restart verfügbar weil rpcbind sich beim booten irgendwie mit besagter Meldung verabschiedet..
...
-
Hallo,
mir fallen dazu zwei Ausweichmöglichkeiten ein:
Mit ceni das Netzwerk einrichten, oder mal als Alternative zum nm Wicd versuchen.
Viele Grüße,
Holger
-
Hallo Namensvetter :)
Das hat mit dem Netzwerk (start/stop/cen/wicd oder wie auch immer) nix zu tun. Ich hab mittlerweile alles mögliche durchprobiert. Selbst mit komplett deaktivierten Netzwerk ändert sich an dem Verhalten absolut nix.
Holger...
-
Das habe ich noch gefunden bei den Debian Bugreports (hilft dir leider aber nicht weiter)
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=761951
mit einem Verweis auf den hier:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=761951
Sollte eigentlich gefixt sein, so wie ich das verstehe.
-
Hallo Namensvetter :)
Das hat mit dem Netzwerk (start/stop/cen/wicd oder wie auch immer) nix zu tun. Ich hab mittlerweile alles mögliche durchprobiert. Selbst mit komplett deaktivierten Netzwerk ändert sich an dem Verhalten absolut nix.
Holger...
Hallo Holger,
heute werde ich mal siduction neu aufsetzen, ich wollte mir auf Basis von der xorg iso mein KDE selbst zusammen stellen.
Ich arbeite auch mit nfs, auf dem NAS läuft Debian Jessie. Ich werde dann hier mal berichten, ob es läuft.
Noch eine Frage, Du schreibst: Ich hab hier schon seit einiger Zeit folgende Meldung im Journal zu rpcbind, man sieht sie auch kurz beim booten. Die folge ist das der nfs-server nicht ordnungsgemäss startet.
Du redest doch aber vom Client, auf dem die nfs-Freigaben gemountet werden sollen. Da muss doch gar kein nfs-server starten. Oder stehe ich gerade auf dem Schlauch?
Viele Grüße,
Holger
-
Moin Holger.
Ja, du siehst das schon richtig. Die Clients haben natürlich keinen NFS-Server, brauchen sie ja auch nicht. Das Problem hat der Server. Auf den Clients (nfs-common) kommt aber auch besagte Meldung von rpcbind, was aber da kein Problem ist..
Ich Klartext: Es braucht immer einen manuellen restart des NFS-Servers.
Da in Jessie und SID derzeit noch die gleichen Versionen von nfs sind, denke ich mir das Problem könnte vielleicht ganz woanders liegen. Aber das ist Spekulation.
Holger...
-
Hi hsp,
kannst du mal mit systemd-analyze dump die Abhängigkeiten beim Booten von rpcbind bzw. den nfs-kernel-server noch überprüfen.
EDIT: Ubuntu hat das Problem ebenso :-(
https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/1452644
-
@Bluelupo, from your ubuntu bug, if it is true
So, it is quite a systematic problem with the System-V init scripts and their dependency setup in systemd.
This old System-V code makes systemD look ugly, just wanted to say that: If you look into the needed Debian patches onto upstream systemD ... ugly
-
Moin.
Ich hatte gestern Abend nochmal an dem Problem etwas rumgefrickelt aber ohne Ergebnis. Seit dem D-U heute Morgen funktioniert das ganze wieder obwohl besagte Meldung von rpcbind noch vorhanden ist. Keine Ahnung warum, aber es geht.
Hier der Auszug aus der apt history.log welche Pakete da kamen. Eines der Paket hat das Problem wohl behoben aber welches *grübel*
Start-Date: 2015-05-27 07:37:19
Commandline: apt-get dist-upgrade
Upgrade: libdebian-installer-extra4:amd64 (0.99, 0.100), libqt4-xml:amd64 (4.8.6+git155-g716fbae+dfsg-2, 4.8.7+dfsg-1), libqt4-network:amd64 (4.8.6+git155-g716fbae+dfsg-2, 4.8.7+dfsg-1), gvfs-bin:amd64 (1.22.2-1+b1, 1.24.1-2), libpython2.7-stdlib:amd64 (2.7.10~rc1-1, 2.7.10-1), qdbus:amd64 (4.8.6+git155-g716fbae+dfsg-2, 4.8.7+dfsg-1), libqtcore4:amd64 (4.8.6+git155-g716fbae+dfsg-2, 4.8.7+dfsg-1), libqt4-svg:amd64 (4.8.6+git155-g716fbae+dfsg-2, 4.8.7+dfsg-1), libqt4-dbus:amd64 (4.8.6+git155-g716fbae+dfsg-2, 4.8.7+dfsg-1), libqt4-opengl:amd64 (4.8.6+git155-g716fbae+dfsg-2, 4.8.7+dfsg-1), libgdk-pixbuf2.0-common:amd64 (2.31.4-1, 2.31.4-2), libqt4-script:amd64 (4.8.6+git155-g716fbae+dfsg-2, 4.8.7+dfsg-1), libwayland-server0:amd64 (1.6.0-2, 1.7.0-2), gvfs-common:amd64 (1.22.2-1, 1.24.1-2), gir1.2-gdkpixbuf-2.0:amd64 (2.31.4-1, 2.31.4-2), dconf-service:amd64 (0.22.0-1, 0.24.0-2), gparted:amd64 (0.19.0-2.1, 0.19.0-3), python2.7:amd64 (2.7.10~rc1-1, 2.7.10-1), gvfs-daemons:amd64 (1.22.2-1+b1, 1.24.1-2), libwayland-cursor0:amd64 (1.6.0-2, 1.7.0-2), gvfs:amd64 (1.22.2-1+b1, 1.24.1-2), ntfs-3g:amd64 (2014.2.15AR.3-2, 2014.2.15AR.3-3), qtcore4-l10n:amd64 (4.8.6+git155-g716fbae+dfsg-2, 4.8.7+dfsg-1), libqtdbus4:amd64 (4.8.6+git155-g716fbae+dfsg-2, 4.8.7+dfsg-1), libpython2.7:amd64 (2.7.10~rc1-1, 2.7.10-1), gvfs-backends:amd64 (1.22.2-1+b1, 1.24.1-2), libdconf1:amd64 (0.22.0-1, 0.24.0-2), libwayland-client0:amd64 (1.6.0-2, 1.7.0-2), dconf-gsettings-backend:amd64 (0.22.0-1, 0.24.0-2), libpcrecpp0:amd64 (8.35-3.3, 8.35-5), python2.7-minimal:amd64 (2.7.10~rc1-1, 2.7.10-1), libgdk-pixbuf2.0-0:amd64 (2.31.4-1, 2.31.4-2), gvfs-libs:amd64 (1.22.2-1+b1, 1.24.1-2), libdebian-installer4:amd64 (0.99, 0.100), libpcre3:amd64 (8.35-3.3, 8.35-5), libqtgui4:amd64 (4.8.6+git155-g716fbae+dfsg-2, 4.8.7+dfsg-1), libpython2.7-minimal:amd64 (2.7.10~rc1-1, 2.7.10-1)
End-Date: 2015-05-27 07:37:35
...
-
Tja, zu früh gefreut.
Nun geht es plötzlich nicht mehr und es ist wieder alles beim alten :(
...
-
Hi Holger,
ist es dann nicht besser, für das nfs-Server System ein Debian Jessie zu nehmen? Dass das aktuelle Ubuntu da auch Schwierigkeiten hat ... oh oh.
Ich habe auch schon mal überlegt, unser NAS (Druckerserver, Datenserver) mit siduction zu betreiben. Aber ich habe mich dann doch für Debian Stable entschieden, auf dem NAS werkelten schon Squeeze, dann Wheezy und nun läuft da Jessie. Mit nfs gab es bisher keine Schwierigkeiten. Gut, unter Wheezy zickte mal ssh -X herum.
Viele Grüße,
Holger
-
@holgerw: Pi x Daumen - alles, was Server ist, wür ich wenn möglich auf stable laufen lassen. Is einfach bequemer - und auf einem NAS Abhängigkeiten zu fixen oder das Ding alle Woche updaten zu sollen - nu ja, wer es mag - wäre auch nicht meins.
-
Um es richtig zu stellen. Mein Server (NAS) läuft natürlich mit stable. In diesem Fall handelt es sich um mein Rechenknecht im Keller der sein home von meinem Desktop einhängt und das ist SID <==> SID. Und 2 Vboxen spielen da auch mit rein die sich was vom Desktop einhängen was der zeit nur mit dem oben weiter genannten Würgaround funktioniert (nfsrestart im autostart).
...
-
Heute kam ja systemd 220 und ich hoffte auf Besserung. Enttäuschend das Ergebnis.
Mai 30 07:56:27 hsp1 systemd[1]: Detected architecture x86-64.
Mai 30 07:56:27 hsp1 systemd[1]: Set hostname to <hsp1>.
Mai 30 07:56:27 hsp1 systemd[1]: [/lib/systemd/system/sudo.service:7] Failed to unescape command line, ignoring: /usr/bin/find /var/lib/sudo -exec /usr/bin/touch -d @0 '{}' \073
Mai 30 07:56:27 hsp1 systemd[1]: sudo.service: Service lacks both ExecStart= and ExecStop= setting. Refusing.
Mai 30 07:56:27 hsp1 systemd[1]: ^[[1;39msudo.service: Cannot add dependency job, ignoring: Unit sudo.service failed to load: Invalid argument. See system logs and 'systemctl status sudo$
Mai 30 07:56:27 hsp1 systemd[1]: ^[[1;39mbasic.target: Found ordering cycle on basic.target/start
Mai 30 07:56:27 hsp1 systemd[1]: ^[[1;39mbasic.target: Found dependency on sockets.target/start
Mai 30 07:56:27 hsp1 systemd[1]: ^[[1;39mbasic.target: Found dependency on dbus.socket/start
Mai 30 07:56:27 hsp1 systemd[1]: ^[[1;39mbasic.target: Found dependency on sysinit.target/start
Mai 30 07:56:27 hsp1 systemd[1]: ^[[1;39mbasic.target: Found dependency on nfs-common.service/start
Mai 30 07:56:27 hsp1 systemd[1]: ^[[1;39mbasic.target: Found dependency on rpcbind.target/start
Mai 30 07:56:27 hsp1 systemd[1]: ^[[1;39mbasic.target: Found dependency on rpcbind.service/start
Mai 30 07:56:27 hsp1 systemd[1]: ^[[1;39mbasic.target: Found dependency on network-online.target/start
Mai 30 07:56:27 hsp1 systemd[1]: ^[[1;39mbasic.target: Found dependency on network.target/start
Mai 30 07:56:27 hsp1 systemd[1]: ^[[1;39mbasic.target: Found dependency on wpa_supplicant.service/start
Mai 30 07:56:27 hsp1 systemd[1]: ^[[1;39mbasic.target: Found dependency on basic.target/start
Mai 30 07:56:27 hsp1 systemd[1]: ^[[1;39mbasic.target: Breaking ordering cycle by deleting job sockets.target/start
Mai 30 07:56:27 hsp1 systemd[1]: sockets.target: Job sockets.target/start deleted to break ordering cycle starting with basic.target/start
Mai 30 07:56:27 hsp1 systemd[1]: ^[[1;39macpid.path: Found ordering cycle on acpid.path/start
Mai 30 07:56:27 hsp1 systemd[1]: ^[[1;39macpid.path: Found dependency on sysinit.target/start
Mai 30 07:56:27 hsp1 systemd[1]: ^[[1;39macpid.path: Found dependency on nfs-common.service/start
Mai 30 07:56:27 hsp1 systemd[1]: ^[[1;39macpid.path: Found dependency on rpcbind.target/start
Mai 30 07:56:27 hsp1 systemd[1]: ^[[1;39macpid.path: Found dependency on rpcbind.service/start
Mai 30 07:56:27 hsp1 systemd[1]: ^[[1;39macpid.path: Found dependency on network-online.target/start
Mai 30 07:56:27 hsp1 systemd[1]: ^[[1;39macpid.path: Found dependency on network.target/start
Mai 30 07:56:27 hsp1 systemd[1]: ^[[1;39macpid.path: Found dependency on wpa_supplicant.service/start
Mai 30 07:56:27 hsp1 systemd[1]: ^[[1;39macpid.path: Found dependency on basic.target/start
Mai 30 07:56:27 hsp1 systemd[1]: ^[[1;39macpid.path: Found dependency on paths.target/start
Mai 30 07:56:27 hsp1 systemd[1]: ^[[1;39macpid.path: Found dependency on acpid.path/start
Mai 30 07:56:27 hsp1 systemd[1]: ^[[1;39macpid.path: Breaking ordering cycle by deleting job nfs-common.service/start
Mai 30 07:56:27 hsp1 systemd[1]: nfs-common.service: Job nfs-common.service/start deleted to break ordering cycle starting with acpid.path/start
Mai 30 07:56:27 hsp1 systemd[1]: ^[[1;39macpid.path: Found ordering cycle on acpid.path/start
Mai 30 07:56:27 hsp1 systemd[1]: ^[[1;39macpid.path: Found dependency on sysinit.target/start
Mai 30 07:56:27 hsp1 systemd[1]: ^[[1;39macpid.path: Found dependency on rpcbind.service/start
Mai 30 07:56:27 hsp1 systemd[1]: ^[[1;39macpid.path: Found dependency on network-online.target/start
Mai 30 07:56:27 hsp1 systemd[1]: ^[[1;39macpid.path: Found dependency on network.target/start
Mai 30 07:56:27 hsp1 systemd[1]: ^[[1;39macpid.path: Found dependency on wpa_supplicant.service/start
Mai 30 07:56:27 hsp1 systemd[1]: ^[[1;39macpid.path: Found dependency on basic.target/start
Mai 30 07:56:27 hsp1 systemd[1]: ^[[1;39macpid.path: Found dependency on paths.target/start
Mai 30 07:56:27 hsp1 systemd[1]: ^[[1;39macpid.path: Found dependency on acpid.path/start
Mai 30 07:56:27 hsp1 systemd[1]: ^[[1;39macpid.path: Breaking ordering cycle by deleting job rpcbind.service/start
Mai 30 07:56:27 hsp1 systemd[1]: rpcbind.service: Job rpcbind.service/start deleted to break ordering cycle starting with acpid.path/start
...
-
Nach einer Diskussion mit agaida im IRC ist die Sache geklärt woran es lag. Es ist und war Systemd selber, was ich sehr traurig finde. Anscheinend ist Systemd nicht in der Lage veraltetes Gerümpel aus /etc/systemd/system wieder zu entfernen wenns nicht mehr gebraucht wird.
Agaida meinte nachdem er auch nach einem D-U von einem fetten Problem im Zusammenhang mit Systemd überrascht wurde, das man /etc/systemd/system mal ausmisten müsste weil da viel veraltetes rumfliegt. Und genau da ist der Hund begraben gewesen. Nach einer bereinigung von /etc/systemd/system vom alten Mist ist nun alles wieder jut. Was genau ich da nun gelöscht und geändert habe weiß ich ehrlich gesagt nicht mehr, es war aber einiges.
Ich bin eigentlich von Systemd sehr überzeugt gegenüber von sysvinit, aber das hier dämpft die Überzeugung doch um einiges.
...
-
Hi hsp,
zeig uns doch mal deinen IST-Zustand deines entrümpelten Verzeichnisses. Wäre u.U. für ähnliche gelagerte Probleme ganz hilfreich. Schau doch in die Bash-Historie dann weißt du was du gelöscht hast ;-)
-
Wenn es so einfach wär bluelupo. Ich hab das mit 'nem Dateimanager unter X gemacht. Nix mit .bash_history
So siehts nach der Bereinigung aus:
$ pwd
/etc/systemd/system
.:
create-cache-dirs.service
dbus-fi.epitest.hostap.WPASupplicant.service@
dbus-org.freedesktop.Avahi.service@
dbus-org.freedesktop.nm-dispatcher.service@
display-manager.service@
getty.target.wants/
getty\@tty2.service.d/
graphical.target.wants/
hibernate.target.wants/
hybrid-sleep.target.wants/
multi-user.target.wants/
paths.target.wants/
printer.target.wants/
sockets.target.wants/
sshd.service@
suspend.target.wants/
sysinit.target.wants/
syslog.service@
vncserver.service
./getty.target.wants:
getty\@tty1.service@
./getty@tty2.service.d:
autologin.conf
./graphical.target.wants:
accounts-daemon.service@
console-kit-daemon.service@
upower.service@
./hibernate.target.wants:
anacron-resume.service@
./hybrid-sleep.target.wants:
anacron-resume.service@
./multi-user.target.wants:
acpid.service@
anacron.service@
avahi-daemon.service@
binfmt-support.service@
create-cache-dirs.service@
cron.service@
cups-browsed.service@
dns-clean.service@
inetd.service@
lm-sensors.service@
NetworkManager.service@
pppd-dns.service@
remote-fs.target@
rsync.service@
rsyslog.service@
ssh.service@
./paths.target.wants:
acpid.path@
cups.path@
./printer.target.wants:
cups.service@
./sockets.target.wants:
acpid.socket@
avahi-daemon.socket@
cups.socket@
pcscd.socket@
./suspend.target.wants:
anacron-resume.service@
./sysinit.target.wants:
systemd-timesyncd.service@
...
-
Wer gucken möchte was im Vergleich zum Urzustand oder Default in seinem System geändert wurde kommt eventuell mit systemd-delta weiter. Laut Archwiki:
You can use systemd-delta to see which unit files have been overridden or extended and what exactly has been changed.
Siehe man systemd-delta (http://www.freedesktop.org/software/systemd/man/systemd-delta.html)
-
Nach der Vorlage von hsp machs ich mal kurz und schmerzhaft - eigentlich müsste /etc/systemd leer sein bis auf ein paar symlinks - alles andere wird früher oder später massive Probleme bringen. Das hat auch einen Hintergrund:
Alles in /etc/systemd unterliegt der Verantwortung und Wartung durch den User. Nicht mehr und nicht weniger. Das wird durch debian nie (wieder) angepackt - und noch schlimmer, es hat Priorität gegenüber den orginalen Daten im systemd-Installationsverzeichnis. Das bedeutet - die können fixen und verfeinern, soviel sie wollen, solange das neue Zeug durch /etc/systemd ausgeblendet (oder besser verdeckt) wird kommen diese Änderungen nicht an.
Ein 2. Punkt können eventuell unsaubere Behandlungen von /etc/init.d und /etc/rc#.d sein - steht da was drin, wird ein systemd-Generator anspringen und versuchen, daraus ordentliche Services zu erstellen. ist halt historisch gewachsen und war/ist legitim - inwieweit solche generierte Sachen eigene Service-Files ausblenden - keine Ahnung. Fakt ist nur, dass ich da gestern massiv reingelaufen bin, eigentlich schon die Tage vorher, da war das aber noch nicht so störend.
Edit: Die Konfigurationsdateien sollte man im Verzeichnis /etc/systemd stehen lassen, die kommen aus den Paketen - Dank für die Berichtigung an hsp.