One of systemd’s main goals is to unify basic Linux configurations and service behaviors across all distributions.
Is it a bug – or a feature?
social competence(social skills such as face2face-communication) is a rare good on this planet – and especially in tech-heavy industries such as computers – where people dealing with machines all week long – tend to become themselves – machines. (brain forgets how to verbal speak)
Humans != machines. Humans should have consciousness (hopefully) that allows them to realize „what is the right thing“ and emotions that (hopefully) motivates them – to „do the right thing“ – machines have not yet such features. (CIA investing into quantum computing, Mr Musk investing into AI development)
Without social skills – cooperation between humans declines – without cooperation mankind is fucked.
And Mr Torvalds thinks if you are NOT rude – people won’t understand you. I disagree.
I would say – this is placed in the area of project-management – especially software-project management.
And as you can read in my article – „how to write perfect software and finish on time“ (not) you will realize – errors are not the exception – they are the rule – and rate of errors increases with complexity (amount of people, features and lines of code).
technical but also concept-errors, design errors so to speak.
so every software company and product needs 1. time-to-ripe and 2. some form of quality-and-error-management. If not – they believe to be in god-mode – and forget – only nobody is perfect. But who would like to be a nobody?
what could Mr Torvalds improve in his way of communication – what we all should do – no matter how angry you are try:
1. say something positive
and you will be heared. completely without scandals.
back to topic:
systemd is a suite of basic building blocks for a Linux system. It provides a system and service manager that runs as PID 1 and starts the rest of the system. systemd provides aggressive parallelization capabilities, uses socket and D-Bus activation for starting services, offers on-demand starting of daemons, keeps track of processes using Linux control groups, maintains mount and automount points, and implements an elaborate transactional dependency-based service control logic. systemd supports SysV and LSB init scripts and works as a replacement for sysvinit. Other parts include a logging daemon, utilities to control basic system configuration like the hostname, date, locale, maintain a list of logged-in users and running containers and virtual machines, system accounts, runtime directories and settings, and daemons to manage simple network configuration, network time synchronization, log forwarding, and name resolution. See Lennart’s blog story for a longer introduction, and the three status updates since then. Also see the Wikipedia article. If you are wondering whether systemd is for you, please have a look at this comparison of init systems by one of the creators of systemd.
systemd provides various interfaces developers and programs might rely on. Starting with version 26 (the first version released with Fedora 15) we promise to keep a number of them stable and compatible for the future.
The stable interfaces are:
- The unit configuration file format. Unit files written now will stay compatible with future versions of systemd. Extensions to the file format will happen in a way that existing files remain compatible.
- The command line interface of systemctl, loginctl, journalctl. We will make sure that scripts invoking these commands will continue to work with future versions of systemd. Note however that the output generated by these commands is generally not included in the promise, unless it is documented in the man page. Example: the output of „systemctl status“ is not stable, but the one of „systemctl show“ is, because the former is intended to be human readable and the latter computer readable, and this is documented in the man page.
- The protocol spoken on the socket referred to by $NOTIFY_SOCKET, as documented in sd_notify(3).
- Some of the „special“ unit names and their semantics. To be precise the ones that are necessary for normal services, and not those required only for early boot and late shutdown, with very few exceptions. To list them here: basic.target, shutdown.target, sockets.target, network.target, getty.target, graphical.target, multi-user.target, rescue.target, emergency.target, poweroff.target, reboot.target, halt.target, runlevel[1-5].target.
- For a more comprehensive and authoritative list, consult the Interface Portability And Stability Chart
The following interfaces will not necessarily be kept stable for now, but we will eventually make a stability promise for these interfaces too. In the meantime we will however try to keep breakage of these interfaces at a minimum:
- The D-Bus interfaces of the main service daemon (!) [ An additional restriction applies here: functionality we consider legacy might not be available based on compile-time options, such as SysV support, libwrap support and similar. Apps should not assume properties and methods related to this functionality are unconditionally available in the D-Bus interfaces. ]
- The set of states of the various state machines used in systemd, e.g. the high-level unit states inactive, active, deactivating, and so on, as well (and in particular) the low-level per-unit states.
- All „special“ units that aren’t listed above.
The following interfaces are considered private to systemd, and are not and will not be covered by any stability promise:
- Undocumented switches to systemd, systemctl and otherwise
- The internal protocols used on the various sockets such as the sockets /run/systemd/shutdown, /run/systemd/private.
One of the main goals of systemd is to unify basic Linux configurations and service behaviors across all distributions. Systemd project does not contain any distribution-specific parts. Distributions are expected to convert over time their individual configurations to the systemd format, or they will need to carry and maintain patches in their package if they still decide to stay different.
What does this mean for you? When developing with systemd, don’t use any of the latter interfaces – use systemd.
You are welcome to use other interfaces, but if you use any of the second kind (i.e. those where we don’t yet make a stability promise), then make sure to subscribe to our mailing list, where we will announce API changes, and be prepared to update your program eventually.
Note that this is a promise, not an eternal guarantee. These are our intentions, but if in the future there are very good reasons to change or get rid of an interface we have listed above as stable, then we might take the liberty to do so, despite this promise. However, if we do this, then we’ll do our best to provide a smooth and reasonably long transition phase.
where is systemd?
lrwxrwxrwx 1 root root 20 Apr 8 23:08 init -> /lib/systemd/systemd
lrwxrwxrwx 1 root root 14 Apr 8 23:08 telinit -> /bin/systemctl
root@debian:~# stat /lib/systemd/systemd
Size: 1316528 Blocks: 2576 IO Block: 4096 regular file
Device: 801h/2049d Inode: 6294591 Links: 1
Access: (0755/-rwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root)
Useful SystemD commands (hints for systemctl or systemctl vs chkconfig and service)
List all running services
Start/stop or enable/disable services
Activates a service immediately:
# systemctl start foo.service
Deactivates a service immediately:
# systemctl stop foo.service
Restarts a service:
# systemctl restart foo.service
Shows status of a service including whether it is running or not:
# systemctl status foo.service
Enables a service to be started on bootup:
# systemctl enable foo.service
Disables a service to not start during bootup:
# systemctl disable foo.service
Check whether a service is already enabled or not:
# systemctl is-enabled foo.service; echo $?
0 indicates that it is enabled. 1 indicates that it is disabled
How do I change the runlevel?
systemd has the concept of targets which is a more flexible replacement for runlevels in sysvinit.
Run level 3 is emulated by multi-user.target. Run level 5 is emulated by graphical.target. runlevel3.target is a symbolic link to multi-user.target and runlevel5.target is a symbolic link to graphical.target.
You can switch to ‘runlevel 3′ by running
# systemctl isolate multi-user.target (or) systemctl isolate runlevel3.target
You can switch to ‘runlevel 5′ by running
# systemctl isolate graphical.target (or) systemctl isolate runlevel5.target
How do I change the default runlevel?
systemd uses symlinks to point to the default runlevel. You have to delete the existing symlink first before creating a new one
# rm /etc/systemd/system/default.target
Switch to runlevel 3 by default
# ln -sf /lib/systemd/system/multi-user.target /etc/systemd/system/default.target
Switch to runlevel 5 by default
# ln -sf /lib/systemd/system/graphical.target /etc/systemd/system/default.target
systemd does not use /etc/inittab file.
List the current run level
runlevel command still works with systemd. You can continue using that however runlevels is a legacy concept in systemd and is emulated via ‘targets’ and multiple targets can be active at the same time. So the equivalent in systemd terms is
# systemctl list-units --type=target
Powering off the machine
You can use
Some more possibilities are: halt -p, init 0, shutdown -P now
Note that halt used to work the same as poweroff in previous Fedora releases, but systemd distinguishes between the two, so halt without parameters now does exactly what it says – it merely stops the system without turning it off.
Service vs. systemd
# service NetworkManager stop
# systemctl stop NetworkManager.service
Chkconfig vs. systemd
# chkconfig NetworkManager off
# systemctl disable NetworkManager.service
systemd has a built-in readahead implementation is not enabled on upgrades. It should improve bootup speed but your mileage may vary depending on your hardware. To enable it:
# systemctl enable systemd-readahead-collect.service # systemctl enable systemd-readahead-replay.service
|service foobar start||systemctl start foobar.service||Used to start a service (not reboot persistent)|
|service foobar stop||systemctl stop foobar.service||Used to stop a service (not reboot persistent)|
|service foobar restart||systemctl restart foobar.service||Used to stop and then start a service|
|service foobar reload||systemctl reload foobar.service||When supported, reloads the config file without interrupting pending operations.|
|service foobar condrestart||systemctl condrestart foobar.service||Restarts if the service is already running.|
|service foobar status||systemctl status foobar.service||Tells whether a service is currently running.|
|ls /etc/rc.d/init.d/||ls /lib/systemd/system/*.service /etc/systemd/system/*.service||Used to list the services that can be started or stopped|
|chkconfig foobar on||systemctl enable foobar.service||Turn the service on, for start at next boot, or other trigger.|
|chkconfig foobar off||systemctl disable foobar.service||Turn the service off for the next reboot, or any other trigger.|
|chkconfig foobar||systemctl is-enabled foobar.service||Used to check whether a service is configured to start or not in the current environment.|
|chkconfig foobar –list||ls /etc/systemd/system/*.wants/foobar.service||Used to list what levels this service is configured on or off|
|chkconfig foobar –add||Not needed, no equivalent.|
systemd is still a young project, but it is not a baby anymore. The initial announcement I posted precisely a year ago. Since then most of the big distributions have decided to adopt it in one way or another, many smaller distributions have already switched. The first big distribution with systemd by default will be Fedora 15, due end of May. It is expected that the others will follow the lead a bit later (with one exception). Many embedded developers have already adopted it too, and there’s even a company specializing on engineering and consulting services for systemd. In short: within one year systemd became a really successful project.
However, there are still folks who we haven’t won over yet. If you fall into one of the following categories, then please have a look on the comparison of init systems below:
- You are working on an embedded project and are wondering whether it should be based on systemd.
- You are a user or administrator and wondering which distribution to pick, and are pondering whether it should be based on systemd or not.
- You are a user or administrator and wondering why your favourite distribution has switched to systemd, if everything already worked so well before.
- You are developing a distribution that hasn’t switched yet, and you are wondering whether to invest the work and go systemd.
And even if you don’t fall into any of these categories, you might still find the comparison interesting.
We’ll be comparing the three most relevant init systems for Linux: sysvinit, Upstart and systemd. Of course there are other init systems in existance, but they play virtually no role in the big picture. Unless you run Android (which is a completely different beast anyway), you’ll almost definitely run one of these three init systems on your Linux kernel. (OK, or busybox, but then you are basically not running any init system at all.) Unless you have a soft spot for exotic init systems there’s little need to look further. Also, I am kinda lazy, and don’t want to spend the time on analyzing those other systems in enough detail to be completely fair to them.
Speaking of fairness: I am of course one of the creators of systemd. I will try my best to be fair to the other two contenders, but in the end, take it with a grain of salt. I am sure though that should I be grossly unfair or otherwise incorrect somebody will point it out in the comments of this story, so consider having a look on those, before you put too much trust in what I say.
We’ll look at the currently implemented features in a released version. Grand plans don’t count.
|Interfacing via D-Bus||no||yes||yes|
|Modular C coded early boot services included||no||no||yes|
|Socket-based Activation: inetd compatibility||no||no||yes|
|Configuration of device dependencies with udev rules||no||no||yes|
|Path-based Activation (inotify)||no||no||yes|
|Snapshotting of system state||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|
|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|
|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|
|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|
|Built-In Profiling and Tools||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 services controllable like native services||yes||no||yes|
|Reexecution with full serialization of state||yes||no||yes|
|Container support (as advanced chroot() replacement)||no||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|
|Easily writable, extensible and parseable service files, suitable for manipulation with enterprise management tools||no||no||yes|
 Read-Ahead implementation for Upstart available in separate package ureadahead, requires non-standard kernel patch.
 Socket activation implementation for Upstart available as preview, lacks parallelization support hence entirely misses the point of socket activation.
 Bus activation implementation for Upstart posted as patch, not merged.
 udev device event bridge implementation for Upstart available as preview, forwards entire udev database into Upstart, not practical.
 Mount handling utility mountall for Upstart available in separate package, covers only boot-time mounts, very limited dependency system.
 Some distributions offer this implemented in shell.
 LSB init scripts support this, if they are used.
Available Native Service Settings
|Root Directory (chroot())||no||yes||yes|
|Environment Variables from external file||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|
|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|
 Upstart supports only the deprecated oom_score_adj mechanism, not the current oom_adj logic.
 Upstart lacks support for RLIMIT_RTTIME and RLIMIT_RTPRIO.
Note that some of these options are relatively easily added to SysV init scripts, by editing the shell sources. The table above focusses on easily accessible options that do not require source code editing.
|Maturity||> 15 years||6 years||1 year|
|Specialized professional consulting and engineering services available||no||no||yes|
As the tables above hopefully show in all clarity systemd has left behind both sysvinit and Upstart in almost every aspect. With the exception of the project’s age/maturity systemd wins in every category. At this point in time it will be very hard for sysvinit and Upstart to catch up with the features systemd provides today. In one year we managed to push systemd forward much further than Upstart has been pushed in six.
It is our intention to drive forward the development of the Linux platform with systemd. In the next release cycle we will focus more strongly on providing the same features and speed improvement we already offer for the system to the user login session. This will bring much closer integration with the other parts of the OS and applications, making the most of the features the service manager provides, and making it available to login sessions. Certain components such as ConsoleKit will be made redundant by these upgrades, and services relying on them will be updated. The burden for maintaining these then obsolete components will be passed on the vendors who plan to continue to rely on them.
If you are wondering whether or not to adopt systemd, then systemd obviously wins when it comes to mere features. Of course that should not be the only aspect to keep in mind. In the long run, sticking with the existing infrastructure (such as ConsoleKit) comes at a price: porting work needs to take place, and additional maintainance work for bitrotting code needs to be done. Going it on your own means increased workload.
That said, adopting systemd is also not free. Especially if you made investments in the other two solutions adopting systemd means work. The basic work to adopt systemd is relatively minimal for porting over SysV systems (since compatibility is provided), but can mean substantial work when coming from Upstart. If you plan to go for a 100% systemd system without any SysV compatibility (recommended for embedded, long run goal for the big distributions) you need to be willing to invest some work to rewrite init scripts as simple systemd unit files.
systemd is in the process of becoming a comprehensive, integrated and modular platform providing everything needed to bootstrap and maintain an operating system’s userspace. It includes C rewrites of all basic early boot init scripts that are shipped with the various distributions. Especially for the embedded case adopting systemd provides you in one step with almost everything you need, and you can pick the modules you want. The other two init systems are singular individual components, which to be useful need a great number of additional components with differing interfaces. The emphasis of systemd to provide a platform instead of just a component allows for closer integration, and cleaner APIs. Sooner or later this will trickle up to the applications. Already, there are accepted XDG specifications (e.g. XDG basedir spec, more specifically XDG_RUNTIME_DIR) that are not supported on the other init systems.
systemd is also a big opportunity for Linux standardization. Since it standardizes many interfaces of the system that previously have been differing on every distribution, on every implementation, adopting it helps to work against the balkanization of the Linux interfaces. Choosing systemd means redefining more closely what the Linux platform is about. This improves the lifes of programmers, users and administrators alike.
I believe that momentum is clearly with systemd. We invite you to join our community and be part of that momentum.
systemctl – output process tree
Since: Di 2017-05-02 15:51:20 CEST; 28min left
│ └─1 /usr/lib/systemd/systemd --switched-root --system --deserialize 23
│ │ └─1074 /bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation
│ │ └─2124 /usr/sbin/cron -n
│ │ └─1257 /usr/sbin/wickedd --systemd --foreground
│ │ └─1105 /usr/lib/hyper-v/bin/hv_vss_daemon --no-daemon
│ │ ├─2105 /usr/lib/postfix/master -w
│ │ ├─2106 pickup -l -t fifo -u
│ │ └─2107 qmgr -l -t fifo -u
│ │ └─1260 /usr/sbin/wickedd-nanny --systemd --foreground
│ │ └─1220 /usr/lib/accounts-daemon
│ │ └─1082 /usr/sbin/nscd
│ │ └─565 /usr/lib/systemd/systemd-journald
│ │ └─1815 /usr/lib/udisks2/udisksd --no-debug
│ │ └─1246 /usr/lib/wicked/bin/wickedd-dhcp4 --systemd --foreground
│ │ ├─1205 /usr/sbin/gdm
│ │ ├─1211 /usr/lib/gdm/gdm-simple-slave --display-id /org/gnome/DisplayManager/Displays/_0
│ │ └─1219 /usr/bin/Xorg :0 -background none -verbose -auth /run/gdm/auth-for-gdm-ZAzyg4/database -seat seat0 vt7
│ │ └─1607 /usr/lib/upower/upowerd
│ │ └─1110 /usr/lib/systemd/systemd-logind
│ │ └─1244 /usr/lib/wicked/bin/wickedd-dhcp6 --systemd --foreground
│ │ └─firstname.lastname@example.org
│ │ └─1125 /sbin/agetty --noclear tty1 linux
│ │ └─1957 /usr/sbin/sshd -D
│ │ └─611 /usr/lib/systemd/systemd-udevd
│ │ └─582 /usr/sbin/haveged -w 1024 -v 0 -F
│ │ └─1242 /usr/lib/wicked/bin/wickedd-auto4 --systemd --foreground
│ │ └─1231 /usr/lib/polkit-1/polkitd --no-debug
│ │ └─1067 /usr/sbin/irqbalance --foreground
│ │ └─1921 /usr/lib/hyper-v/bin/hv_kvp_daemon --no-daemon
│ │ └─1106 /usr/sbin/rsyslogd -n
│ └─1619 /usr/lib/rtkit/rtkit-daemon
│ ├─1665 gdm-session-worker [pam/gdm-password]
│ ├─1678 /usr/bin/gnome-keyring-daemon --daemonize --login
│ ├─1682 /usr/lib/gnome-session-binary --session gnome-classic
│ ├─1737 /usr/bin/dbus-launch --sh-syntax --exit-with-session /usr/bin/ssh-agent /etc/X11/xinit/xinitrc --session gnome-classic
│ ├─1738 /bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session
│ ├─1739 /usr/bin/ssh-agent /etc/X11/xinit/xinitrc --session gnome-classic
│ ├─1745 /usr/lib/at-spi2/at-spi-bus-launcher
│ ├─1750 /bin/dbus-daemon --config-file=/usr/share/defaults/at-spi2/accessibility.conf --nofork --print-address 3
│ ├─1754 /usr/lib/at-spi2/at-spi2-registryd --use-gnome-session
│ ├─1768 /usr/bin/gnome-shell
│ ├─1774 /usr/lib/gvfs/gvfsd
│ ├─1779 /usr/lib/gvfs/gvfsd-fuse /run/user/1000/gvfs -f -o big_writes
│ ├─1797 /usr/bin/pulseaudio --start --log-target=syslog
│ ├─1812 /usr/lib/gvfs/gvfs-udisks2-volume-monitor
│ ├─1825 /usr/lib/gvfs/gvfs-mtp-volume-monitor
│ ├─1830 /usr/lib/gvfs/gvfs-gphoto2-volume-monitor
│ ├─1835 /usr/lib/gvfs/gvfs-goa-volume-monitor
│ ├─1839 /usr/lib/gnome-settings-daemon-3.0/gnome-settings-daemon
│ ├─1860 /usr/lib/gnome-settings-daemon-3.0/gsd-printer
│ ├─1861 nautilus --no-default-window --force-desktop
│ ├─1873 /usr/lib/dconf-service
│ ├─1883 /usr/lib/gvfs/gvfsd-trash --spawner :1.9 /org/gtk/gvfs/exec_spaw/0
│ ├─1893 /usr/lib/gvfs/gvfsd-burn --spawner :1.9 /org/gtk/gvfs/exec_spaw/1
│ ├─2655 /usr/lib/gvfs/gvfsd-metadata
│ ├─2798 /usr/lib/gnome-terminal-server
│ ├─2818 bash
│ ├─2838 su
│ └─2841 bash
│ ├─1670 /usr/lib/systemd/systemd --user
│ └─1672 (sd-pam)
├─3135 sshd: user [priv]
├─3139 sshd: user@pts/1
└─3192 systemctl status
show services and mount points with systemd
UNIT LOAD ACTIVE SUB DESCRIPTION
-.mount loaded active mounted /
\x2esnapshots.mount loaded active mounted /.snapshots
boot-grub2-i386\x2dpc.mount loaded active mounted /boot/grub2/i386-pc
boot-grub2-x86_64\x2defi.mount loaded active mounted /boot/grub2/x86_64-efi
dev-hugepages.mount loaded active mounted Huge Pages File System
dev-mqueue.mount loaded active mounted POSIX Message Queue File System
home.mount loaded active mounted /home
opt.mount loaded active mounted /opt
run-user-1000-gvfs.mount loaded active mounted /run/user/1000/gvfs
run-user-1000.mount loaded active mounted /run/user/1000
srv.mount loaded active mounted /srv
sys-fs-fuse-connections.mount loaded active mounted FUSE Control File System
sys-kernel-debug.mount loaded active mounted Debug File System
tmp.mount loaded active mounted /tmp
usr-local.mount loaded active mounted /usr/local
var-cache.mount loaded active mounted /var/cache
var-crash.mount loaded active mounted /var/crash
var-lib-libvirt-images.mount loaded active mounted /var/lib/libvirt/images
var-lib-machines.mount loaded active mounted /var/lib/machines
var-lib-mailman.mount loaded active mounted /var/lib/mailman
var-lib-mariadb.mount loaded active mounted /var/lib/mariadb
var-lib-mysql.mount loaded active mounted /var/lib/mysql
var-lib-named.mount loaded active mounted /var/lib/named
var-lib-pgsql.mount loaded active mounted /var/lib/pgsql
var-log.mount loaded active mounted /var/log
var-opt.mount loaded active mounted /var/opt
var-spool.mount loaded active mounted /var/spool
var-tmp.mount loaded active mounted /var/tmp
LOAD = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB = The low-level unit activation state, values depend on unit type.
28 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.
systemd – Which services are enabled disabled?
UNIT FILE STATE
alternative to htop?
Control Group Tasks %CPU Memory Input/s Output/s
/ - 0.7 543.0M - -
/init.scope 1 - - - -
/system.slice 67 - - - -
/system.slice/accounts-daemon.service 3 - - - -
/system.slice/cron.service 1 - - - -
/system.slice/dbus.service 1 - - - -
/system.slice/display-manager.service 9 - - - -
/system.slice/haveged.service 1 - - - -
/system.slice/hv_kvp_daemon.service 1 - - - -
/system.slice/hv_vss_daemon.service 1 - - - -
/system.slice/irqbalance.service 1 - - - -
/system.slice/nscd.service 11 - - - -
/system.slice/packagekit.service 4 - - - -
/system.slice/polkit.service 6 - - - -
/system.slice/rsyslog.service 5 - - - -
/system.slice/rtkit-daemon.service 3 - - - -
/system.slice/sshd.service 1 - - - -
/system.slice/system-getty.slice 1 - - - -
/email@example.com 1 - - - -
/system.slice/systemd-hostnamed.service 1 - - - -
/system.slice/systemd-journald.service 1 - - - -
/system.slice/systemd-localed.service 1 - - - -
/system.slice/systemd-logind.service 1 - - - -
/system.slice/systemd-udevd.service 1 - - - -
/system.slice/udisks2.service 5 - - - -
/system.slice/upower.service 3 - - - -
/system.slice/wickedd-auto4.service 1 - - - -
/system.slice/wickedd-dhcp4.service 1 - - - -
/system.slice/wickedd-dhcp6.service 1 - - - -
/system.slice/wickedd-nanny.service 1 - - - -
/system.slice/wickedd.service 1 - - - -
/user.slice 92 - - - -
/user.slice/user-1000.slice 92 - - - -
/user.slice/user-1000.slice/session-1.scope 81 - - - -
/user.slice/user-1000.slice/session-2.scope 6 - - - -
/user.slice/user-1000.slice/session-3.scope 3 - - - -
/firstname.lastname@example.org 2 - - - -