More systemd tools

[dos2unix]

hostnamectl - Managing Hostnames the Modern Way
For decades, changing a hostname on Linux meant editing multiple files and crossing your fingers that you got them all. Here's what we used to do:
The old way:

Edit the hostname file
vim /etc/hostname
Update the hosts file
vim /etc/hosts
(Edit the 127.0.1.1 line to match new hostname)
On older RHEL/CentOS systems
vim /etc/sysconfig/network
(Update HOSTNAME= line)
Apply it immediately (maybe)
hostname newname.example.com
Reboot to make sure it actually stuck
reboot

You had to remember which files mattered for your particular distro, hope you didn't make a typo in any of them, and often just rebooted to be certain everything took effect properly.
The new way:

hostnamectl set-hostname server01.example.com

That's it. One command handles everything - updates all the necessary files, applies the change immediately, and persists across reboots.
Useful commands:
Check your current hostname and related info:

hostnamectl

This shows you:

Static hostname (what's in the config files)
Transient hostname (currently active)
Pretty hostname (human-readable description)
Icon name, chassis type, machine ID, boot ID
Operating system info
Kernel version

Set a pretty hostname (with spaces and special characters):

hostnamectl set-hostname --pretty "Ray's Production Database Server"

The pretty hostname is stored in /etc/machine-info and can be used by applications that want a more descriptive name.
What it does behind the scenes:

Updates /etc/hostname with your static hostname
Updates /etc/machine-info for pretty hostname and other metadata
Notifies systemd and other services of the change
No manual /etc/hosts editing needed for the basic hostname

It's not just about convenience - it's about consistency. The old way left room for discrepancies between files, between what the kernel thought the hostname was and what was in config files. hostnamectl ensures everything stays in sync.

 

[dos2unix]

timedatectl - Managing Time, Date, and Timezones the Modern Way
Managing system time used to involve multiple tools and commands depending on what you needed to change. Hardware clock, system clock, timezones, NTP - each had its own approach and potential pitfalls.
The old way:
Setting the date and time:

Set system time
date --set="2024-01-15 14:30:00"
Sync to hardware clock
hwclock --systohc
Or set hardware clock directly
hwclock --set --date="2024-01-15 14:30:00"
hwclock --hctosys

Changing timezones:

Copy or symlink the timezone file
cp /usr/share/zoneinfo/America/Los_Angeles /etc/localtime
Or the symlink approach
ln -sf /usr/share/zoneinfo/America/Los_Angeles /etc/localtime
On older RHEL systems, also edit this
vim /etc/sysconfig/clock
Update ZONE= line

Setting up NTP:

Install and configure NTP daemon
yum install ntp
vim /etc/ntp.conf
systemctl enable ntpd
systemctl start ntpd

You had to remember the difference between system time and hardware clock, figure out the correct timezone path, and manage separate NTP services. Easy to get things out of sync.
The new way:
Check current time settings:

timedatectl

This shows you everything - local time, universal time, RTC time, timezone, whether NTP is enabled, and whether the system clock is synchronized.
Set the date and time:

timedatectl set-time "2024-01-15 14:30:00"

This sets both the system time and syncs it to the hardware clock automatically.
Change timezone:

Find your timezone
timedatectl list-timezones | grep -i los_angeles
Set it
timedatectl set-timezone America/Los_Angeles

Enable NTP synchronization:

timedatectl set-ntp true

This enables systemd-timesyncd, the built-in NTP client. No need to install and configure a separate NTP daemon for basic time synchronization.
Additional useful commands:

Show just the timezone
timedatectl show --property=Timezone --value
Disable NTP if needed
timedatectl set-ntp false
See all available timezones
timedatectl list-timezones

What it does behind the scenes:

Updates /etc/localtime for timezone changes
Manages both system clock and hardware clock synchronization
Controls systemd-timesyncd for NTP
Ensures consistency between all time-related settings

Time synchronization issues can cause serious problems - authentication failures, log correlation headaches, certificate validation errors. timedatectl gives you a single interface to manage all aspects of system time, reducing the chance of configuration drift between the various time-related components.
One note: If you need more advanced NTP features (like serving time to other systems), you'll still want chrony or ntpd. But for most systems that just need to sync their clocks, systemd-timesyncd through timedatectl is sufficient.

 

[dos2unix]

localectl - Managing Locale and Keyboard Settings the Modern Way
System locale and keyboard configuration used to mean editing various files and environment variables, with settings scattered across different locations depending on your distribution.
The old way:
Setting system locale:

Edit the locale configuration file
vim /etc/locale.conf
Or on some systems
vim /etc/sysconfig/i18n
Set variables like:
LANG=en_US.UTF-8
LC_TIME=en_US.UTF-8
LC_MONETARY=en_US.UTF-8
Source it or reboot to apply
source /etc/locale.conf

Configuring keyboard layout:

For console keyboard
vim /etc/vconsole.conf
Set KEYMAP=us
For X11 keyboard
vim /etc/X11/xorg.conf.d/00-keyboard.conf
Configure XkbLayout and other options
Load the new keymap
loadkeys us

You had to know which files your distribution used, remember the correct locale names, and handle console versus X11 keyboard settings separately.
The new way:
Check current locale and keyboard settings:

localectl

This shows you system locale, VC (virtual console) keymap, and X11 keyboard layout all in one view.
Set system locale:

localectl set-locale LANG=en_US.UTF-8

You can set specific locale categories if needed:

localectl set-locale LANG=en_US.UTF-8 LC_TIME=en_GB.UTF-8

Set keyboard layout for console:

localectl set-keymap us

Set X11 keyboard layout:

localectl set-x11-keymap us

For more complex X11 keyboard configurations:

localectl set-x11-keymap us pc105 dvorak compose:ralt

Additional useful commands:

List available locales
localectl list-locales
List available keymaps
localectl list-keymaps
Search for a specific keymap
localectl list-keymaps | grep -i dvora
List X11 layouts
localectl list-x11-keymap-layouts
List X11 models
localectl list-x11-keymap-models
List X11 variants
localectl list-x11-keymap-variants
List X11 options
localectl list-x11-keymap-options

What it does behind the scenes:

Updates /etc/locale.conf for system locale
Updates /etc/vconsole.conf for console keymap
Updates /etc/X11/xorg.conf.d/00-keyboard.conf for X11 settings
Ensures consistency between console and X11 when appropriate

Locale settings affect how dates, times, numbers, and currency are displayed throughout your system. Keyboard layouts are critical for international users or anyone using non-standard layouts like Dvorak or Colemak. localectl provides a consistent interface for managing these settings instead of hunting through multiple configuration files, and it helps ensure that console and graphical environments stay in sync.
Common use case - setting up a server in a different locale:

Set British English with US keyboard
localectl set-locale LANG=en_GB.UTF-8
localectl set-keymap us

 

[dos2unix]

resolvectl - Managing DNS Resolution the Modern Way
DNS configuration used to mean editing resolv.conf and hoping nothing overwrote your changes. Network managers, DHCP clients, and VPN tools all fought over that file, making persistent DNS settings a challenge.
The old way:
Setting DNS servers:

Edit resolv.conf directly
vim /etc/resolv.conf
Add nameservers
nameserver 8.8.8.8
nameserver 8.8.4.4
nameserver 1.1.1.1
Add search domains
search example.com internal.example.com
Set options
options timeout:2 attempts:3

The problem was that /etc/resolv.conf was constantly being overwritten by NetworkManager, dhclient, or other tools. You might make changes that worked until the next DHCP lease renewal.
Some workarounds:

Make it immutable (heavy-handed approach)
chattr +i /etc/resolv.conf
Or configure NetworkManager not to touch it
vim /etc/NetworkManager/NetworkManager.conf
Add: dns=none
Or edit dhclient configuration
vim /etc/dhcp/dhclient.conf
Add: supersede domain-name-servers 8.8.8.8, 8.8.4.4;

Testing DNS resolution:

Use dig or nslookup
dig example.com
nslookup example.com
Check what's actually in resolv.conf
cat /etc/resolv.conf

The new way:
Check current DNS settings:

resolvectl status

This shows you DNS servers for each network interface, global DNS settings, DNSSEC status, and more - a complete picture of your DNS configuration.
Query DNS using the system resolver:

resolvectl query example.com

This shows you exactly how systemd-resolved is resolving names, including which DNS server answered and how long it took.
Check statistics:

resolvectl statistics

Shows cache hit/miss rates and other resolver statistics.
Flush DNS cache:

resolvectl flush-caches

Query specific record types:

resolvectl query example.com --type=MX
resolvectl query example.com --type=TXT
resolvectl query example.com --type=AAAA

Check DNSSEC validation:

resolvectl query example.com --type=A --validate=yes

Set DNS servers (typically done through NetworkManager or systemd-networkd):

With NetworkManager
nmcli connection modify eth0 ipv4.dns "8.8.8.8 8.8.4.4"
nmcli connection up eth0
With systemd-networkd
Edit /etc/systemd/network/your-connection.network
Add under [Network]:
DNS=8.8.8.8
DNS=8.8.4.4

Additional useful commands:

Show detailed status for specific interface
resolvectl status enp0s3
Show just the DNS servers
resolvectl dns
Show search domains
resolvectl domain
Reset statistics
resolvectl reset-statistics
Monitor DNS queries in real-time (debugging)
resolvectl monitor

What it does behind the scenes:

systemd-resolved manages /etc/resolv.conf (usually as a symlink to /run/systemd/resolve/stub-resolv.conf)
Provides local DNS caching
Handles per-interface DNS settings
Supports DNSSEC validation
Integrates with systemd-networkd and NetworkManager
Provides DNS-over-TLS support

DNS problems are among the most common networking issues. resolvectl gives you visibility into exactly how DNS resolution is working on your system. Instead of editing a file that might get overwritten, you work with the actual resolver that's handling your queries. The caching, statistics, and per-interface DNS settings make troubleshooting much easier.
Common troubleshooting workflow:

Check current configuration
resolvectl status
Test a query
resolvectl query problematic-host.example.com
Flush cache if needed
resolvectl flush-caches
Try again
resolvectl query problematic-host.example.com

One note: On some systems you might still see the older systemd-resolve command. This has been replaced by resolvectl, though some distros maintain compatibility symlinks. Use resolvectl for the current syntax.

 

[dos2unix]

Out of time for tonight, but more coming...

timedatectl - Time/date/timezone management (already did this one)
hostnamectl - Hostname and machine metadata (already did this one)
localectl - Locale and keyboard settings (already did this one)
loginctl - Session management
bootctl - systemd-boot bootloader management
resolvectl - DNS resolver control (replaces older systemd-resolve - already did this one)
coredumpctl - Core dump management
networkctl - Network status (the problem with this one, is it tends to be distro specific) but I might mention it anyway.

Notice I didn't include systemctl,, waaay too big, needs it's own thread, but of lot of those have already been done in other threads as well.

 

[dos2unix]

loginctl - Managing User Sessions the Modern Way


Managing user sessions and logins used to involve checking multiple sources and using different tools depending on what information you needed. Finding out who was logged in, how long they'd been there, and managing their sessions meant piecing together data from various commands.


The old way:


Checking who's logged in:

whowlastlast usernamelastb

The who command shows current users, w gives more detail with idle time, last shows login history, and lastb shows failed login attempts.


Finding user processes:

ps aux | grep usernamepkill -u usernamekillall -u username

List processes for a user with ps, kill all their processes with pkill, or use the heavy-handed killall approach.


Managing terminals:

write username tty1wall "System going down for maintenance"pkill -9 -t pts/1

Write to another user's terminal, broadcast to all users, or kick a user off by killing their TTY.


You had to combine multiple tools to get a complete picture, and managing sessions meant finding the right processes and terminals to target.


The new way:


Check current sessions:

loginctl

This shows all active sessions with session ID, user, seat, and TTY in one clean view.


Detailed session information:

loginctl show-session 1

Shows everything about a session - user, state, type, service, remote host, timestamps, and more.


Check specific user sessions:

loginctl list-sessionsloginctl user-status usernameloginctl show-user username

Terminate a session:

loginctl terminate-session 1

This cleanly ends the session and all associated processes.


Kill all sessions for a user:

loginctl terminate-user username

Lock or unlock a session:

loginctl lock-session 1loginctl unlock-session 1

Useful for remote administration - lock a user's graphical session without killing it.


Additional useful commands:

loginctl list-usersloginctl list-seatsloginctl seat-status seat0loginctl enable-linger usernameloginctl disable-linger usernameloginctl show-session 1 --property=Stateloginctl show-session 1 --property=IdleSinceHintloginctl activate 1

List all users with sessions, show seat information (physical/virtual consoles), enable or disable lingering so user services persist after logout, show specific session properties, or activate a session to switch to it if local.


What it does behind the scenes is interface with systemd-logind for session management. It tracks sessions, users, and seats (physical console positions), manages user services and scopes, handles session locking and power management, and integrates with polkit for authorization.


Why this matters is that session management is critical for multi-user systems. loginctl gives you fine-grained control over user sessions without having to hunt down process IDs or terminal devices. You can cleanly terminate sessions, enable user services to persist after logout (lingering), and get detailed session state information all through one consistent interface.


Common administrative tasks:

loginctl list-sessionsloginctl show-session 3 | grep Idleloginctl terminate-session 5loginctl enable-linger devuser

See all sessions and who's idle, check if a user has been idle, terminate an inactive SSH session, or allow user services to run after logout (useful for screen/tmux).


Understanding lingering - by default, when a user logs out, all their processes are terminated. Enabling linger for a user means their systemd user instance keeps running, allowing user services (like a personal web server or background job) to persist. This is particularly useful for service accounts or users running long-term background tasks.


Check which users have lingering enabled:

ls /var/lib/systemd/linger/

 

[dos2unix]

coredumpctl - Managing Core Dumps the Modern Way


When applications crash, they can leave behind core dumps - snapshots of memory at the time of the crash. These are invaluable for debugging, but historically they've been scattered around the filesystem, difficult to find, and awkward to manage.


The old way:


Core dumps were typically written to the current working directory of the crashing process, or to a system-wide location if configured.

ulimit -c unlimited./my_crashing_programls -lh core*

Enable core dumps with ulimit, run your program, then hunt for the core file.


Finding core dumps scattered around the system:

find / -name "core." -o -name "core"find /var/crash -type ffind /tmp -name "core."

Examining a core dump:

gdb /path/to/program /path/to/core.12345file core.12345strings core.12345 | less

Load it in gdb, check what it is with file, or grep through it with strings.


Configuring where cores go:

vim /etc/sysctl.conf

Edit kernel.core_pattern to control the naming and location, something cryptic like:

kernel.core_pattern = /var/crash/core.%e.%p.%t

Where %e is executable name, %p is PID, %t is timestamp. You had to remember these format specifiers and hope your pattern didn't conflict with anything.


The new way:


List all core dumps:

coredumpctl

Shows a clean list of all crashes with timestamp, PID, UID, signal, and executable name.


Get detailed info about a specific crash:

coredumpctl info 12345

Replace 12345 with the PID from the list. Shows full details including command line, stack trace excerpt, and core dump location.


List crashes for a specific program:

coredumpctl list /usr/bin/my_program

Show only crashes from a particular executable:

coredumpctl list firefox

Get info on the most recent crash:

coredumpctl info

Without specifying a PID, it shows the most recent crash.


Debug a crash directly:

coredumpctl debug

This automatically launches gdb with the most recent core dump and the correct executable already loaded. No more hunting for paths.


Debug a specific crash:

coredumpctl debug 12345

Extract a core dump to a file:

coredumpctl dump -o myapp.corecoredumpctl dump 12345 -o myapp.core

Save the most recent core dump, or a specific one, to a file for analysis elsewhere.


Additional useful commands:

coredumpctl list --since "2024-01-01"coredumpctl list --until "1 hour ago"coredumpctl list --since yesterdaycoredumpctl info --since "10 minutes ago"coredumpctl dump --reverse

Filter by time, show info for recent crashes, or dump the oldest core instead of newest.


Clean up old core dumps:

coredumpctl vacuum --keep-free=1Gcoredumpctl vacuum --max-use=500M

Free up space by removing old cores until you have 1GB free, or limit total storage to 500MB.


What it does behind the scenes is collect core dumps via systemd-coredump, store them in a structured journal format in /var/lib/systemd/coredump/, compress them automatically to save space, and maintain metadata in the systemd journal for easy querying.


Why this matters is that debugging crashes becomes much easier when you can actually find the core dumps. coredumpctl gives you a central place to see all crashes, filter by time or program, and automatically launch the debugger with everything properly configured. No more wondering where that core file went or whether core dumps are even enabled.


Common debugging workflow:

coredumpctl listcoredumpctl infocoredumpctl debug

See what's crashed recently, get details on the most recent crash, then jump straight into gdb to investigate.


Configuration note - core dump collection is configured in /etc/systemd/coredump.conf where you can set storage limits, compression, and other options. But the defaults are usually sensible - compress cores, store up to 10% of disk space or 2GB, whichever is less.


Check storage usage:

du -sh /var/lib/systemd/coredump/journalctl --disk-usage

 

[dos2unix]

bootctl - Managing systemd-boot the Modern Way


Note: bootctl is primarily used on systems running systemd-boot as their bootloader. This is common on Fedora, newer RHEL systems, and some Arch-based distributions. Debian, Ubuntu, and their derivatives typically use GRUB instead, so bootctl may not be present on those systems. If you're on a Debian-based system and don't have bootctl, you're probably using GRUB and don't need it.


Managing bootloaders used to mean editing configuration files, running update commands, and hoping you didn't render your system unbootable. GRUB configuration in particular has always been complex, with generated files you're not supposed to edit directly.


The old way with GRUB:


Installing or updating GRUB:

grub2-install /dev/sdagrub2-mkconfig -o /boot/grub2/grub.cfg

Or on older systems:

grub-install /dev/sdaupdate-grub

Setting the default boot entry:

vim /etc/default/grub

Edit GRUB_DEFAULT, then regenerate the config:

grub2-mkconfig -o /boot/grub2/grub.cfg

Viewing boot entries meant parsing the generated grub.cfg file, which is not meant for human consumption:

less /boot/grub2/grub.cfg

The file is auto-generated with warnings not to edit it directly, making customization awkward.


The new way with systemd-boot:


Check bootloader status:

bootctl status

Shows firmware type (UEFI/BIOS), boot loader version, ESP location, default boot entry, and more in a clean, readable format.


List boot entries:

bootctl list

Shows all available boot options with their titles, IDs, and whether they're the default.


Install or update systemd-boot:

bootctl installbootctl update

Install systemd-boot to the ESP (EFI System Partition) or update it to the latest version.


Set the default boot entry:

bootctl set-default entry-id

Or set it to boot once to a specific entry, then revert to default:

bootctl set-oneshot entry-id

Useful for testing a new kernel - boot it once, and if something goes wrong, the next reboot uses the default.


Additional useful commands:

bootctl is-installedbootctl random-seedbootctl systemd-efi-options

Check if systemd-boot is installed, manage the random seed for early boot entropy, or view EFI-specific systemd options.


Managing boot entries with systemd-boot is simpler than GRUB. Boot entries are just text files in /boot/loader/entries/ with a straightforward format:

cat /boot/loader/entries/fedora.conf

Might show something like:

title   Fedora Linuxlinux   /vmlinuz-6.5.0initrd  /initramfs-6.5.0.imgoptions root=UUID=xxxxx ro quiet

Human-readable and editable, unlike GRUB's generated configuration.


What it does behind the scenes is manage systemd-boot, a simple UEFI boot manager. It doesn't need complex configuration generation because boot entries are simple .conf files. It integrates with the systemd ecosystem, supports secure boot, and provides automatic discovery of boot entries.


Why this matters is that systemd-boot is significantly simpler than GRUB. If you're on a UEFI system and don't need GRUB's advanced features (like BIOS support, network booting, or complex scripting), systemd-boot provides a cleaner, more maintainable alternative. bootctl makes managing it straightforward.


Common tasks:

bootctl statusbootctl listbootctl update

Check your boot configuration, see available entries, and keep the bootloader updated.


Testing a new kernel safely:

bootctl set-oneshot new-kernel-entryreboot

Boot the new kernel once. If it works, make it default. If it fails, the system will boot the previous default next time.


Important caveat: systemd-boot only works on UEFI systems. If you're on legacy BIOS, you're stuck with GRUB or another traditional bootloader. Also, if you're dual-booting with Windows or need advanced boot features, GRUB might still be your better choice.

 

[dos2unix]

networkctl - Managing systemd-networkd the Modern Way

Note: networkctl is the companion tool for systemd-networkd, which is common on Debian, Ubuntu (especially server/cloud editions), and some minimal distributions. RHEL, Fedora, and their derivatives typically use NetworkManager instead, so networkctl may not be present or useful on those systems. If you're managing a traditional RHEL/Fedora server, you're probably better off sticking with nmcli.

Network management traditionally meant using various tools depending on what you needed to check - ifconfig for interfaces, route for routing tables, ethtool for link status, and so on. Each tool had its own output format and quirks.

The old way:

Checking interface status:

ifconfigip addr show
ip link show

Show all interfaces, their addresses, and link status.

Checking routes:

route -n
ip route show
netstat -rn

Display routing tables with different commands depending on what you had installed.

Bringing interfaces up or down:

ifconfig eth0 up
ifconfig eth0 down
ip link set eth0 up
ip link set eth0 down

Checking link status and speed:

ethtool eth0
mii-tool eth0

See physical link state, speed, duplex settings.

You had to remember different commands for different information, and the output formats varied widely.

The new way with systemd-networkd:

List all network interfaces:

networkctl

Shows a clean summary of all interfaces with their index, name, type, operational state, and setup state.

Detailed status of all interfaces:

networkctl status

Shows comprehensive information including addresses, routes, DNS servers, and gateway for all interfaces.

Status of a specific interface:

networkctl status eth0

Detailed view of one interface - link state, addresses, routes, DNS, and more.

Reload network configuration:

networkctl reload

Reloads .network files from /etc/systemd/network/ without restarting the service.

Reconfigure a specific interface:

networkctl reconfigure eth0

Reapplies configuration to one interface, useful after editing its .network file.


Additional useful commands:

networkctl list
networkctl lldp
networkctl label

List interfaces in different formats, show LLDP neighbor information if available, or display address labels.

What it does behind the scenes is query systemd-networkd for network state information. It reads configuration from /etc/systemd/network/*.network files, manages link configuration, handles DHCP clients, and integrates with systemd-resolved for DNS.

Why this matters is mainly relevant if you're actually using systemd-networkd instead of NetworkManager. On Ubuntu Server cloud instances, minimal container hosts, or embedded systems, networkctl provides a unified way to check network status without juggling multiple legacy tools. The output is consistent and easy to parse.

Common troubleshooting workflow:

networkctl
networkctl status eth0
journalctl -u systemd-networkd

See which interfaces are up, get details on a specific one, and check the systemd-networkd logs if something isn't working.

The reality for most RHEL/Fedora admins is that nmcli does everything you need and more. networkctl is simpler but less feature-rich. You'll mainly encounter it when working with:

Ubuntu Server instances in the cloud, minimal distributions like CoreOS or Flatcar, container hosts where NetworkManager would be overkill, or systems where someone explicitly chose systemd-networkd for its simplicity.

If you're on a system with NetworkManager:

nmcli device status
nmcli connection show

Does the same job and gives you way more control. Stick with what works.

 

[GatorsFan]

That is great info if you use systemd, but is useless for sysvinit

 

[wendy-lebaron]

Post in thread 'More systemd tools'

Jan 31, 2026

timedatectl - Managing Time, Date, and Timezones the Modern Way
Managing system time used to involve multiple tools and commands depending on what you needed to change. Hardware clock, system clock, timezones, NTP - each had its own approach and potential pitfalls.
The old way:
Setting the date and time:

Set system time
date --set="2024-01-15 14:30:00"
Sync to hardware clock
hwclock --systohc
Or set hardware clock directly
hwclock --set --date="2024-01-15 14:30:00"
hwclock --hctosys

Changing timezones:

Copy or symlink the timezone file
cp /usr/share/zoneinfo/America/Los_Angeles...

• dos2unix

• 

thank you for this bit of information about setting the time.

i found a "bash script line" to do it but i don't like it. however i've had to use it. while i was on debian "bookworm" with mate desktop. because for some reason. the system settings for setting the time. was completely shut out from me. the "ntp" program didn't work.