debianforum.de

Auf unseren 'frischen' Buster-Setups sieht das nach dem usr-merge hier auf allen System so aus:

Jetzt noch ein weiterer Aspekt - wer darf wann überhaupt /sbin/shutdown aufrufen?

Die Diskussion hier dreht sich vorwiegend um weitere Binaries, die alle eigentlich überflüssig sind. Ich selbst nutze im Terminal entweder oder Statt "now" kann man auch (Verzögerungs)-Zeiten angeben. In diesem Falle werden dann alle auf dem System angemeldeten User benachrichtigt, damit sie ihre Arbeit beenden/sichern können.

Was ich darüberhinaus beobachtet habe (allerdings noch unter Stretch):
Wenn meine Frau an ihrem Laptop sitzt (Debian mit XFCE) kann sie jederzeit das System herunterfahren
- aber das geht nicht (zumindest mit dem Desktop-Applet, wenn ich von remote als "root" angemeldet bin, z.B. um ein Problem zu beheben. Umgekehrt kann ich als root per ssh jederzeit das System herunterfahren, auch wenn sie noch auf dem Desktop eingelogt ist.

ingo2 hat geschrieben:

25.05.2020 23:11:52

Die Diskussion hier dreht sich vorwiegend um weitere Binaries, die alle eigentlich überflüssig sind.

reboot ist kein weiteres Binary sondern ein symbolic Link auf /bin/systemctl. Das gleiche gillt für poweroff, halt, runlevel, shutdown und telinit. Also nur ein einziges Binary, das man unter verschiedenen Namen aufrufen kann und dann unterschiedliche Aktionen bewirkt.

das sehe ich hier auch, sind alles Symlinks auf systemctl.

Aber wieso geben dann die man-pages unterschiedliche Optionen für die "alten" Befehle? z.B. kennt laut man-page die Optionen "-r" und "-t" und auch den Zeitparameter von nicht?
Welche man-page gilt denn nun?

ingo2 hat geschrieben:

26.05.2020 12:15:18

das sehe ich hier auch, sind alles Symlinks auf systemctl.

Aber wieso geben dann die man-pages unterschiedliche Optionen für die "alten" Befehle?

Code: Alles auswählen

man poweroff

z.B. kennt laut man-page die Optionen "-r" und "-t" und auch den Zeitparameter von

Code: Alles auswählen

man shutdown

nicht?
Welche man-page gilt denn nun?

Beide sind korrekt. systemctl(8) kann je nach Aufrufname (argv[0]) unterschiedliche Legacy-Interfaces unterstuetzen. Das Legacy-Interface fuer `shutdown' ist kompatibel zum alten `shutdown' und das fuer `poweroff' ist kompatibel zum alten `poweroff'.

Bloss weil es Symlinks auf das gleiche Binary sind, heisst das technisch nicht, dass dieses sich nicht abhaengig vom Aufrufnahme unterschiedlich verhalten kann.

Danke für die Aufklärung @Meillo - diese Möglichkeit bei Symlinks war mir bisher nicht bewußt.
Damit ist ja dann "systemctl" die reinste eierlegende Wollmilchsau - aber ohne entsprechende Dokumentation.
Gilt wohl dann auch für Hardlinks?

Ingo

ingo2 hat geschrieben:

26.05.2020 13:06:36

Gilt wohl dann auch für Hardlinks?

Ja.

Hardlinks sind (multiple) reale Namen der Datei.

Meillo hat geschrieben:

13.05.2020 14:52:40

DaCoda hat geschrieben:

13.05.2020 14:05:40

MSfree hat geschrieben:

11.05.2020 13:46:12

Für Super steht es sicher nicht. Früher ware dort mal statisch gelinkte Porgramme, also solche, die keine "DLLs" brauchen. Heute sind das eher Systemprogramme.

Also unter http://www.linfo.org/sbin.html steht, dass unter /sbin nur Programme sind, welche nur durch den root user ausgefüghrt werden können.
Dadurch zeichnet sich dieses Verzeichnis aus.

Wenn du genau liest, dann steht dort, dass die Programme *normalerweise* nur von root ausgefuehrt werden. Die Programme werden normalen Usern standardmaessig nicht angeboten ($PATH), aber jeder User kann $PATH selber veraendern und auch unabhaengig von $PATH mit einem absoluten Pfad beliebige Programme aufrufen (fuer die er Executable-Rechte hat). [...]

[...]

Und darueber hinaus muss man den historischen Kontext sehen. Wie etwas entstanden ist und wie es heute verwendet wird kann unterschiedlich sein. Z.B. bei /sbin: entstanden als ``static binaries'', heute genutzt als ``system binaries''. [...]

Da dieses Thema gerade auf der TUHS-Mailingliste aufgekommen ist und dort Personen geantwortet haben, die es wirklich wissen, verlinke ich mal: https://minnie.tuhs.org/pipermail/tuhs/ ... 21752.html (Die Antworten darauf sind relevant.)

Meine Aussage war also falsch. Entstanden ist /sbin/ als um System-Binaries separat zu halten, damit man die anderen Binaries auf separate Dateisysteme legen konnte, die man erst spaeter im Boot-Prozess mountet. Zu der Zeit (4.3 BSD Reno) gab es noch gar kein dynamisches Linking.