Fix für SysVinit und Systemd

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • Fix für SysVinit und Systemd

      Hallo Zusammen,

      für diverse Pakete gibt es einen Fix für SysVinit auf Debian 8. Bislang waren die Pakete immer so gebaut, dass Systemd bei Debian 8 Systemen Voraussetzung war. Nun wird das Init-Skript installiert, wenn kein Systemd (/lib/systemd) gefunden wird.

      Dies betrifft die Pakete

      * bloonix-server
      * bloonix-webgui-core
      * bloonix-satellite
      * bloonix-agent
      * bloonix-wtrm

      Viele Grüße
      Jonny
    • Seitdem fix bekomme ich auf Wheezy folgende Probleme: Unpacking replacement bloonix-satellite ...
      Processing triggers for man-db ...
      Setting up bloonix-core (0.35-1) ...
      Setting up bloonix-agent (0.68-1) ...
      /var/lib/dpkg/info/bloonix-agent.postinst: line 5: systemctl: command not found
      Configure bloonix with systemd
      /var/lib/dpkg/info/bloonix-agent.postinst: line 13: systemctl: command not found
      Starting (condrestart) bloonix-agent..
      /var/lib/dpkg/info/bloonix-agent.postinst: line 25: systemctl: command not found
      Setting up bloonix-plugins-basic (0.51-1) ...
      Setting up bloonix-plugins-linux (0.51-1) ...
      Setting up bloonix-plugins-mysql (0.14-1) ...
      Setting up bloonix-plugins-sensors (0.10-1) ...
      Setting up bloonix-satellite (0.8-1) ...
      /var/lib/dpkg/info/bloonix-satellite.postinst: line 5: systemctl: command not found
      Configure bloonix with systemd
      /var/lib/dpkg/info/bloonix-satellite.postinst: line 13: systemctl: command not found
      Starting (condrestart) bloonix-satellite..
      /var/lib/dpkg/info/bloonix-satellite.postinst: line 25: systemctl: command not found
    • Danke,
      bekomme jetzt noch andere Fehlermeldungen auf Jessie:

      bloonix-agent (0.69-1) wird eingerichtet ...
      Configure bloonix with systemd
      Failed to execute operation: File exists
      Starting (condrestart) bloonix-agent..
      bloonix-server (0.51-1) wird eingerichtet ...
      Configure bloonix with systemd
      Failed to execute operation: File exists
      Failed to execute operation: File exists

      Starting (condrestart) bloonix-server..
      Starting (condrestart) bloonix-srvchk..
      bloonix-webgui-core (0.18-1) wird eingerichtet ...
      Configure bloonix with systemd
      Failed to execute operation: File exists
      bloonix-webgui (0.89-1) wird eingerichtet ...

      Hast du den Pfad vom Systemd Startup File geändert?

      bloonix-init-host spuckt auch einen Fehler aus -- Bei ganz frisch installierten Hosts nur (bei den alten ist das Script wohl noch vorhanden)

      Can't exec "/etc/init.d/bloonix-agent": Datei oder Verzeichnis nicht gefunden at /usr/bin/bloonix-init-host line 101.
    • Die Meldungen "Failed to execute operation: File exists" kannst du ignorieren.

      "Configure bloonix with systemd" - bekommst du die Meldung auf einem Wheezy?

      Das Postinstall-Skript der Pakete macht folgendes:

      Existiert das Verzeichnis /usr/lib/systemd, dann wird ein File für systemd angelegt
      Existiert das Verzeichnis /usr/lib/systemd nicht, dann wird das Init-Skript angelegt.
    • Auf einer ganz frischen Debian Wheezy Kiste...

      Source Code

      1. root@debian-wheezy:~# apt-get install bloonix-agent bloonix-server bloonix-wtrm bloonix-satellite
      2. Reading package lists... Done
      3. Building dependency tree
      4. Reading state information... Done
      5. The following extra packages will be installed:
      6. ...
      7. Suggested packages:
      8. ...
      9. The following NEW packages will be installed:
      10. ...
      11. 0 upgraded, 100 newly installed, 0 to remove and 48 not upgraded.
      12. Need to get 25.8 MB of archives.
      13. After this operation, 93.1 MB of additional disk space will be used.
      14. Do you want to continue [Y/n]?
      15. ...
      16. ...
      17. ...
      18. root@debian-wheezy:~# ls -l /etc/init.d/bloonix-*
      19. -rwxr-xr-x 1 root root 739 Mar 29 10:41 /etc/init.d/bloonix-agent
      20. -rwxr-xr-x 1 root root 605 Mar 29 10:41 /etc/init.d/bloonix-satellite
      21. -rwxr-xr-x 1 root root 590 Mar 30 23:08 /etc/init.d/bloonix-server
      22. -rwxr-xr-x 1 root root 585 Mar 30 23:08 /etc/init.d/bloonix-srvchk
      23. -rwxr-xr-x 1 root root 584 Mar 29 10:43 /etc/init.d/bloonix-wtrm
      Display All
    • Anfangs war es Wheezy.
      Jessie meinte ich in meinem 2ten Post.

      nosxxx wrote:


      bekomme jetzt noch andere Fehlermeldungen auf Jessie:


      bloonix-init-host spuckt auch einen Fehler aus -- Bei ganz frisch installierten Hosts nur (bei den alten ist das Script wohl noch vorhanden)
      Can't exec "/etc/init.d/bloonix-agent": Datei oder Verzeichnis nicht gefunden at /usr/bin/bloonix-init-host line 101.
    • Heisenberg wrote:

      Woher kommt das denn und kann man das abschalten? Mein apt-dater interpretiert das bei jedem Update als Fehler und ich muss die Meldung per Hand ignorieren. Nichts tragisches, nervt nur ein wenig. ;)


      Das kommt von einem "systemctl daemon-reload". Du kannst das wirklich ignorieren. Es gab eine Paketreihe, da wurden die Postinstall-Skripte mit "set -e" ausgeführt, sprich, die sind abgebrochen und haben einen Fehler geschmissen. In den aktuellen Paketen wird da einfach nur die Warnung ausgegeben.
    • Der apt-dater kontrolliert einfach nur in dem Output, den der Server gibt, ob es ein "warning", ein "error" oder ein "failed" gibt. Falls ja, muss ich mir die Meldung anschauen und kann sie dann entweder ignorieren oder per Hand eingreifen. Aktuell habe ich das über die Option "ErrPattern=(error|fail)" im apt-dater abgeschaltet, aber manchmal sind warnings ja doch hilfreich zu sehen.

      Das apt-get upgrade läuft, außer dem Warning, problemlos durch - daher wird auch nicht gehandelt.
      I probably won't go down in history, but I will go down on your sister.
      - Hank Moody
    • @Jonny: er meint den "apt-dater" (ibh.de/apt-dater/)

      schuld an den Meldungen dürften Einträge wie diese im postinst sein:

      Source Code

      1. systemctl preset bloonix-server.service


      Dei Frage wäre hier nur noch: Warum wird nicht einfach "systemctl enable" genutzt? Es gibt ohnehin keine preset-rule für bloonix-*-units (zumindest habe ich keine gefunden ;) )
      Sofern ich es richtig verstanden habe, meckert "systemctl preset" rum, weil die entsprechende bloonix-unit schon aktiv (enabled) ist .. und er das per default auch beim preset ohne preset-file machen würde.
      Sozusagen ein erwarteter Fehler.

      Wer mich nicht verstanden hat kanns auch hier nachlesen:
      Preset files may be written for specific distributions, for specific spins or for specific sites, in order to enforce different policies as needed. Preset policies are stored in .preset files in /usr/lib/systemd/system-preset/. If no policy exists the default implied policy of "enable everything" is enforced, i.e. in Debian style.

      The policy encoded in preset files is applied to a unit by invoking "systemctl preset ". It is recommended to use this command in all package post installation scriptlets. "systemctl preset " is identical to "systemctl enable " resp. "systemctl disable " depending on the policy.


      Das Problem ist also, dass "systemctl preset" den Fehler wirft, wenn die Unit schon aktiv ist und sie anlegt, wenn sie nicht aktiviert ist (bei Neuinstallation sollte der Fehler also nicht auftauchen).

      Lösungsvorschlag 1: 'enable' anstelle von 'preset' nutzen (wobei das aber ohnehin nicht notwendig ist, da bei debian jede unit, die nicht explizit deaktiviert wurde zb per preset, aktiv ist - s.o.)
      Lösungsvorschlag 2: für bloonix-units ein preset anlegen .. wobei ich jetzt keinen trivialen weg gefunden habe, damit systemd meine selbstgeschriebenen presets auch 'frist'

      The post was edited 1 time, last by LicoMonch ().

    • Ok. Rolle rückwärts und Salto mortale bitte.
      Das obige ist zwar an sich nicht falsch, aber die Ursache ist doch eine andere (mich hat der Fehler beim 'preset' nicht in Ruhe gelasen ;)

      Ich habe mich also etwas umgeschaut und folgende dead links gefunden:

      Source Code

      1. root@somehost:/etc/systemd/system/multi-user.target.wants# ll
      2. ..
      3. lrwxrwxrwx 1 root root 46 Jun 25 2015 bloonix-srvchk.service -> /usr/lib/systemd/system/bloonix-srvchk.service
      4. lrwxrwxrwx 1 root root 46 Jun 25 2015 bloonix-webgui.service -> /usr/lib/systemd/system/bloonix-webgui.service
      5. ..
      6. root@somehost:/etc/systemd/system/multi-user.target.wants# ll /usr/lib/systemd/system/bloonix-srvchk.service
      7. ls: cannot access /usr/lib/systemd/system/bloonix-srvchk.service: No such file or directory
      8. root@somehost:/etc/systemd/system/multi-user.target.wants# systemctl preset bloonix-srvchk.service
      9. Failed to execute operation: File exists
      Display All


      ein kurzes 'systemctl disable bloonix-srvchk.service' und danach 'systemctl enable bloonix-srvchk.service' korrigieren das ganze

      Source Code

      1. root@somehost:/etc/systemd/system/multi-user.target.wants# systemctl disable bloonix-srvchk.service && systemctl enable bloonix-srvchk.service
      2. Removed symlink /etc/systemd/system/multi-user.target.wants/bloonix-srvchk.service.
      3. Created symlink from /etc/systemd/system/multi-user.target.wants/bloonix-srvchk.service to /lib/systemd/system/bloonix-srvchk.service.
      4. root@somehost:/etc/systemd/system/multi-user.target.wants# ll
      5. ..
      6. lrwxrwxrwx 1 root root 42 Apr 7 02:41 bloonix-srvchk.service -> /lib/systemd/system/bloonix-srvchk.service
      7. lrwxrwxrwx 1 root root 46 Jun 25 2015 bloonix-webgui.service -> /usr/lib/systemd/system/bloonix-webgui.service
      8. ..
      9. root@somehost:/etc/systemd/system/multi-user.target.wants# ll /lib/systemd/system/bloonix-srvchk.service
      10. -rwxr-xr-x 1 root root 536 Apr 6 18:01 /lib/systemd/system/bloonix-srvchk.service
      11. root@somehost:/etc/systemd/system/multi-user.target.wants# systemctl preset bloonix-srvchk.service
      12. root@somehost:/etc/systemd/system/multi-user.target.wants# echo $?
      13. 0
      Display All


      Folgendes:

      Source Code

      1. # systemctl preset bloonix-srvchk.service
      2. Failed to execute operation: File exists

      Bedeutet also: Ich kann den Dienst nicht auf enabled setzen, weil es schon einen gleichlautenden gibt und ich muss es mit einem Fehler quittieren, weil der Dienst auf eine andere Unit zeigt, als die, die Du gerade aktivieren möchtest. (Ich denke, dass es hierbei egal ist, dass die Ziel-Unit gar nicht existiert, sondern nur geprüft wird, ob die Link-Destination identisch ist (=> kein Fehler durch preset) oder nicht (=> Fehler durch preset)).

      @Heisenberg: Das heißt auch das die Packages in Ordnung sind und Du und ich leiider auch, immer bei solchen Fehlern von dpkg schauen müssen, ob zum Beispiel obiger Fall vorliegt.

      @Jonny: Kann es sein, dass Du irgendwann mal die Ziel-Verzeichnisse für die Unit-Files angepasst hast?
    • Hier nochmal als Beweis, dass das Problem mit dem obigen Fix verschwindet:

      Source Code

      1. # aptitude reinstall bloonix-server
      2. The following packages will be REINSTALLED:
      3. bloonix-server
      4. 0 packages upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 0 not upgraded.
      5. Need to get 0 B/45.2 kB of archives. After unpacking 0 B will be used.
      6. (Reading database ... 33690 files and directories currently installed.)
      7. Preparing to unpack .../bloonix-server_0.53-1_all.deb ...
      8. Unpacking bloonix-server (0.53-1) over (0.53-1) ...
      9. Processing triggers for man-db (2.7.0.2-5) ...
      10. Setting up bloonix-server (0.53-1) ...
      11. Configure bloonix with systemd
      12. Starting (condrestart) bloonix-server..
      13. Starting (condrestart) bloonix-srvchk..
      14. Scanning processes...
      15. Scanning candidates...
      16. Scanning kernel images...
      17. Failed to retrieve available kernel versions.
      18. Restarting services using systemd...
      Display All
    • Jonny wrote:

      Bei den nächsten Paketen fix ich das im Postinstall mit dem alten Unit File.


      Danke.

      Machst Du eigentlich auch bei den RPMs ein 'systemctl preset bloonix-*' im postinst? Wenn ja, dann wird das meines Wissens nach zumindest unter Fedora zu Problemen führen, da dort die letzte Preset-Regel 'disable *' ist. Und da Bloonix kein preset mitbringt, wird beim Postinst der Service deaktiviert werden - was bei der Installation ja sogar gut ist (schliesslich ist der Service noch uneingerichtet und ungetestet), aber beim Update sicher nicht gewünscht ist.

      Wie das bei anderen RPM-Distibution wie CentOS aussieht, kann ich leider im Moment nicht prüfen.