Bug 1285492 - systemctl can't read symlinks to SysVinit service scripts in /etc/init.d after upgrading to RHEL 7.2's systemd-219-19.el7
Summary: systemctl can't read symlinks to SysVinit service scripts in /etc/init.d afte...
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: systemd
Version: 7.2
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: rc
: ---
Assignee: systemd-maint
QA Contact: Branislav Blaškovič
URL:
Whiteboard:
Keywords: EasyFix, ZStream
: 1303813 (view as bug list)
Depends On:
Blocks: 1203710 1289485 1201326 1288005
TreeView+ depends on / blocked
 
Reported: 2015-11-25 18:03 UTC by Ryan Sawhill
Modified: 2018-06-01 08:45 UTC (History)
31 users (show)

(edit)
Clone Of:
: 1288005 (view as bug list)
(edit)
Last Closed: 2016-11-04 00:46:36 UTC


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2016:2216 normal SHIPPED_LIVE systemd bug fix and enhancement update 2016-11-03 13:24:51 UTC
Red Hat Knowledge Base (Solution) 2067013 None None None 2015-12-18 10:05 UTC

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


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