Bug 842060
Summary: | RFE: systemctl mask of an otherwise non-existent unit should print a warning, still succeed | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Reartes Guillermo <rtguille> |
Component: | systemd | Assignee: | Michal Sekletar <msekleta> |
Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | low | Docs Contact: | |
Priority: | unspecified | ||
Version: | rawhide | CC: | johannbg, lnykryn, metherid, mschmidt, msekleta, pahan, plautrba, rvokal, ssahani, systemd-maint, vpavlin, zbyszek |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | systemd-231-1.fc25.x86_64 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2016-07-27 00:19:53 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Reartes Guillermo
2012-07-21 14:17:32 UTC
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. |