There is a README file on CentOS 7 in /etc/init.d that says
Note that traditional init scripts continue to function on a systemd system. An init script /etc/rc.d/init.d/foobar is implicitly mapped into a service unit foobar.service during system initilization
So I dropped my file in the above directory, rebooted and my item did not start.
doing "systemctl list-unit-files | grep myservice" did now show anything.
What piece did I miss?
I used to use rc.local and just need a script to run AFTER everything else has ran. no special start/stop/reload is needed... just a simple script.
Thanks
jerry
On 9/25/2014 11:39 AM, Jerry Geis wrote:
There is a README file on CentOS 7 in /etc/init.d that says
Note that traditional init scripts continue to function on a systemd system. An init script /etc/rc.d/init.d/foobar is implicitly mapped into a service unit foobar.service during system initilization
So I dropped my file in the above directory, rebooted and my item did not start.
doing "systemctl list-unit-files | grep myservice" did now show anything.
What piece did I miss?
is your init.d script chmod +x ?
just putting something in init.d isn't sufficient, it has to be linked in rc?.d as a S##name ... which chkconfig on (or systemctl) are supposed to do
is your init.d script chmod +x ?
just putting something in init.d isn't sufficient, it has to be linked in rc?.d as a S##name ... which chkconfig on (or systemctl) are supposed to do
Yes the script is executable... forgot to mention that.
From the comment in the README file, I thought that was all I needed to do.
I have not run any chkconfig or systemctl.
Jerry
Jerry Geis wrote:
is your init.d script chmod +x ?
just putting something in init.d isn't sufficient, it has to be linked in rc?.d as a S##name ... which chkconfig on (or systemctl) are supposed to do
Yes the script is executable... forgot to mention that.
From the comment in the README file, I thought that was all I needed to do.
I have not run any chkconfig or systemctl.
That's the problem, then. It should have comments, near the top, as to what what runlevel it should be started at, and *when* (i.e., after the network is up for apache...). Then running chkconfig <servicename> on will make it happen.
From a 6.5 server, from /etc/init.d/sshd:
# chkconfig: 2345 55 25
This will start and make sure sshd is running in runlevels 2, 3, 4, and 5, and it will start it as S55sshd on the way up, and shut id down with K25 on the reboot.
mark
On 25 Sep 2014 19:39, "Jerry Geis" geisj@pagestation.com wrote:
I used to use rc.local and just need a script to run AFTER everything else has ran. no special start/stop/reload is needed... just a simple script.
1) you can still use /etc/rc.d/rc.local 2) read the systemd.service man page and do a little learning. Thus is the exact sort of scenario systemd units make trivial with very simple config compared to writing a sysvinit script
On 26 September 2014 07:24, James Hogarth james.hogarth@gmail.com wrote:
On 25 Sep 2014 19:39, "Jerry Geis" geisj@pagestation.com wrote:
I used to use rc.local and just need a script to run AFTER everything
else
has ran. no special start/stop/reload is needed... just a simple script.
- you can still use /etc/rc.d/rc.local
- read the systemd.service man page and do a little learning. Thus is the
exact sort of scenario systemd units make trivial with very simple config compared to writing a sysvinit script
To give an example of the systemd bit should you wish to try a unit file:
cat > /etc/systemd/system/speciallittlesnowflake.service <<EOF [Unit] Description=This unit describes starting my special little snowflake and needs a network After=network-online.target
[Service] Type=forking ExecStart=/usr/local/bin/speciallittlesnowflake.sh TimeoutSec=0 RemainAfterExit=yes
[Install] WantedBy=multi-user.target EOF
systemctl daemon-reload systemctl enable myspeciallittlesnowflake
Adapt as needed ;)