Description of problem: darkcode.service (which does not exists) can be masked. While masked, it is more likely to appear as a 'valid/real' service and generate confusion. Version-Release number of selected component (if applicable): Fedora 17 x86_64 (3.4.5-2.fc17.x86_64) systemd.x86_64 44-17.fc17 @updates systemd-analyze.x86_64 44-17.fc17 @updates systemd-sysv.x86_64 44-17.fc17 @updates How reproducible: always Steps to Reproduce: 1. systemctl mask darkcode.service Actual results: I masked a fantasy .service: I was surprised it let me do it. Now the darkcode.service is 'something' to systemd... # systemctl mask darkcode.service ln -s '/dev/null' '/etc/systemd/system/darkcode.service' That is strange, why can something that do not exist be unable to be started because it is masked? # systemctl start darkcode.service Failed to issue method call: Unit darkcode.service is masked. The same as above: # systemctl restart darkcode.service Failed to issue method call: Unit darkcode.service is masked. What does it mean, it stopped it ok??? How!!! # systemctl stop darkcode.service That is strange, why can something that do not exist be unable to be started because it is masked? # systemctl start darkcode.service Failed to issue method call: Unit darkcode.service is masked. Let's see what does it when unmasked: # systemctl unmask darkcode.service rm '/etc/systemd/system/darkcode.service' Ok, it does not exists. So the issue happens only when me mask something that does not exists. # systemctl start darkcode.service Failed to issue method call: Unit darkcode.service failed to load: No such file or directory. See system logs and 'systemctl status darkcode.service' for details. # systemctl status darkcode.service darkcode.service Loaded: error (Reason: No such file or directory) Active: inactive (dead) Let's do it again: # systemctl mask darkcode.service ln -s '/dev/null' '/etc/systemd/system/darkcode.service' And ??? what does it mean ??? it is a masked service? # systemctl status darkcode.service darkcode.service Loaded: masked (/dev/null) Active: inactive (dead) # systemctl start darkcode.service Failed to issue method call: Unit darkcode.service is masked. And whops, that when one might be confused, it is listed as 'something' that is masked. # systemctl -a | grep darkcode.service darkcode.service masked inactive dead darkcode.service It feels that systemctl needs some adustments in the masking of services. Expected results: one should not be able to mask something that does not exists.
systemctl now, i.e. F18, prints error message when you want to stop non-existing unit. However, administrator might want to have ability to mask non-existing unit in same cases, but we should print warning message, because in most cases this is not what he wants and it is probably typo in the name of unit. I will elaborate on this and prepare patch.
(In reply to comment #1) > However, administrator might want to have ability to mask > non-existing unit in same cases Yes. A possible use-case is wanting to mask a unit preemptively before installing a package that ships it. > but we should print warning message, > because in most cases this is not what he wants and it is probably typo in > the name of unit. I will elaborate on this and prepare patch. Indeed. The possibility of a typo is likely, so a warning makes sense. Thanks.
I repeated the test with F18: # hostnamectl Static hostname: fntstx3localdomain Pretty hostname: fntstx3.localdomain Icon name: computer-vm Chassis: vm Machine ID: 6edd621a3d9752943a01ca74f153f539 Boot ID: 940b37d74f4d4c0d8aed43e68e7722e1 Virtualization: kvm Operating System: Fedora 18 (Spherical Cow) CPE OS Name: cpe:/o:fedoraproject:fedora:18 Kernel: Linux 3.7.2-201.fc18.x86_64 Architecture: x86_64 # systemctl mask darkcode.service ln -s '/dev/null' '/etc/systemd/system/darkcode.service' # systemctl start darkcode.service Failed to issue method call: Unit darkcode.service is masked. # systemctl restart darkcode.service Failed to issue method call: Unit darkcode.service is masked. >> Acording to Comment #1, this should print an error but it does not. # systemctl stop darkcode.service # systemctl start darkcode.service Failed to issue method call: Unit darkcode.service is masked. # systemctl list-unit-files |grep -i darkcode darkcode.service masked # systemctl unmask darkcode.service rm '/etc/systemd/system/darkcode.service' # systemctl start darkcode.service Failed to issue method call: Unit darkcode.service failed to load: No such file or directory. See system logs and 'systemctl status darkcode.service' for details. # systemctl status darkcode.service darkcode.service Loaded: error (Reason: No such file or directory) Active: inactive (dead) Jan 20 19:37:53 fntstx3localdomain systemd[1]: Stopped darkcode.service. # systemctl mask darkcode.service ln -s '/dev/null' '/etc/systemd/system/darkcode.service' # systemctl status darkcode.service darkcode.service Loaded: masked (/dev/null) Active: inactive (dead) Jan 20 19:37:53 fntstx3localdomain systemd[1]: Stopped darkcode.service. # systemctl start darkcode.service Failed to issue method call: Unit darkcode.service is masked. # systemctl -a | grep darkcode.service # systemctl list-unit-files |grep -i darkcode darkcode.service masked No changes. Regarding both Comment #1 and #2 about the "[...] administrator might want to have ability to mask non-existing unit in same cases [...]": For such an usage, a '--force' or similar parameter would make sense. It will still permit to do it, but it will not do it by default. Maybe the version should be changed to F18.
I should clarify that patch I wrote, has never been sent upstream. I will try to explain my concerns I've had at the time. When masking is requested, systemd will always mask the unit file, even it doesn't exist. Changes made in filesystem are sent back to systemctl which informs user about what happened. We have couple options how to detect masking of non-existing unit file. Either we will change dbus interface of pid 1, such that it will send additional information about presence of unit file in a filesystem, or systemctl will check existence of unit file by itself. TBH I wasn't sure what is better solution here, thus I've never sent patch upstream. I will ask around and finish it so we can finally resolve this issue. Michal
Michal what's the current status on this issue?
I am currently looking into this. Expect couple patches dealing with masking to land upstream very soon.
I tested this again with F20: # hostnamectl Static hostname: stark.espada Icon name: computer-desktop Chassis: desktop Machine ID: e837339228d144d7978eae4231db458b Boot ID: be2eda7a815648ffb9572b292e416435 Operating System: Fedora 20 (Heisenbug) CPE OS Name: cpe:/o:fedoraproject:fedora:20 Kernel: Linux 3.13.9-200.fc20.x86_64 Architecture: x86_64 # systemctl mask darkcode.service ln -s '/dev/null' '/etc/systemd/system/darkcode.service' # systemctl start darkcode.service Failed to issue method call: Unit darkcode.service is masked. # systemctl restart darkcode.service Failed to issue method call: Unit darkcode.service is masked. >> Acording to Comment #1, this should print an error but it does not. # systemctl stop darkcode.service # systemctl start darkcode.service Failed to issue method call: Unit darkcode.service is masked. # systemctl unmask darkcode.service rm '/etc/systemd/system/darkcode.service' # systemctl start darkcode.service Failed to issue method call: Unit darkcode.service failed to load: No such file or directory. # systemctl status darkcode.service darkcode.service Loaded: not-found (Reason: No such file or directory) Active: inactive (dead) Apr 15 05:14:10 stark.espada systemd[1]: Stopped darkcode.service. # systemctl mask darkcode.service ln -s '/dev/null' '/etc/systemd/system/darkcode.service' # systemctl status darkcode.service darkcode.service Loaded: masked (/dev/null) Active: inactive (dead) Apr 15 05:14:10 stark.espada systemd[1]: Stopped darkcode.service. # systemctl start darkcode.service Failed to issue method call: Unit darkcode.service is masked. # systemctl -a | grep -i darkcode.service # systemctl list-units | grep -i darkcode # systemctl list-units -a --full | grep -i darkcode.service Ok, now the output of this changed. This was the previous output: > # systemctl -a | grep darkcode.service > darkcode.service masked inactive dead darkcode.service That was the original reason i opened the bugreport.
@Michal Can you confirm that the patch landed on the version of systemd specified above? systemd.x86_64 208-16.fc20 @updates systemd-libs.x86_64 208-16.fc20 @updates systemd-python.x86_64 208-16.fc20 @updates systemd-python3.x86_64 208-16.fc20 @updates Also can you confirm that this issue is fixed in F20? One issue remain, should i open another bugreport for it? > Systemd will not stop a non existent service (that is ok). # systemctl stop LALALAL Failed to issue method call: Unit LALALAL.service not loaded. > Systemd will stop a non existant service that was masked. # systemctl mask LALALAL ln -s '/dev/null' '/etc/systemd/system/LALALAL.service' # systemctl stop LALALAL So while a non existent masked unit no longer shows up in the output of systemctl list-units, it is still possible to stop a non existent masked unit. (Comment #1). Cheers.
So, we always allow stopping all units, as configuration files might just have gotten lost, but you should still be able to shut down a specific service. Also, if you mask a unit then we will not see the original one, we won't even know it exists, hence masking something previously non-existing and then stopping will do something, and I think that's probably the right thing to do... I mean, again, think of this: you had a service installed and running. Then you remove the unit file, also mask it. Of course you should be able to stop the unit still, after all the process might still be running and you removed the unit file without making sure you stopped it first. However, I think it would be a good idea to print a warning if a unit that was previously not known is masked. That might actually be a good thing to allow, since sometimes you might want to mask something "in advance", i.e. in the case it reappears. However, such a case does deserve a warning printed. Retitling this bug to clarify this.
https://github.com/systemd/systemd/pull/3521/commits/d5986112dd54c24306f7158f9528c70b9c37edf1