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

Status
Für weitere Antworten geschlossen.

Sauerland

Member
Antwort zu:
openSUSE 13.1 wird zum "Evergreen"

Da ich dort nicht antworten kann.
Code:
linux-w63r:~ # systemctl enable sshd.service 

linux-w63r:~ # systemctl start sshd.service       

linux-w63r:~ # systemctl disable sshd.service      

linux-w63r:~ # systemctl status sshd.service        
sshd.service - OpenSSH Daemon
   Loaded: loaded (/usr/lib/systemd/system/sshd.service; disabled)
   Active: active (running) since Sa 2016-02-06 08:47:24 CET; 52s ago
 Main PID: 1261 (sshd)
   CGroup: /system.slice/sshd.service
           └─1261 /usr/sbin/sshd -D

Feb 06 08:47:23 linux-w63r sshd-gen-keys-start[1258]: Checking for missing se...
Feb 06 08:47:24 linux-w63r sshd-gen-keys-start[1258]: ssh-keygen: generating ...
Feb 06 08:47:24 linux-w63r sshd[1261]: Server listening on 0.0.0.0 port 22.
Feb 06 08:47:24 linux-w63r sshd[1261]: Server listening on :: port 22.
Hint: Some lines were ellipsized, use -l to show in full.

linux-w63r:~ # strings systemctl | grep -E 'ln \-s|rm\ '
strings: 'systemctl': No such file

linux-w63r:~ # which systemctl
/usr/bin/systemctl

linux-w63r:~ # strings /usr/bin/systemctl | grep -E 'ln \-s|rm\ '
rm '%s'
ln -s '%s' '%s'
Code:
linux-w63r:~ # zypper se -si systemd
Daten des Repositories laden ...
Installierte Pakete lesen ...

S | Name                              | Typ   | Version      | Arch   | Repository       
--+-----------------------------------+-------+--------------+--------+------------------
i | systemd                           | Paket | 210-25.5.4   | x86_64 | openSUSE-13.2-Oss
i | systemd                           | Paket | 210-25.5.4   | x86_64 | openSUSE-13.2-0  
i | systemd-32bit                     | Paket | 210-25.5.4   | x86_64 | openSUSE-13.2-Oss
i | systemd-32bit                     | Paket | 210-25.5.4   | x86_64 | openSUSE-13.2-0  
i | systemd-bash-completion           | Paket | 210-25.5.4   | noarch | openSUSE-13.2-Oss
i | systemd-bash-completion           | Paket | 210-25.5.4   | noarch | openSUSE-13.2-0  
i | systemd-logger                    | Paket | 210-25.5.4   | x86_64 | openSUSE-13.2-Oss
i | systemd-logger                    | Paket | 210-25.5.4   | x86_64 | openSUSE-13.2-0  
i | systemd-presets-branding-openSUSE | Paket | 0.3.0-12.1.2 | noarch | openSUSE-13.2-Oss
i | systemd-presets-branding-openSUSE | Paket | 0.3.0-12.1.2 | noarch | openSUSE-13.2-0  
i | systemd-sysvinit                  | Paket | 210-25.5.4   | x86_64 | openSUSE-13.2-Oss
i | systemd-sysvinit                  | Paket | 210-25.5.4   | x86_64 | openSUSE-13.2-0  
i | util-linux-systemd                | Paket | 2.25.1-2.4   | x86_64 | openSUSE-13.2-Oss
i | util-linux-systemd                | Paket | 2.25.1-2.4   | x86_64 | openSUSE-13.2-0  
linux-w63r:~ #
Frische openSUSE 13.2 Installation ohne Updates in VirtualBox.
 

Rain_Maker

Administrator
Teammitglied
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.

Code:
linux-w63r:~ # systemctl enable sshd.service 

linux-w63r:~ # systemctl start sshd.service       

linux-w63r:~ # systemctl disable sshd.service
OK, also auch hier herrscht "Stille", wo eigentlich keine sein sollte, weil auch hier

Code:
linux-w63r:~ # strings /usr/bin/systemctl | grep -E 'ln \-s|rm\ '
rm '%s'
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
 

Rain_Maker

Administrator
Teammitglied
Würgaround (sic!)

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

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

Code:
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 .........

Code:
systemctl disable sshd

rm '/etc/systemd/system/multi-user.target.wants/sshd.service'

systemctl enable sshd 

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
 
Status
Für weitere Antworten geschlossen.
Oben