Bug 842060 - RFE: systemctl mask of an otherwise non-existent unit should print a warning, still succeed
RFE: systemctl mask of an otherwise non-existent unit should print a warning,...
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: systemd (Show other bugs)
rawhide
x86_64 Linux
unspecified Severity low
: ---
: ---
Assigned To: Michal Sekletar
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-07-21 10:17 EDT by Reartes Guillermo
Modified: 2016-07-26 20:19 EDT (History)
12 users (show)

See Also:
Fixed In Version: systemd-231-1.fc25.x86_64
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-07-26 20:19:53 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Reartes Guillermo 2012-07-21 10:17:32 EDT
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.
Comment 1 Michal Sekletar 2012-07-30 10:38:39 EDT
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.
Comment 2 Michal Schmidt 2012-07-30 10:54:24 EDT
(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.
Comment 3 Reartes Guillermo 2013-01-20 17:51:16 EST
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.
Comment 4 Michal Sekletar 2013-01-21 07:35:54 EST
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
Comment 5 Jóhann B. Guðmundsson 2013-06-15 12:24:41 EDT
Michal what's the current status on this issue?
Comment 6 Michal Sekletar 2013-06-29 17:48:32 EDT
I am currently looking into this. Expect couple patches dealing with masking to land upstream very soon.
Comment 7 Reartes Guillermo 2014-04-15 04:42:14 EDT
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.
Comment 8 Reartes Guillermo 2014-04-15 04:44:13 EDT
@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.
Comment 9 Lennart Poettering 2014-06-19 19:16:00 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.