Welcome, Guest. Please login or register.
Did you miss your activation email?

Author Topic:  Job rpcbind.service/start  (Read 9116 times)

Offline hsp

  • User
  • Posts: 623
Re: Job rpcbind.service/start
« Reply #15 on: 2015/05/23, 08:09:25 »
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...

Offline bluelupo

  • User
  • Posts: 2.068
    • BluelupoMe
Re: Job rpcbind.service/start
« Reply #16 on: 2015/05/23, 10:31:20 »
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
« Last Edit: 2015/05/23, 10:50:28 by bluelupo »

Offline ralul

  • User
  • Posts: 1.814
Re: Job rpcbind.service/start
« Reply #17 on: 2015/05/24, 17:50:05 »
@Bluelupo, from your ubuntu bug, if it is true
Quote
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
experiencing siduction runs better than my gentoo makes me know I know nothing

Offline hsp

  • User
  • Posts: 623
Re: Job rpcbind.service/start
« Reply #18 on: 2015/05/27, 08:19:37 »
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*

Code: [Select]
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

...

Offline hsp

  • User
  • Posts: 623
Re: Job rpcbind.service/start
« Reply #19 on: 2015/05/27, 12:49:28 »
Tja, zu früh gefreut.
Nun geht es plötzlich nicht mehr und es ist wieder alles beim alten :(

...

holgerw

  • Guest
Re: Job rpcbind.service/start
« Reply #20 on: 2015/05/27, 12:57:52 »
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

Offline melmarker

  • User
  • Posts: 2.799
    • g-com.eu
Re: Job rpcbind.service/start
« Reply #21 on: 2015/05/27, 17:15:04 »
@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.
Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. (Benjamin Franklin, November 11, 1755)
Never attribute to malice that which can be adequately explained by stupidity. (Hanlons razor)

Offline hsp

  • User
  • Posts: 623
Re: Job rpcbind.service/start
« Reply #22 on: 2015/05/27, 17:38:25 »
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).

...

Offline hsp

  • User
  • Posts: 623
Re: Job rpcbind.service/start
« Reply #23 on: 2015/05/30, 08:29:30 »
Heute kam ja systemd 220 und ich hoffte auf Besserung. Enttäuschend das Ergebnis.
Code: [Select]
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

...

Offline hsp

  • User
  • Posts: 623
Re: Job rpcbind.service/start
« Reply #24 on: 2015/05/30, 17:48:48 »
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.

...

Offline bluelupo

  • User
  • Posts: 2.068
    • BluelupoMe
Re: Job rpcbind.service/start
« Reply #25 on: 2015/05/30, 19:17:22 »
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 ;-)

Offline hsp

  • User
  • Posts: 623
Re: Job rpcbind.service/start
« Reply #26 on: 2015/05/30, 19:39:13 »
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:
Code: [Select]
$ 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@

...

Offline der_bud

  • User
  • Posts: 1.072
  • member
Re: Job rpcbind.service/start
« Reply #27 on: 2015/05/30, 21:45:29 »
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:
Quote
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
Du lachst? Wieso lachst du? Das ist doch oft so, Leute lachen erst und dann sind sie tot.

Offline melmarker

  • User
  • Posts: 2.799
    • g-com.eu
Re: Job rpcbind.service/start
« Reply #28 on: 2015/05/30, 22:24:42 »
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.
« Last Edit: 2015/05/30, 23:05:39 by melmarker »
Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. (Benjamin Franklin, November 11, 1755)
Never attribute to malice that which can be adequately explained by stupidity. (Hanlons razor)