Bug 3900 - systemd fails to start .sh init scripts
Summary: systemd fails to start .sh init scripts
Status: RESOLVED FIXED
Alias: None
Product: OE-Core
Classification: Build System, Metadata & Runtime
Component: core (show other bugs)
Version: 1.4
Hardware: x86 Multiple
: Medium normal
Target Milestone: 1.4.1
Assignee: Radu Moisan
QA Contact:
URL:
Whiteboard:
Depends on:
Blocks:
 
Reported: 2013-02-18 12:10 UTC by Ross Burton
Modified: 2013-05-13 15:04 UTC (History)
7 users (show)

See Also:
OS type for building Yocto: ---
Type of Regression: ---
Verified:
Documentation change: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ross Burton 2013-02-18 12:10:57 UTC
From Holger on the oe-core list:

> I am using the busybox ifplugd to
> configure the network on plug/un-plug of the cable. My start script ended
> with .sh in the name. systemd recognized the script but failed to start
> it. Renaming it to not end with .sh fixed the issue for me. This is more
> like a systemd bug than OE but I wonder if we could change update-rc.d
> bbclass to check the for the .sh in the start script and then complain
> about it?
Comment 1 Chen Qi 2013-02-19 03:02:12 UTC
There's a similar bug in sysvinit in our system.
https://bugzilla.yoctoproject.org/show_bug.cgi?id=3612
Comment 2 Radu Moisan 2013-05-13 10:44:50 UTC
this is not an issue anymore. I acknowledge the behavior in past, but now with lastest master (f7afeeb75993b159bb8959e0309bc5eb3978a8fb) all *.sh scripts seem to work. Tried to enable manually banner.sh and it works. Also rmnologin.sh works, as the service is alive and no warnings found in logs. Tried psplash.sh as well, and the service is started.
Comment 3 Ross Burton 2013-05-13 15:04:43 UTC
Confirmed, this piece of code that is now enabled always and not just for some distros is the fix:

  if (endswith(name, ".sh"))
    /* Drop .sh suffix */
    strcpy(stpcpy(r, name) - 3, ".service");