-1

I use the following crontab to regularly reboot my system

30 5 * * * root root reboot

but after these scheduled reboots, some services don't automatically start. The ones I have noticed already are OpenVPN and PostgreSQL, but I expect there to be more. Firstly, I noticed this after adding the scheduled reboot but as I recently upgraded from 15.10, it could be that something went wrong during the upgrade.

I hope someone can tell me, a) what I did wrong or/and b) what may have caused this.

FallenWarrior
  • 103
  • 5
  • 1
    *"What I did wrong?""* : Scheduled reboots are not a solution, they're a bandaid and you should fix the actual problem that requires your to regularly reboot. `---` *"what may have caused this?"* : Services that don't start after a reboot either are not enabled to start automatically in the first place (`systemctl list-unit-files --type=service`) or they fail to start properly (check logs for errors and `journalctl`) – HBruijn Sep 27 '16 at 18:09

2 Answers2

1

A) Daily server reboots are wrong. Other than that, the proper way to restart is shutdown -r now, which properly shuts down services on the server and then reboots.

B) Using reboot to reboot the server does not shutdown services, so those might end up in unstable state and therefore refuse to start.

Tero Kilkanen
  • 34,499
  • 3
  • 38
  • 58
  • I thought that `reboot` would link to `systemctl reboot` which does a proper restart sequence? – HBruijn Sep 27 '16 at 18:15
  • I think the question of "What did I do wrong" should be read as "What did I do wrong causing the services not to start" and not "what am I doing wrong when rebooting the server". Your answer has good information though. – pacey Sep 27 '16 at 18:17
  • That could be, actually i haven't used `reboot` since my early linux days years ago, when it did a direct reset. My answer could be obsolete therefore. – Tero Kilkanen Sep 27 '16 at 18:18
1

There might be an issue regarding the autostart of the daemons with which you are experiencing problems.

The correct behaviour depends on the init system used. It is not perfectly clear which one you are using. Since you upgraded to Ubuntu 15.10 systemd should be the default, but you are mentioning /etc/init.d and this would point to System-V style init scripts which are a bit different.

systemd

First you should check that the service has the correct systemd init script under /etc/systemd/system/multi-user.target.wants/{service}.service

Then you can enable the service by issueing the command:

$ sudo systemctl enable {service}.service

System V

Check the runlevel your system boots into when a maintenance reboot is done

$ runlevel

Check whether the service has a functioning bash script under /etc/init.d/{service}

Then enable the service on boot:

$ update-rc.d {service} enable
pacey
  • 3,833
  • 1
  • 15
  • 31
  • Clarification of the currently running version, I previously had 15.10 and now I upgraded to 16.04 using a regular `do-release-upgrade` but without removing the old packages, which I did manually afterwards. I tried both of your solutions since both files existed and after rebooting the daemons still did not autostart. When manually controlling services, I usually use `/etc/init.d/` and that works, so this time I executed `/etc/init.d/{service} restart` and that solved it like it usually does. – FallenWarrior Sep 27 '16 at 19:23
  • @FallenWarrior Can you check in `/proc/1/comm` which init system is currently in use? Maybe your system is configured for upstart which I haven't described in my answer. – pacey Sep 27 '16 at 19:31
  • It says `systemd`, therefore I don't know what the problem could be here. I operate this machine solely as a home server therefore I am far closer to consumer grade than to tech support grade, sorry for that. – FallenWarrior Sep 27 '16 at 19:53
  • Since you said you are issuing a `/etc/init.d/{service} restart` after the reboot that fixes the problem you might want to check whether after a reboot the services are running. Things I'd try would be `ps aux | grep openvpn` and `/etc/init.d/{service} start`. Just a shot in the dark but maybe the services get startet while the interfaces are not up yet. – pacey Sep 27 '16 at 19:57
  • The first snapshot only yields the `grep` process itself, as it has openvpn as an argument. Issuing `/etc/init.d/openvpn start` followed by another snapshot grep then also yields the daemon itself. Looks like the services aren't even run on startup. – FallenWarrior Sep 27 '16 at 21:13
  • systemd has some support for SysV style init scripts, but also a [number of incompatibilities](https://www.freedesktop.org/wiki/Software/systemd/Incompatibilities/) – HBruijn Sep 27 '16 at 22:36
  • You might want to look into [this question about PostgreSQL](https://serverfault.com/questions/787426/postgresql-not-listening-on-local-eth1-after-reboot/788044) which describes a similar problem which was solved by waiting for the ethernet device on (re)boot . – pacey Sep 28 '16 at 08:39
  • Anyways, I found the solution myself after taking a closer look at the error logs. I had bound these services to specific adresses instead of 0.0.0.0 but forgot adding `After=network-online.target` to the service files. – FallenWarrior Oct 02 '16 at 01:40