I have read the answer/comments for the thread Diffrence between /etc/init.d/ssh start and service ssh start.

But I need this /etc/init.d method to be working. I have some auto-generated scripts which invoke /etc/init.d method only. Could you kindly provide me some fix/workaround for this?

  • The old SysV method of putting script in /etc/init.d will still work if everything is in place. Also note that service is a good option in the sense that it will first look in /etc/init and then /etc/init.d for the script so if a script is only in /etc/init.d then service will do the same as /etc/init.d/script start|stop|restart ..what is your goal ? – heemayl Sep 16 '15 at 12:06
  • @heemayl I'd be curious to know if that's actually the case though. Upstart (et al) have very different ways of monitoring the PID and status of things, so if Upstart starts rsyslog, will the sysv-init version be able to stop it? Would the upstart command be able to stop a sysv-init version? – Oli Sep 16 '15 at 12:10
  • @Oli if both scripts exist then the one in /etc/init.d would contain some logic that would skip it if the init is upstart/systemd..if the script is only in /etc/init.d then it would work as expected.. – heemayl Sep 16 '15 at 12:13
  • Hi Heemay, thanks for your comments..well, actually I am trying to install defense4all package & this guy keeps on complaining about "Failed to start rsyslog service". After some investigation I saw it uses one auto/runtime generated script to start 'rsyslogd' through /etc/init.d. I am very new to this defense4all & I donno where to change that script (if at all possible). To me, making /etc/init.d working looked easier compared to that other option. I understand /etc/init.d is not the recommended method, but I thought there might be some workaround for this. – Sanjib Sep 16 '15 at 12:14
  • Hard to tell without seeing the insights..please edit your question and the mentioned script residing in /etc/init.d....also while responding to someone's comment please use "@name" e.g. @heemayl – heemayl Sep 16 '15 at 13:01

The last answer is a way to solve the defense4all installation problem about "Failed to start rsyslog service".This problem is caused by the bug of rsyslog (maybe, I found on the other webs), you can use service rsyslog instead of /etc/init.d/rsyslog, so you can edit the file in defense4all code files to solve this problem.

In the file:

../defense4all/dfapp.aggregate/src/install/config_rsyslog.bash

change the last sentences:

/etc/init.d/rsyslog stop > /dev/null 

to:

service rsyslog stop

and:

/etc/init.d/rsyslog stop > /dev/null   

to:

service rsyslog start

And then rebuild the project to create .deb or .rpm files.Hope this may help you.

You faced this problem because the rsyslog script in newer Ubuntu is written to be handled by upstart and not the traditional init daemon.

I saw your fix in the comments above. Another workaround that allows your automation scripts to continue using /etc/init.d/rsyslog start|stop is -

Edit the file /etc/init.d/rsyslog , comment/delete all instances of following code block -

if init_is_upstart; then
    exit 1 (or exit 0)
fi

Now

/etc/init.d/rsyslog start|stop

should work.

For more information, see this.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.