After updating some stuff on one of my debian-servers it ignores "some" of the scripts it should run at startup (from "init.d").

For example Postfix, Memcached or other daemons are startet, but "Apache2", "Cron" and others are not. I can't find any error in logfiles that indicate the start has failed, so i guess it was never triggered.

Any idea where to look? :(

edit: output from sysv-rc-conf looks good to me and shows that Apache and Cron should be started just like Postfix etc...

Any further ideas?

edit / solution: i moved everything that did not start properly to "S19..." in rc2.d and now all i need is running after reboot. But I am still clueless what was the problem before...


You can use sysv-rc-conf utility. It shows you all scripts found in /etc/init.d/ folder in rows. The columns represent the different run levels. You can (un)mark a cell in the table and the corresponding link is (de)activated.

On debian-based systems, you can also use update-rc.d. On redhat-like systems, you can use chkconfig. If the relevant links are there, the scripts should be invoked at startup.

| improve this answer | |
  • yes, all the links are present in rc2.d and rc3.d. But some are excecuted, some are not. this is what puzzels me :( sysv-rc.conf is a great tool. Everything looks fine there though. I'll post a screenshot soon – Sebastian Dec 31 '11 at 19:47

Scripts in init.d are only executed if they're supposed to run at the particular run level. Most Linux distributions use symbolic links from /etc/rcX.d, where X is the run level, to select which scripts are executed. Your distribution may also provide a tool to manage these links.

| improve this answer | |
  • yes, all the links are present in rc2.d and rc3.d. But some are excecuted, some are not. this is what puzzels me :( – Sebastian Dec 31 '11 at 19:44

I'm not really a Server Fault person but I have great respect for the SO engine and all instances of it. I had the problem described here, and eventually solved it.

In my case, /etc/rc2.d was ignored because my system was using /etc/init.d/.depend.start instead. I edited it manually, and the changes I made to that file were NOT ignored.

I found that out by tracing the /etc/init.d/rc script, and the FILES section at the end of the startpar man page. I really wish this had been less obscure and silent. It seems it is not a recent change, but I never ran into it, possibly because I used stable repositories lately. Or because apt-get was doing its job and I didn't have to change the settings manually.

However, it might not be the issue described in this thread. The author mentioned using S19 fixed his problem, which I can make no sense of. Anyway, I hope this will be useful to someone. I checked many threads and did not find the solution anywhere.

| improve this answer | |

One place to check is the /etc/default/servicename file (where servicename is the name of the service not starting).

Some init scripts will have an option in that file which controls the daemon starting which defaults to no so that it forces you to at least look at the configuration before starting the daemon.

Apache2 and cron don't have this setting from memory but perhaps some of the "others" you referred to might use it.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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