User:Tsu2/systemd-3
systemd status - One Command to Rule Them All
Well, not exactly. But it'll display a lot of good, useful stuff.
Starting with openSUSE 12.3 (will vary with other distros), the journal has been implemented which will eventually replace the syslog at /var/log/messages (will vary with other distros). Like everything else about systemd, the availablility of the journal does not mean that older, legacy methods of reading and writing to the syslog cease to exist, if you prefer grepping the syslog, go ahead and do that but you may find that the journal is far more efficient and saves time.
Some systemd fundamentals required before using the journal...
systemd is a replacement for earlier Linux subsystems, bootup and shutdown management, unifying the many systems like SystemV use of bash init scripts, udev for device auto detection and configuration, mounting and unmounting partitions and devices, even basic commands like start, restart and shutdown which can vary from distro to distro.
You no longer need to learn how each and every subsystem works and their unique commands, you now have a single system that does it all and uses similar commands applied to every "unit." Units are the objects that represent every manageable subsystem type. To date there are 10 main types(may grow) but there is also an additional "special" type which is the wild card that can be used to manage units that don't fit into the standard types. The "systemd." part of the name is required when defining configurations, which can often be omitted when using the command line.
| Unit Types | |
|---|---|
| systemd.service | service |
| systemd.socket | socket based activation (eg network sockets) |
| systemd.target | during bootup, "synchronization points" |
| systemd.device | Expose kernel-based device support, can be used for device based activation |
| systemd.mount | mount points |
| systemd.automount | parallelized bootup and on demand mount points |
| systemd.snapshot | preserve state of a set of units |
| systemd.snapshot | preserve state of a set of units |
| systemd.timer | trigger units based on timers |
| systemd.swap | similar.mount, but for swap files and partitions |
| systemd.path | dynamically add/remove paths for units when changed or modified |
| <special>.target | A number of special units that invoke common functionality, Can be invoked by CLI |
Troubleshooting
In almost all cases, now a single command may give you all the info you need where to fix your problem
| systemctl status <unitname.unittype> |
The trick may be to identify exactly what the unitname is, if you don't know already you can list all the units on your system but the list will be very, very long
| systemctl -a |
If you only want to list the loaded units, just type systemctl by itself with no flags
| systemctl |
If you only want to list a unit type, you can specify. The following lists only the services (daemons) on your system, see the above list for other unit types
| systemctl --type=service |
You can read the documentation for other options including scoping the list by state if you wish.
The following is an example of "systemd status" which you should post with your question in the Technical Help Forums. Note that it identifies among things the simple name of the problem unit, the location of your error and a few lines of the journal related to the error.
| # systemctl status dnsmasq.service
dnsmasq.service - DNS caching server. Loaded: loaded (/lib/systemd/system/dnsmasq.service; enabled)
Active: failed (Result: exit-code) since Fri, 22 Feb 2013 14:04:13 -0800; 1 weeks and 1 days ago
CGroup: name=systemd:/system/dnsmasq.service
Feb 22 14:04:12 VISTA dnsmasq[731]: dnsmasq: error at line 95 of /etc/dnsmasq.conf |
Newbie hint - Writing output to file:
If copying from the console is uncomfortable, you can easily create a text file containing the results of your command, so from wherever your command prompt exists (maybe ~/Documents) the following creates a filename "journalresult.txt" with the results.
| systemctl status <unitname>.<unittype > journalresult.txt |
additional information
| MAN pages of course! (But it's long and sometimes complex) |
| Link to SDB systemd - None seems to exist today |
| A slide deck introducing systemd |
| Lennart Poettering's systemd blog (>20 installments), a primary author of systemd |
| Freedesktop.org systemd landing page |
| Link to something |