Troubleshoot systemd-fsckd Socket Activation and fsck Progress

Boot hangs on a filesystem check with no progress bar in sight. systemd-fsckd is the daemon behind that display, not the thing doing the actual checking.

This guide covers what it does, how to check its socket and service without touching boot configuration, and what evidence to gather when progress goes missing or a check looks stuck. It covers the systemd 255 package installed on this machine. Give it 15 minutes for the read-only checks, longer if you need to reproduce socket activation yourself.

The key boundary is simple: systemd-fsckd is not a replacement for fsck. It receives progress messages from filesystem checks over a private Unix socket and forwards one consolidated stream to the console and to Plymouth when Plymouth is running. It can also handle a cancellation request made through Plymouth.

1. Confirm the installed daemon

Start with unprivileged checks; none of these start a service or touch a unit:

$ command -v systemd-fsckd
$ /usr/lib/systemd/systemd-fsckd --version
systemd 255 (255.4-1ubuntu8.17)
$ /usr/lib/systemd/systemd-fsckd --help
systemd-fsckd [OPTIONS...]

Capture fsck progress and forward one stream to plymouth

The executable normally sits under /usr/lib/systemd/, not necessarily on an admin's PATH. The installed manual documents only --help and --version. Do not go looking for a foreground option, a device argument or a command that launches a check: none exists here.

2. Inspect the socket and service units

Read the installed unit definitions instead of guessing where the endpoint lives:

$ systemctl cat systemd-fsckd.socket systemd-fsckd.service
[Socket]
ListenStream=/run/systemd/fsck.progress
SocketMode=0600

[Service]
ExecStart=/usr/lib/systemd/systemd-fsckd
StandardOutput=journal+console

The socket listens on /run/systemd/fsck.progress at mode 0600, a local, permission-restricted endpoint for the fsck machinery, not a public service interface. The service is wired to that socket and sends its normal output to the journal and console.

On this system, both units are static, so do not try to enable them like an ordinary always-on daemon:

$ systemctl show -p LoadState,ActiveState,SubState,UnitFileState systemd-fsckd.socket
LoadState=loaded
ActiveState=inactive
SubState=dead
UnitFileState=static
$ systemctl show -p LoadState,ActiveState,SubState,UnitFileState systemd-fsckd.service
LoadState=loaded
ActiveState=inactive
SubState=dead
UnitFileState=static

Inactive is not automatically a fault. The daemon is meant to appear when a filesystem check needs it, then go idle and exit after leaving the door open for new fsck connections for a while.

3. Check the current socket state

Ask systemd directly for the socket state and its listening address:

$ systemctl status --no-pager systemd-fsckd.socket
○ systemd-fsckd.socket - fsck to fsckd communication Socket
     Loaded: loaded (.../systemd-fsckd.socket; static)
     Active: inactive (dead)
     Triggers: ● systemd-fsckd.service
     Listen: /run/systemd/fsck.progress (Stream)

When the socket is active, check the endpoint itself:

$ systemctl show -p Listen systemd-fsckd.socket
Listen=/run/systemd/fsck.progress (Stream)
$ stat -c '%A %a %U %G %n' /run/systemd/fsck.progress
srw------- 600 root root /run/systemd/fsck.progress

The exact status layout shifts between systemd versions, but the facts that matter are the loaded unit, the Listen path and the 0600 permission. An absent path while the socket is inactive is expected; do not create that socket file yourself, systemd owns it.

4. Reproduce activation only if you actually need to

To check the unit can start, use the socket unit rather than launching the executable by hand:

$ sudo systemctl start systemd-fsckd.socket
$ systemctl is-active systemd-fsckd.socket
active
$ systemctl status --no-pager systemd-fsckd.socket

This starts the listener; it does not run a filesystem check by itself. It changes live system state, so do this on a maintenance host or a planned diagnostic window, and do not stop the socket while a real boot-time check might be using it.

The daemon normally starts the moment an fsck process connects. There is no safe generic test client documented here, and writing arbitrary bytes to the private socket could interfere with the protocol. Treat an active socket as the meaningful signal; do not poke it with nc, socat, or a hand-written probe.

When you are done with a manually started listener, undo exactly that change:

$ sudo systemctl stop systemd-fsckd.socket
$ systemctl is-active systemd-fsckd.socket
inactive

If another unit or a genuine filesystem check owns the socket, stopping it could interrupt boot work. Leave it running and go after the dependency instead.

5. Read the journal after a failure

Treat the service and socket units as separate evidence sources:

$ journalctl --no-pager -u systemd-fsckd.service -b
$ journalctl --no-pager -u systemd-fsckd.socket -b
$ systemctl status --no-pager systemd-fsckd.service

The -b flag limits the search to the current boot. Diagnosing an earlier boot instead, swap in the right journal boot selector after listing them with journalctl --list-boots. Look for a failed executable, permission errors around the private socket, or a clean exit once checks finished. A service sitting at inactive (dead) after boot is not, by itself, evidence of failure.

If systemd does report a failed state, keep the journal output before clearing anything. systemctl reset-failed systemd-fsckd.service only clears systemd's recorded failure state; it repairs nothing, recreates no missing unit file, and does not touch the underlying cause.

6. Understand cancellation and where the safety line sits

When Plymouth is running, systemd-fsckd asks it to capture Control+C. Pressing it during an active check terminates running checks and puts newly connecting fsck instances into a cancelled state while the daemon stays that way. That is a real operational cancellation, not a harmless way to dismiss a progress screen.