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?

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

| improve this answer | |
  • 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

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.