RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
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...
Keywords:
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:
: 1303813 (view as bug list)
Depends On:
Blocks: 1201326 1203710 1288005 1289485
TreeView+ depends on / blocked
 
Reported: 2015-11-25 18:03 UTC by Ryan Sawhill
Modified: 2020-09-10 09:29 UTC (History)
31 users (show)

Fixed In Version: systemd-219-20.el7
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1288005 (view as bug list)
Environment:
Last Closed: 2016-11-04 00:46:36 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 2067013 0 None None None 2015-12-18 10:05:08 UTC
Red Hat Product Errata RHBA-2016:2216 0 normal SHIPPED_LIVE systemd bug fix and enhancement update 2016-11-03 13:24:51 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.