Bug 1285492

Summary: systemctl can't read symlinks to SysVinit service scripts in /etc/init.d after upgrading to RHEL 7.2's systemd-219-19.el7
Product: Red Hat Enterprise Linux 7 Reporter: Ryan Sawhill <rsawhill>
Component: systemdAssignee: systemd-maint
Status: CLOSED ERRATA QA Contact: Branislav Blaškovič <bblaskov>
Severity: high Docs Contact:
Priority: high    
Version: 7.2CC: abeausol, adrian.fischli, bblaskov, fj-lsoft-kernel-it, hebron, jkurik, john.lofgren, jscotka, kashyap.desai, lauri.cerneck, lnykryn, lupinix.fedora, mcamen, moagrawa, mschena, pdwyer, pragshar, rainer.peter+redhat, redhat-bugzilla, rsawhill, santony, sathya.prakash, sreekanth.reddy, sreekanth.reddy, suganath-prabu.subramani, sumit.saxena, sumit.saxena, systemd-maint-list, troels, vanhoof, wangsy30
Target Milestone: rcKeywords: EasyFix, ZStream
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: systemd-219-20.el7 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1288005 (view as bug list) Environment:
Last Closed: 2016-11-04 00:46:36 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:
Bug Depends On:    
Bug Blocks: 1201326, 1203710, 1288005, 1289485    

Description Ryan Sawhill 2015-11-25 18:03:43 UTC
Description of problem:

  The rebase of systemd in RHEL 7.2 seems to have broken something with SysVinit compatibility. As the summary suggests, if a service script resides directly in /etc/init.d, all is well; however, if /etc/init.d/<SERVICE> is a symlink, all systemctl/service commands fail with: "Unit <SERVICE>.service failed to load: No such file or directory."

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

  systemd-219-19.el7

How reproducible:

  100%

Steps to Reproduce:

  1. Create a simple test sysv script somewhere on the rootfs
     e.g.:
       cd /etc; curl -O http://people.redhat.com/rsawhill/foo; chmod +x foo

  2. Create a symlink in /etc/init.d to the new service script
     e.g.:
       ln -sv /etc/foo /etc/init.d/foo

  3. Add the service:
       chkconfig --add foo

  4. Confirm it works with manual calls:
       /etc/init.d/foo start; /etc/init.d/foo status

  5. Use systemctl to test:
       service foo status; service foo restart
       systemctl status foo; systemctl restart foo

Actual results in RHEL 7.2:

  ~~~
  [root@z72 etc]# service foo status; service foo restart; systemctl status foo; systemctl restart foo
  ● foo.service
     Loaded: not-found (Reason: No such file or directory)
     Active: inactive (dead)
  Reloading systemd:                                         [  OK  ]
  Restarting foo (via systemctl):  Failed to restart foo.service: Unit foo.service failed to load: No such file or directory.
                                                             [FAILED]
  ● foo.service
     Loaded: not-found (Reason: No such file or directory)
     Active: inactive (dead)
  Failed to restart foo.service: Unit foo.service failed to load: No such file or directory.

  [root@z72 etc]# rpm -qa systemd\*
  systemd-libs-219-19.el7.x86_64
  systemd-219-19.el7.x86_64
  systemd-sysv-219-19.el7.x86_64
  ~~~

