Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
FS#31172 - [systemd] systemctl returns status of nonexistent .device units
Attached to Project:
Arch Linux
Opened by Asher Higgs (alphaniner) - Friday, 17 August 2012, 16:04 GMT
Last edited by Dave Reisner (falconindy) - Saturday, 25 August 2012, 02:42 GMT
Opened by Asher Higgs (alphaniner) - Friday, 17 August 2012, 16:04 GMT
Last edited by Dave Reisner (falconindy) - Saturday, 25 August 2012, 02:42 GMT
|
DetailsDescription:
I mistyped the name of a systemd .device unit in the command 'systemctl status <device unit>'. Nevertheless, systemctl returned that it was loaded. So I tried a completely ridiculous name, and still it returned as loaded: # systemctl status roopeedoopeedoo.device roopeedoopeedoo.device Loaded: loaded Active: inactive (dead) In contrast, running 'systemctl status <nonexistent non-device unit>' returns an error as expected: # systemctl status roopeedoopeedoo.service roopeedoopeedoo.service Loaded: error (Reason: No such file or directory) Active: inactive (dead) Additional info: * package version(s) systemd, systemd-tools, libsystemd ver. 188-2 systemd-arch-units ver. 20120405-2 Also, trying to start or stop a non-existent .device unit seems to succeed: # systemctl stop roopeedoopeedoo.device # echo $? 0 Steps to reproduce: Run 'systemctl status <nonexistent .device unit>'. |
This task depends upon
Closed by Dave Reisner (falconindy)
Saturday, 25 August 2012, 02:42 GMT
Reason for closing: Not a bug
Additional comments about closing: Working as intended.
Saturday, 25 August 2012, 02:42 GMT
Reason for closing: Not a bug
Additional comments about closing: Working as intended.
"stop" isn't a valid verb for devices, but I suspect calling stop on any unit that's already in the non-active state will result in success.