Systemd generates mount units for the filesystems listed in fstab. Maybe check those with systemctl status? (Like `systemctl status -- -.mount` for my root partition)
Sadly no. The problem is that the entire local-fs.target is stopped 'cleanly' but with no clear reason. i.e.
$ systemctl status local-fs.target
Active: inactive (dead) since [...]
21:12:56 ... systemd[1]: Reached target Local File Systems.
21:12:57 ... systemd[1]: Stopped target Local File Systems.
Yes, the log just shows it stopping one second after being started, nothing happening inbetween, and no reason given for it being stopped.
Incredibly enough, local-fs.target is a dependency for graphical.target, so the system should not have continued booting. But not only it has continued booting, systemd even thinks that it finished booting all-OK. State is "running" (not "degraded" as it would be if any service/mount failed), with 0 failed services. Even though both graphical.target and local-fs.target are 'dead'.
It is at least built in a logical way and once you understand that logic then related commands will be discoverable.
`systemctl` is the systemd command line tool for inspecting and manipulating services/units.
`systemctl status` is the command for showing the status of a service or unit.
The `--` part is not specific to systemd at all, it's used in many commands to separate flags from positional arguments. This lets you use positional arguments that might happen to start with a dash without them being interpreted as flags. [1].
systemd manages mounts, they're named according to the mount point, with a transformation to turn it into a filename (mostly converting slashes to dashes, plus a .mount suffix). Hence, the root mount ('/') is named '-.mount'.
The annoying part is that now that '-' stands for '/', you need to use '\x2d' for '-'. Which is pretty annoying when manipulating mount names during the shell.
I wish they had picked ':' for '/' instead of '-'. That one would be pretty uncommon to find in a mount path, and has a bit of precedent on OSX.
(Who would ever mount anything on a path with a colon anyway? That would be as silly as using slashes instead of dashes for options)
Fair. I think it's because systemd lets you use slashes in unit names, but you can't represent those as files so you have to use a dash instead. This is the worst for the root filesystem mounted at / since that's the entire name. In systemd's defense, it warns you when you try systemctl status the normal way.
Hint: to specify units starting with a dash, use "--":
systemctl [OPTIONS...] COMMAND -- -.mount ...
I found my mount names by running systemctl list-units, so it's not something I had to look up.
You can use systemd-escape(1) to have it generate the correct unit name for you, e.g.:
systemctl status $(systemd-escape --path /home --suffix mount)
Yeah, complicated and verbose, but reliable and integrates into systemd mindset very well.
That to me reads as "show me the status of all files ending in .mount in the current directory". Once you start hijacking shell metacharacters you're on dodgy ground.
> Where *.js isn't using the shell glob feature, it's just a regex compatible string.
Except it isn't, because a `*` at the start of a regex is invalid. `-name` patterns given to `find` are explicitly shell glob patterns. You might be thinking of `-regex` patterns, which GNU find also has.
It's a bit shonky when `find` does it because it's not saying "the shell pattern applies in this directory", and I regularly trip over it. It's something special you've got to know about how `find` works, but at least it's still anchored to the idea of being searched in a path that's also part of the command. There's a semantic link there.
With `systemctl status *.mount` you've not even got that. What path is being searched for `*.mount` files? Is that path part of the `systemctl` interface? Or is this just another way that `systemctl` insists on being a special snowflake that someone's decided I now need to devote neurons to?
Incredibly enough, local-fs.target is a dependency for graphical.target, so the system should not have continued booting. But not only it has continued booting, systemd even thinks that it finished booting all-OK. State is "running" (not "degraded" as it would be if any service/mount failed), with 0 failed services. Even though both graphical.target and local-fs.target are 'dead'.