Expected results (run on a stock RHEL 7.1 machine -- installed from DVD without any updates):

  ~~~
  [root@z71 etc]# service foo status; service foo restart; systemctl status foo; systemctl restart foo
  foo.service - SYSV: This is the awesome foo.
     Loaded: loaded (/etc/rc.d/init.d/foo)
     Active: active (running) since Wed 2015-11-25 12:50:38 EST; 33s ago
    Process: 2246 ExecStart=/etc/rc.d/init.d/foo start (code=exited, status=0/SUCCESS)
     CGroup: /system.slice/foo.service
             └─2249 sleep 99d

  Nov 25 12:50:38 z71.example.com systemd[1]: Starting SYSV: This is the awesome foo....
  Nov 25 12:50:38 z71.example.com foo[2246]: [31B blob data]
  Nov 25 12:50:38 z71.example.com systemd[1]: Started SYSV: This is the awesome foo..
  Restarting foo (via systemctl):                            [  OK  ]
  foo.service - SYSV: This is the awesome foo.
     Loaded: loaded (/etc/rc.d/init.d/foo)
     Active: active (running) since Wed 2015-11-25 12:51:12 EST; 4ms ago
    Process: 2289 ExecStop=/etc/rc.d/init.d/foo stop (code=exited, status=0/SUCCESS)
    Process: 2293 ExecStart=/etc/rc.d/init.d/foo start (code=exited, status=0/SUCCESS)
     CGroup: /system.slice/foo.service
             └─2297 sleep 99d

  Nov 25 12:51:12 z71.example.com systemd[1]: Starting SYSV: This is the awesome foo....
  Nov 25 12:51:12 z71.example.com foo[2293]: [31B blob data]
  Nov 25 12:51:12 z71.example.com systemd[1]: Started SYSV: This is the awesome foo..

  [root@z71 etc]# rpm -qa systemd\*
  systemd-libs-208-20.el7.x86_64
  systemd-208-20.el7.x86_64
  systemd-sysv-208-20.el7.x86_64
  ~~~

Additional info:

  Please don't confuse this with unrelated Bug 1212569 - systemd does not start sysvinit service if using symlink to mounted filesystem.

Comment 7 Troels Arvin 2016-02-16 10:58:46 UTC
In the errata description at https://rhn.redhat.com/errata/RHBA-2016-0199.html it states:

  "Note that the real location of the init script must be on the partition that is mounted in the initial ramdisk (initrd)"

What does that mean?

If /usr/local/foo is a normal (non-NFS, non-automounted) directory mounted at boot-time via fstab: Will a symlink to a script in that directory be expected to work, given the fixed systemd package in RHBA-2016:0199-1?

Comment 8 Sirius Rayner-Karlsson 2016-02-16 11:31:36 UTC
(In reply to Troels Arvin from comment #7)
> In the errata description at
> https://rhn.redhat.com/errata/RHBA-2016-0199.html it states:
> 
>   "Note that the real location of the init script must be on the partition
> that is mounted in the initial ramdisk (initrd)"
> 
> What does that mean?
> 
> If /usr/local/foo is a normal (non-NFS, non-automounted) directory mounted
> at boot-time via fstab: Will a symlink to a script in that directory be
> expected to work, given the fixed systemd package in RHBA-2016:0199-1?

Bugzilla is not a support tool, so the question is better routed through your support agreement and via the Customer Portal (https://access.redhat.com).

However, the way I understand things, if the filesystem that holds the actual script the symbolical link in /etc/rc.d/init.d points at is not available by the time systemd processes the init files - it will not get run by systemd (as the symlink points at something currently non-existent). 

In other words - make sure that the filesystem(s) that hold your init-scripts are present and mounted by the time systemd begins its processing of init-scripts if you are going to use symbolical links.

/Anders

Comment 9 Ryan Sawhill 2016-02-16 18:19:50 UTC
(In reply to Troels Arvin from comment #7)
> In the errata description at
> https://rhn.redhat.com/errata/RHBA-2016-0199.html it states:
> 
>   "Note that the real location of the init script must be on the partition
> that is mounted in the initial ramdisk (initrd)"
> 
> What does that mean?
> 
> If /usr/local/foo is a normal (non-NFS, non-automounted) directory mounted
> at boot-time via fstab: Will a symlink to a script in that directory be
> expected to work, given the fixed systemd package in RHBA-2016:0199-1?

Anders answered you correctly. This is basically just reiterating the requirement explained in https://bugzilla.redhat.com/show_bug.cgi?id=1212569 -- that after this fix symlinks will be OK again as long as they're pointing to files in / or /usr.

Comment 11 Lukáš Nykrýn 2016-05-05 12:15:37 UTC
*** Bug 1303813 has been marked as a duplicate of this bug. ***

Comment 14 errata-xmlrpc 2016-11-04 00:46:36 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2016-2216.html