Arch Linux

Warum systemd als /usr/lib/systemd/systemd?

Ovion

Einen guten Abend,

wenn ich mein System via systemd starten möchte, muss ich ja das systemd-executable als init-Kernelparameter übergeben. Dies ist aber doch ein executable und keine Bibliothek, denn Bibliotheken werden von Programmen benutzt. Was also macht das systemd-executable (wie auch ein haufen anderer systemd-Programme, wie mir scheint) in /usr/*lib*/systemd/? Gehört es nicht eigentlich eher nach /usr/bin oder /usr/sbin (solange es letzteres noch gibt)? Oder habe ich eine falsche Vorstellung im Kopf? systemd ist doch keine Bibliothek, sondern mein Initsystemeinsprung*programm*?

Macht auch nicht nur Arch so, bei Gentoo hab ich's gelesen und bei freedesktop.org wird ebenfalls dieser Pfad verwendet, bei Fedora und Suse hab ich nichts zum systemd-Pfad gefunden, vermutlich wegabstrahiert und Dateilisten für die Pakete gibt's auch nicht. Da sogar bei freedesktop.org dieser Pfad verwendet wird, gehe ich davon aus, dass Fedora und Suse es aber ebenfalls dort liegen haben.

Ich danke für Aufklärung!

fs4000

http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLIBLIBRARIESFORPROGRAMMINGANDPA

/usr/lib includes object files, libraries, and internal binaries that are not intended to be executed directly by users or shell scripts.

Im neuen FHS 3.0 hat man dazu /usr/libexec geschaffen: http://www.linuxbase.org/betaspecs/fhs/fhs/ch04s07.html

=> Das Zeug soll halt einfach nicht in $PATH liegen, weil es sinnlos wäre sowas zu starten.

~~Um noch deine Frage nach dem Pfad bei Fedora und Suse zu beantworten: Die basieren auf RedHat und haben schon lange /usr/libexec.~~

Edit: Aber gerade hier nutzt Fedora doch wieder /usr/lib?!? Verstehen muss man das nicht… Zu Suse sag ich dann mal doch besser nichts.

Ovion

Ach so, danke!
Ich find's zwar immer noch nicht intuitiv, aber zumindest weiß ich jetzt, warum's da liegt.

Warum der Ordner libexec auch wieder auf Librarys bezug nehmen muss, anstatt sysexec oder sysbin oder so zu heißen, erschließt sich mir aber noch immer nicht (oder habe einen falschen Library-Begriff). Aber ich nehme mal an, dass ist lediglich eine Namensentscheidung nach Gusto ohne technischen Hintergrund?

fs4000

Naja, Libraries und Executables unterscheiden sich intern nicht großartig voneinander. Die Unterscheidung, ruft es der Benutzer auf oder wird es von einem anderen Programm geladen, ist da viel offensichtlicher.

Beispiel:

$ /usr/lib/libc-2.17.so 
GNU C Library (GNU libc) stable release version 2.17, by Roland McGrath et al.
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 4.8.0.
Compiled on a Linux 3.8.4 system on 2013-04-09.
Available extensions:
	crypt add-on version 2.1 by Michael Glad and others
	GNU Libidn by Simon Josefsson
	Native POSIX Threads Library by Ulrich Drepper et al
	BIND-8.2.3-T5B
libc ABIs: UNIQUE IFUNC
For bug reporting instructions, please see:
<https://bugs.archlinux.org/>.

Library und ausführbar, wie soll man das jetzt einordnen? 😉

Ovion

Schon wahr. Was passiert denn, wenn man das Ding ausführt (bzw. kann ich das ohne Nebenwirkungen ausprobieren)? Nach meinem Verständnis ist ein binary mit main-Methode (bzw. Main-Methode mit für das binary "sinnvoller" Funktion*) ein Programm, eines ohne main() eine lib.
Quasi die Frage: Ist das binary eigenständig in einer Form benutzbar, die über "ich kann den Namen in die Konsole tippen und bekomme den nächsten Terminalprompt" hinausgeht?
Ist es nicht eigenständig benutzbar => lib, sonst Programm
Mischformen gibt es natürlich sicher auch.

Gibt es etwas, was dieser Betrachtung entgegenspricht?

*) Wenn ich einen mysql-über-Netzwerk-Wrapper habe und dessen main() gibt "hello World" auf die Konsole, zählt das für mich nicht zu "für das binary sinnvoll" => lib