This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 866346 - systemd--194: systemctl Unit File commands such as link fail when NAME specified as absolute path
systemd--194: systemctl Unit File commands such as link fail when NAME specif...
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: systemd (Show other bugs)
18
All Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: systemd-maint
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-10-15 02:33 EDT by Judy Wathen
Modified: 2012-12-20 10:01 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-12-20 10:01:29 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Potential patch (635 bytes, patch)
2012-10-15 08:45 EDT, Lukáš Nykrýn
no flags Details | Diff

  None (edit)
Description Judy Wathen 2012-10-15 02:33:01 EDT
Description of problem:

Bug 856975 addressed the failure of systemctl Unit File commands (enable, disable, reenable, etc.) when the "service" suffice was omitted from the NAME argument, specified as a basename, not a full path.  

In systemd-194, the fix to bug846975 is incorporated.  However, there seem to be some new problems when the NAME argument is specified as an absolute path.  The absolute path is required for the link command.  In order to be able to "undo" a link command, the absolute path must be accepted by the disable command as well.

In systemd-194, the following commmands which succeeded on systemd-188 fail:

[root@localhost yum.repos.d]# systemctl \ enable  /usr/lib/systemd/system/cups.service
Failed to issue method call: No such file or directory

[root@localhost yum.repos.d]# systemctl \ disable  /usr/lib/systemd/system/cups.service
Failed to issue method call: No such file or directory

[root@localhost yum.repos.d]# systemctl \   reenable  /usr/lib/systemd/system/cups.service
Failed to issue method call: No such file or directory

[root@localhost yum.repos.d]# systemctl \ link  /usr/lib/systemd/system/cups.service
Failed to issue method call: Invalid argument
[root@localhost yum.repos.d]# systemctl link  /tmp/meow.service
Failed to issue method call: Invalid argument

(In the last example, /tmp/meow.service is a copy of a service file unit, copied to  /tmp to test the "systemctl link" command.  For systemd-188 to succeed, the filename must end with ".service" and the "service" suffix must be included on the command line as part of the absolute path.)

Note, however, that "systemctl mask" and "systemctl unmask" commands failed for _both_ the missing ".service" suffix and the absolute path in systemd-188, and both these cases succeed in systemd-194.

I neglected to test the behavior of "systemctl pretest" on systemd-194.

For reference, the following commands failed in systemd-188 and succeed in systemd-194:

In systemd-188

[root@localhost ~]# systemctl enable cups
Failed to issue method call: Invalid argument
systemctl disable cups
Failed to issue method call: Invalid argument
[root@localhost ~]# systemctl reenable cups
Failed to issue method call: Invalid argument
[root@localhost ~]# systemctl mask cups
Failed to issue method call: Invalid argument
[root@localhost ~]# systemctl mask /usr/lib/systemd/system/cups.service
Failed to issue method call: Invalid argument
[root@localhost ~]# systemctl unmask cups
Failed to issue method call: Invalid argument
[root@localhost ~]# systemctl unmask /usr/lib/systemd/system/cups.service
Failed to issue method call: Invalid argument

My original interest was in investigating these commands in the chrooted environment.  However, after testing systemd-194 on the booted environment, I have not yet setup a clone for testing it in the chrooted environment.  In addition, fixing the cases in the chrooted environment may cause further failures in the booted environment, so the booted environment needs to be addressed first or concurrently.

Side Note: The systemctl "Unit commands" (as defined by "systemctl -h") are probably not expected to accept absolute file paths, as they deal with prcesses rather that paths.  They do appear to accept names with or without the ".service" suffix.  (I haven't tried other suffixes.)  They fail with full paths, which is probably expected, except that the failure message is a little confusing.  Here is a sample:
[root@localhost ~]# systemctl start  /usr/lib/systemd/system/cups.service
Failed to issue method call: Unit usr-lib-systemd-system-cups.service.mount failed to load: No such file or directory. See system logs and 'systemctl status usr-lib-systemd-system-cups.service.mount' for details.
This appears to be because mangle-unit-name appends ".mount" to absolute paths.  However, this is not the subject of this bugzilla.


Version-Release number of selected component (if applicable):

systemd-194

How reproducible:

100%, using cups as a test case.  Rudimentary testing indicates that bluetooth produces the same behavior.

Steps to Reproduce:
1. Install systemd-194 and its dependencies.

2. Run any systemctl "Unit File" command, specifying an absolute path.  The most important cases are 
systemctl link <absolute_path_to_unit_file>
and
systemctl disable <absolute_path_to_unit_file>

3. Record return code and messages.
  
Actual results:

Failures when an absolute path is specified with a systemctl "Unit File" command, which differs from systemd-188.

Expected results:

Success when an absolute path is specified, at least for "systemctl link" and "systemctl disable".

Additional info:

See the desription above.

Chrooted environments still need to be addressed, possibly in a separate bugzilla.
Comment 1 Lukáš Nykrýn 2012-10-15 08:45:05 EDT
Created attachment 627408 [details]
Potential patch

Maybe it would be enough just to not mangle name, when it is a path.
Comment 3 Fedora Update System 2012-10-22 21:04:44 EDT
systemd-195-1.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/systemd-195-1.fc18
Comment 4 Fedora Update System 2012-10-23 02:48:21 EDT
Package systemd-195-1.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing systemd-195-1.fc18'
as soon as you are able to, then reboot.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-16709/systemd-195-1.fc18
then log in and leave karma (feedback).
Comment 5 Fedora Update System 2012-10-26 11:42:59 EDT
systemd-44-21.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/systemd-44-21.fc17
Comment 6 Fedora Update System 2012-10-26 15:37:38 EDT
Package systemd-195-2.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing systemd-195-2.fc18'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-16709/systemd-195-2.fc18
then log in and leave karma (feedback).
Comment 7 Fedora Update System 2012-12-20 10:01:32 EST
systemd-44-21.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.

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