Home / server / Questions / 416956
Accepted
batfastad
Asked: 2012-08-14 04:53:40 +0800 CST

CentOS 5 cron error when stopping/starting a service in crontab

  • 772

What's the best way to stop/start a particular service on a schedule using cron?

I tried running service servicename stop in a cron job but that didn't appear to work so switched to /etc/init.d/servicename

0 19 * * * /etc/init.d/servicename stop >/dev/null 2>&1
0 7 * * * /etc/init.d/servicename start >/dev/null 2>&1

That appears to work, not sure how consistently yet.
But the strange thing is that I get an e-mail from cron with the following error:

/bin/sh: line 1: 20178 Terminated  /etc/init.d/servicename start > /dev/null 2>&1

I only seem to get this error on the starting of the service. The stopping appears to be fine.

Also I thought that the >/dev/null 2>&1 should suppress the e-mailing of notifications. In this case though I'm glad it didn't.

Anyone know of a better way to stop/start services on a schedule, hopefully using cron?
Anyone got any idea what this error is about?

Thanks

centos

2 Answers

  1. You should be able to use /sbin/service...and in fact, that's a good habit to get into, since the next release of RHEL/CentOS/etc will probably use systemd instead of the legacy /etc/init.d scripts. If calling /sbin/service isn't working, you may want to take a look at any error output the command is generating.

    The Terminated error you're getting may be a buggy service control script...if it does something like killall servicename it may inadvertently kill the control script, which can result in this error. You're still seeing the error output because this error message is coming from the shell that cron starts to run your command, rather than from the command itself. If that's what's happening here, you may want to take a look at the init script and see if you can fix the problem.

    When debugging errors, it's sometimes a good idea to redirect stdout and stderr to a file rather than /dev/null (although that wouldn't help in this case).

    • 2
  2. Best Answer

    Yes, a better way to handle this is by using a job control utility like Monit. It's available for CentOS and is a clean way to ensure that your daemons are running when they need to, and can be used to start/stop individual or groups of services on a schedule (via cron)... The example where I see cron fall through the cracks is when something happens within the service window (application crash, etc.)

    Here's an example with the CUPS printing service...

    In a Monit config file somewhere, I'd have a stanza defining the CUPS service, including its PID and start and stop commands.

    check process cups
        with pidfile "/var/run/cupsd.pid"
        start program = "/sbin/service cups start"
        stop program = "/sbin/service cups stop"

    Running monit status

    Process 'cups'
  status                            Running
  monitoring status                 Monitored
  pid                               2357
  parent pid                        1
  uptime                            8d 6h 43m 
  .
  .     
  data collected                    Mon, 13 Aug 2012 09:07:03

    Running monit stop cups stops the service...

    Process 'cups'
  status                            Not monitored
  monitoring status                 Not monitored
  data collected                    Mon, 13 Aug 2012 09:08:03

    monit start cups starts it. I usually add the monit start and stop commands in the crontab to handle the application startup and shutdown. Monit will ensure that the service is also running during those times (e.g. after a mid-day reboot)...

    • 1