4 ms·

Systemd generates mount units for the filesystems listed in fstab. Maybe check those with systemctl status? (Like `systemctl status -- -.mount` for my root part

Systemd generates mount units for the filesystems listed in fstab. Maybe check those with systemctl status? (Like `systemctl status -- -.mount` for my root partition)

dijit 5y ago
Candidly: that command looks like the least discoverable command I’ve seen in the last year.
- heavyset_go 5y ago
  The command systemctl status *.mount Just shows the status of all mount units. It's the same command you'd use to check any other systemd unit, for example, if you want to check Docker's status: systemctl status docker.service Seems consistent and discoverable as long as you have a surface understanding of systemd units.
  - regularfry 5y ago
    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.
    - heavyset_go 5y ago
      It's not using the shell glob syntax, it's just a regex compatible string. The find utility does the same thing: find ~/Code -type f -name *.js Where *.js isn't using the shell glob feature, it's just a regex compatible string. You could put quotes around it to make it clearer: systemctl status "*.mount" The string is matching on unit names, and the mount units have the .mount suffix.
      - regularfry 5y ago
        > 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?
- teddyfrozevelt 5y ago
  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.
  - ephaeton 5y ago
    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.
- azornathogron 5y ago
  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'. [1] See, e.g., https://unix.stackexchange.com/questions/11376/what-does-double-dash-mean https://unix.stackexchange.com/questions/11376/what-does-dou...
  - unilynx 5y ago
    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)
    - salawat 5y ago
      C:\ much?
      - unilynx 5y ago
        I’m pretty sure whoever came up with that was also using slashes for options. Someone was gonna bite :)
    - isodude 5y ago
      Have you seen system-escape? https://www.freedesktop.org/software/systemd/man/systemd-escape.html https://www.freedesktop.org/software/systemd/man/systemd-esc...
- teddyh 5y ago
  Would systemctl status -- $(systemd-escape --suffix=mount --path /) be simpler to read?
heavyset_go 5y ago
If you use a wildcard operator, you can list all the mount statuses: systemctl status *.mount
AshamedCaptain 5y ago
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'.

Systemd generates mount units for the filesystems listed in fstab. Maybe check those with systemctl status? (Like `systemctl status -- -.mount` for my root partition)

dijit 5y ago

Candidly: that command looks like the least discoverable command I’ve seen in the last year.

heavyset_go 5y ago
The command systemctl status *.mount Just shows the status of all mount units. It's the same command you'd use to check any other systemd unit, for example, if you want to check Docker's status: systemctl status docker.service Seems consistent and discoverable as long as you have a surface understanding of systemd units.
- regularfry 5y ago
  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.
  - heavyset_go 5y ago
    It's not using the shell glob syntax, it's just a regex compatible string. The find utility does the same thing: find ~/Code -type f -name *.js Where *.js isn't using the shell glob feature, it's just a regex compatible string. You could put quotes around it to make it clearer: systemctl status "*.mount" The string is matching on unit names, and the mount units have the .mount suffix.
    - regularfry 5y ago
      > 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?
teddyfrozevelt 5y ago
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.
- ephaeton 5y ago
  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.
azornathogron 5y ago
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'. [1] See, e.g., https://unix.stackexchange.com/questions/11376/what-does-double-dash-mean https://unix.stackexchange.com/questions/11376/what-does-dou...
- unilynx 5y ago
  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)
  - salawat 5y ago
    C:\ much?
    - unilynx 5y ago
      I’m pretty sure whoever came up with that was also using slashes for options. Someone was gonna bite :)
  - isodude 5y ago
    Have you seen system-escape? https://www.freedesktop.org/software/systemd/man/systemd-escape.html https://www.freedesktop.org/software/systemd/man/systemd-esc...
teddyh 5y ago
Would systemctl status -- $(systemd-escape --suffix=mount --path /) be simpler to read?

heavyset_go 5y ago

If you use a wildcard operator, you can list all the mount statuses: systemctl status *.mount

AshamedCaptain 5y ago

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'.