Systemd – dlaczego warto go używać

Systemd – dlaczego warto go używać

    przez -
    36 1513
    Linux Tux
    Lennart Poettering opublikował na swoim blogu porównanie systemd z SysVinit i Upstart. Jest to liczący sobie około 18 miesięcy projekt, a jego celem ma być stworzenie nowego daemona init dla systemów Linux, który zunifikuje cały proces startu systemu. Aktualnie jest tak, iż każda dystrybucja posiada własny zestaw skryptów startowych, które były diametralnie różne pomiędzy sobą. Teraz dużą część najczęściej wykonywanych podczas startu systemu rzeczy zajmie się systemd.

    W dalszym etapie startu systemu – gdy są uruchamiane usługi systemowe działają serwisy systemd, które są przenośne pomiędzy dystrybucjami. Dzięki temu programiści nie muszą pisać osobnych skryptów startowych daemona do każdej dystrybucji, a mogą za jednym razem dostarczyć go wraz z systemd.

    Aktualnie dystrybucjami, które zaadoptowały nowego daemona są Fedora 15, openSUSE, Mandriva, Arch, Frugalware i Debian.

    Poniższa tabela ilustruje porównanie możliwości SysVinit, Upstart oraz SystemD:

    sysvinit Upstart systemd
    Interfacing via D-Bus no yes yes
    Shell-free bootup no no yes
    Modular C coded early boot services included no no yes
    Read-Ahead no no[1] yes
    Socket-based Activation no no[2] yes
    Socket-based Activation: inetd compatibility no no[2] yes
    Bus-based Activation no no[3] yes
    Device-based Activation no no[4] yes
    Configuration of device dependencies with udev rules no no yes
    Path-based Activation (inotify) no no yes
    Timer-based Activation no no yes
    Mount handling no no[5] yes
    fsck handling no no[5] yes
    Quota handling no no yes
    Automount handling no no yes
    Swap handling no no yes
    Snapshotting of system state no no yes
    XDG_RUNTIME_DIR Support no no yes
    Optionally kills remaining processes of users logging out no no yes
    Linux Control Groups Integration no no yes
    Audit record generation for started services no no yes
    SELinux integration no no yes
    PAM integration no no yes
    Encrypted hard disk handling (LUKS) no no yes
    SSL Certificate/LUKS Password handling, including Plymouth, Console, wall(1), TTY and GNOME agents no no yes
    Network Loopback device handling no no yes
    binfmt_misc handling no no yes
    System-wide locale handling no no yes
    Console and keyboard setup no no yes
    Infrastructure for creating, removing, cleaning up of temporary and volatile files no no yes
    Handling for /proc/sys sysctl no no yes
    Plymouth integration no yes yes
    Save/restore random seed no no yes
    Static loading of kernel modules no no yes
    Automatic serial console handling no no yes
    Unique Machine ID handling no no yes
    Dynamic host name and machine meta data handling no no yes
    Reliable termination of services no no yes
    Early boot /dev/log logging no no yes
    Minimal kmsg-based syslog daemon for embedded use no no yes
    Respawning on service crash without losing connectivity no no yes
    Gapless service upgrades no no yes
    Graphical UI no no yes
    Built-In Profiling and Tools no no yes
    Instantiated services no yes yes
    PolicyKit integration no no yes
    Remote access/Cluster support built into client tools no no yes
    Can list all processes of a service no no yes
    Can identify service of a process no no yes
    Automatic per-service CPU cgroups to even out CPU usage between them no no yes
    Automatic per-user cgroups no no yes
    SysV compatibility yes yes yes
    SysV services controllable like native services yes no yes
    SysV-compatible /dev/initctl yes no yes
    Reexecution with full serialization of state yes no yes
    Interactive boot-up no[6] no[6] yes
    Container support (as advanced chroot() replacement) no no yes
    Dependency-based bootup no[7] no yes
    Disabling of services without editing files yes no yes
    Masking of services without editing files no no yes
    Robust system shutdown within PID 1 no no yes
    Built-in kexec support no no yes
    Dynamic service generation no no yes
    Upstream support in various other OS components yes no yes
    Service files compatible between distributions no no yes
    Signal delivery to services no no yes
    Reliable termination of user sessions before shutdown no no yes
    utmp/wtmp support yes yes yes
    Easily writable, extensible and parseable service files, suitable for manipulation with enterprise management tools no no yes

    Prócz tego dostępne natywne opcje usług:

    sysvinit Upstart systemd
    OOM Adjustment no yes[1] yes
    Working Directory no yes yes
    Root Directory (chroot()) no yes yes
    Environment Variables no yes yes
    Environment Variables from external file no no yes
    Resource Limits no some[2] yes
    umask no yes yes
    User/Group/Supplementary Groups no no yes
    IO Scheduling Class/Priority no no yes
    CPU Scheduling Nice Value no yes yes
    CPU Scheduling Policy/Priority no no yes
    CPU Scheduling Reset on fork() control no no yes
    CPU affinity no no yes
    Timer Slack no no yes
    Capabilities Control no no yes
    Secure Bits Control no no yes
    Control Group Control no no yes
    High-level file system namespace control: making directories inacessible no no yes
    High-level file system namespace control: making directories read-only no no yes
    High-level file system namespace control: private /tmp no no yes
    High-level file system namespace control: mount inheritance no no yes
    Input on Console yes yes yes
    Output on Syslog no no yes
    Output on kmsg/dmesg no no yes
    Output on arbitrary TTY no no yes
    Kill signal control no no yes
    Conditional execution: by identified CPU virtualization/container no no yes
    Conditional execution: by file existance no no yes
    Conditional execution: by security framework no no yes
    Conditional execution: by kernel command line no no yes