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.