(Erledigt) Antwort zu "Anderes Verhalten von "systemctl enable/disable" seit Update - Sachdienliche Hinweise erbeten ..."

    (Erledigt) Antwort zu "Anderes Verhalten von "systemctl enable/disable" seit Update - Sachdienliche Hinweise erbeten ..."

    Antwort zu:
    openSUSE 13.1 wird zum "Evergreen"

    Da ich dort nicht antworten kann.

    Quellcode

    1. linux-w63r:~ # systemctl enable sshd.service
    3. linux-w63r:~ # systemctl start sshd.service
    5. linux-w63r:~ # systemctl disable sshd.service
    7. linux-w63r:~ # systemctl status sshd.service
    8. sshd.service - OpenSSH Daemon
    9. Loaded: loaded (/usr/lib/systemd/system/sshd.service; disabled)
    10. Active: active (running) since Sa 2016-02-06 08:47:24 CET; 52s ago
    11. Main PID: 1261 (sshd)
    12. CGroup: /system.slice/sshd.service
    13. └─1261 /usr/sbin/sshd -D
    15. Feb 06 08:47:23 linux-w63r sshd-gen-keys-start[1258]: Checking for missing se...
    16. Feb 06 08:47:24 linux-w63r sshd-gen-keys-start[1258]: ssh-keygen: generating ...
    17. Feb 06 08:47:24 linux-w63r sshd[1261]: Server listening on 0.0.0.0 port 22.
    18. Feb 06 08:47:24 linux-w63r sshd[1261]: Server listening on :: port 22.
    19. Hint: Some lines were ellipsized, use -l to show in full.
    21. linux-w63r:~ # strings systemctl | grep -E 'ln \-s|rm\ '
    22. strings: 'systemctl': No such file
    24. linux-w63r:~ # which systemctl
    25. /usr/bin/systemctl
    27. linux-w63r:~ # strings /usr/bin/systemctl | grep -E 'ln \-s|rm\ '
    28. rm '%s'
    29. ln -s '%s' '%s'

    Brainfuck-Quellcode

    1. linux-w63r:~ # zypper se -si systemd
    2. Daten des Repositories laden ...
    3. Installierte Pakete lesen ...
    5. S | Name | Typ | Version | Arch | Repository
    6. --+-----------------------------------+-------+--------------+--------+------------------
    7. i | systemd | Paket | 210-25.5.4 | x86_64 | openSUSE-13.2-Oss
    8. i | systemd | Paket | 210-25.5.4 | x86_64 | openSUSE-13.2-0
    9. i | systemd-32bit | Paket | 210-25.5.4 | x86_64 | openSUSE-13.2-Oss
    10. i | systemd-32bit | Paket | 210-25.5.4 | x86_64 | openSUSE-13.2-0
    11. i | systemd-bash-completion | Paket | 210-25.5.4 | noarch | openSUSE-13.2-Oss
    12. i | systemd-bash-completion | Paket | 210-25.5.4 | noarch | openSUSE-13.2-0
    13. i | systemd-logger | Paket | 210-25.5.4 | x86_64 | openSUSE-13.2-Oss
    14. i | systemd-logger | Paket | 210-25.5.4 | x86_64 | openSUSE-13.2-0
    15. i | systemd-presets-branding-openSUSE | Paket | 0.3.0-12.1.2 | noarch | openSUSE-13.2-Oss
    16. i | systemd-presets-branding-openSUSE | Paket | 0.3.0-12.1.2 | noarch | openSUSE-13.2-0
    17. i | systemd-sysvinit | Paket | 210-25.5.4 | x86_64 | openSUSE-13.2-Oss
    18. i | systemd-sysvinit | Paket | 210-25.5.4 | x86_64 | openSUSE-13.2-0
    19. i | util-linux-systemd | Paket | 2.25.1-2.4 | x86_64 | openSUSE-13.2-Oss
    20. i | util-linux-systemd | Paket | 2.25.1-2.4 | x86_64 | openSUSE-13.2-0
    21. linux-w63r:~ #

    Frische openSUSE 13.2 Installation ohne Updates in VirtualBox.

    Sauerland schrieb:

    Antwort zu:
    openSUSE 13.1 wird zum "Evergreen"

    Da ich dort nicht antworten kann.


    Ups, stimmt ja, das Unterforum ist für normale User gesperrt, das hatte ich nicht bedacht, ich setze wohl am besten dort noch schnell einen Link für Querleser.

    Quellcode

    1. linux-w63r:~ # systemctl enable sshd.service
    3. linux-w63r:~ # systemctl start sshd.service
    5. linux-w63r:~ # systemctl disable sshd.service


    OK, also auch hier herrscht "Stille", wo eigentlich keine sein sollte, weil auch hier

    Quellcode

    1. linux-w63r:~ # strings /usr/bin/systemctl | grep -E 'ln \-s|rm\ '
    2. rm '%s'
    3. ln -s '%s' '%s'


    die Funktionalität im Binary vorhanden ist.

    Sauerland schrieb:


    Frische openSUSE 13.2 Installation ohne Updates in VirtualBox.


    Alles klar, danke für die Mitarbeit.

    Ich habe auch gestern noch einen Hinweis per Email von einem Bekannten bekommen, der das Ganze unter openSUSE 42.1 mit exakt dem selben Ergebnis getestet hat.

    Bug oder Feature? Ich bin immer mehr der Meinung, es ist Ersteres.

    Greetz,

    RM
    "Programming today is a race between software engineers striving to build better & bigger idiot-proof programs and the Universe trying to produce bigger & better idiots. So far, the Universe is winning." (Rick Cook)

    Dies ist ein _öffentliches_ Supportforum, keinerlei Support per PN, EMail oder Instant Messenger.

    openSUSE Leap 42.3 - Kernel 4.20.x - fluxbox 1.3.7

    Bitmessage: BM-2D8h8QZmvHfgbixWeiG1NDZHG1iXAhBz8K

    Würgaround (sic!)

    Nach einiger Recherche und etwas Herumprobiererei wurde ich auf folgenden Workaround gestossen.

    Man schaut nach, ob der Bootparameter "quiet" gesetzt wurde

    Quellcode

    1. grep quiet /proc/cmdline


    falls ja, entfernt man diesen aus der Konfiguration (menu.lst, lilo.conf, grub.cfg, je nach Bootloader), .... Neustart und siehe da .........

    Quellcode

    1. systemctl disable sshd
    3. rm '/etc/systemd/system/multi-user.target.wants/sshd.service'
    5. systemctl enable sshd
    7. ln -s '/usr/lib/systemd/system/sshd.service' '/etc/systemd/system/multi-user.target.wants/sshd.service'


    Warum allerdings ein Parameter für das Verhalten des OS beim Booten (sic!) einen solchen Einfluss auf die Ausgabe eines Userspace-Programmes (sic!) zur Laufzeit (sic!) hat, ähm ja .... *schulterzuck* ..... (von der Tatsache mal ganz abgesehen, dass es bei system-219 in CentOS7 wieder so funktioniert, wie zuvor ........ *koppkratz*)

    Greetz,

    RM
    "Programming today is a race between software engineers striving to build better & bigger idiot-proof programs and the Universe trying to produce bigger & better idiots. So far, the Universe is winning." (Rick Cook)

    Dies ist ein _öffentliches_ Supportforum, keinerlei Support per PN, EMail oder Instant Messenger.

    openSUSE Leap 42.3 - Kernel 4.20.x - fluxbox 1.3.7

    Bitmessage: BM-2D8h8QZmvHfgbixWeiG1NDZHG1iXAhBz8K