0

I feel sure that someone, somewhere changed something on the server but I cannot identify what occurred. Keep in mind the service was working perfectly prior to the beginning of this week. (NOTE: this is specific to one server as this same service is running just fine on 4 other servers.)

The problem...

I have the following service to run a PHP script

start on filesystem and net-device-up IFACE=eth0
respawn

#exec echo OARSUDP ran at  `date` >> /var/log/oarsudp.log

script
    sudo -u root /usr/bin/php -f /home/src/www-server/services/job_info_parser.php
end script

If I attempt to start it I get a message - 

sudo service oarsudp start
oarsudp start/running, process 2604

If I immediately check the status I get - 

sudo service oarsudp status
oarsudp stop/waiting

Things I tried...

I add the exec line to send a comment to the log. It only works when the script tags and its contents are commented out.

I ran the PHP line inside the script tag from the command line and it works perfectly, throwing no errors.

I have confirmed the permissions are correct inside of /etc/init/ (user root, group root, permissions 644).

I have tried changing the name of the service, just because I read a post about some conflicting names and I was grasping at straws.

Additional info...

It appears that the service attempts to respawn, sending out the log message in the exec several times before the service dies.

I just located Upstart's logs and they state -

"Could not open input file: /home/src/www-server/services/job_info_parser.php".

I have tried changing permissions, group and owner but nothing worked.

Has anyone ever seen a service script stop working like this? If so, what was the cause and how can I fix it? Or am I being a total idiot, having introduced a problem within the script or service myself?

Jay Blanchard
  • 117
  • 7

1 Answers1

1

I'm assuming here that this is a long-running daemon-type task; if it's a one-shot run and stop task, then you need the "task" keyword.

1) exec and script are, as far as I'm aware, mutually exclusive; they're two different ways of specifying what's to run for this job.

2) I see no reason for the sudo; upstart runs as root, and you can use setuid/setgid to change the user/group the job runs as if it shouldn't be root.

I suspect that the sudo is confusing things, or hiding what's really going on; upstart is very particular about tracking the pids of running tasks. See http://upstart.ubuntu.com/cookbook/#expect for some gory details; in fact, see that entire page for some possible other clues

Craig Miskell
  • 4,216
  • 1
  • 16
  • 16
  • I have been studying the cookbook and several other sites trying to glean something that will help. Keep in mind that as it is this service has been running on *this* server for several months and is currently running on 4 other servers with no problems. I'll try it without the sudo. – Jay Blanchard Jan 13 '15 at 18:42
  • Tried it without sude, same result. – Jay Blanchard Jan 13 '15 at 18:45
  • Does the PHP script actually stay running? I.e. can you find it with ps? – Craig Miskell Jan 13 '15 at 18:49
  • If I start the PHP script from the command line it continues to run properly. I just located Upstart's logs and they state "Could not open input file: /home/src/www-server/services/job_info_parser.php". I have tried changing permissions, group and owner but nothing worked @CraigMiskell – Jay Blanchard Jan 13 '15 at 19:06
  • I don't know what else to say, sorry: PHP can't find the php script, so bails out. – Craig Miskell Jan 13 '15 at 19:10
  • I made a change based on what you had said, ditching the script tags for `exec /usr/bin/php -f /home/src/www-server/services/job_info_parser.php` and I'll be darned, it started working again. What possible changes on the server could screw with the script tags? – Jay Blanchard Jan 13 '15 at 19:41