FOGScheduler needs started manually since upgrading to SVN 2912 from 1.2.0

[Axel]

I upgraded my FOG server so I could get the latest trunk version this morning and noticed a problem. It seems none of the FOG services are starting on their own like they should be. See below
[CODE]aseikola@crfog:~$ sudo service FOGImageReplicator status
[sudo] password for aseikola:
Usage FOGImageReplicator {start|stop|restart}
aseikola@crfog:~$ sudo service apache2 status
Apache2 is running (pid 1418).
aseikola@crfog:~$ sudo service FOGMulticastManager status
Usage FOGMulticastManager {start|stop|restart}
aseikola@crfog:~$ sudo service FOGScheduler status
Usage FOGScheduler {start|stop|restart}
aseikola@crfog:~$
[/CODE]

[Tom Elliott]

Status doesn’t exist on Ubuntu. Only way I know of to check if they’re running is with
[code]ps -ef|grep FOG[/code]

[Axel]

here is the output of that command

[CODE]aseikola@crfog:~$ sudo ps -ef|grep FOG
aseikola 2944 2589 0 13:56 pts/0 00:00:00 grep --color=auto FOG
[/CODE]

FOG is displaying in red if that helps

[Axel]

I went through and tried just starting each FOG service and that didn’t work, each service had to be restarted

[CODE]aseikola@crfog:~$ sudo ps -ef | grep FOG
root 4122 1 0 14:13 ? 00:00:00 /usr/bin/php -q /opt/fog/service/FOGMulticastManager/FOGMulticastManager
root 4175 1 0 14:13 ? 00:00:00 /usr/bin/php -q /opt/fog/service/FOGSnapinReplicator/FOGSnapinReplicator
root 4306 1 0 14:14 ? 00:00:00 /usr/bin/php -q /opt/fog/service/FOGImageReplicator/FOGImageReplicator
root 4386 1 0 14:14 ? 00:00:00 /usr/bin/php -q /opt/fog/service/FOGTaskScheduler/FOGTaskScheduler
aseikola 4400 2589 0 14:14 pts/0 00:00:00 grep --color=auto FOG
aseikola@crfog:~$
[/CODE]

[Axel]

It seems the behavior is the same on my other install in another location using version 1.2.0. The operating systems is Ubuntu server 12.04.5 LTS. On a reboot the FOG services don’t start up. I try to start the services, and I get a fail. If I restart the service It starts.

[CODE]aseikola@qcfog:~$ sudo service FOGScheduler start
[sudo] password for aseikola:

• Starting FOG Computer Imaging Solution: FOGScheduler [fail]
  aseikola@qcfog:~$ sudo service FOGScheduler restart
• Restarting FOG Computer Imaging Solution: FOGScheduler start-stop-daemon: warning: failed to kill 920: No such process
  [ OK ]
  aseikola@qcfog:~$ ps -ef|grep FOG
  root 1833 1 0 14:33 ? 00:00:00 /usr/bin/php -q /opt/fog/service/FOGTaskScheduler/FOGTaskScheduler
  aseikola 1839 1691 0 14:34 pts/2 00:00:00 grep --color=auto FOG
  aseikola@qcfog:~$
  [/CODE]

[Tom Elliott]

I have a feeling this issue relates to the way services are handled of which I’ve not had the chance to fix. Not for lack of not trying but rather not knowing exactly why it occurs. My only guess is its related to systemd and services starting before necessary components are available.

[Axel]

Then this is a known issue? What can be done to start these at the end of the startup process. I was thinking of making a tiny bash script that will run at the end of init, once everything else is up.

[Tom Elliott]

You could put it in the rc.local file. Maybe just have something like:
[code]sleep 30
service mysql restart
service tftpd-hpa restart
service FOGMulticastManager restart
service FOGScheduler restart
service FOGImageReplicator restart
#if on svn
service FOGSnapinReplicator restart[/code]

[Tom Elliott]

Also, this goes just before the:
[code]exit 0[/code] stanza.

[Sebastian Roth]

Same issue on my machine (Debian 7.6). As Tom said, it’s got to do with services depending on others but being started too early. I am pretty sure the FOG init scripts (which call php scripts) fail because mysql is not coming up fast enough!

My fix is to remove all FOG init scripts from normal startup and call them in rc.local:

[CODE]# update-rc.d FOGMulticastManager remove

update-rc.d FOGScheduler remove

update-rc.d FOGImageReplicator remove

cat /etc/rc.local

sleep 5
service FOGMulticastManager start
service FOGScheduler start
service FOGImageReplicator start
[/CODE]

Not perfect but definitely working.

Maybe sort of a retry (x times) and wait loop could be implemented either in PHP or the init scripts…

[Tom Elliott]

We already have a “waiter” in the fog scripts, but something else is causing it to fail.

[Sebastian Roth]

Can’t see the “waiter”. Is it in the bash script or in php? Can’t find anything in either…

[Tom Elliott]

It’s in the PHP.

The service files called: lib/fog/MulticastManager, lib/fog/ImageReplicator.class.php, lib/fog/SnapinReplicator.class.php, lib/fog/TaskScheduler.class.php and the “waiter” is the lib/fog/Daemon.class.php. However, the services still need some cursory level of access to the mysql, which if that’s the root of our problem, explains why these tasks fail to start properly as well. I wish I knew an all incumbent fix for this but my programming skills seem very off for this kind of tests. All I know is it Definitely is related to upstart/systemd. Even trying to add the necessary components for the service scripts to “require” before they can start seem to not matter.

[Axel]

Tom, have you ever had the fog services randomly stop to where you had to start them again? I have to start and restart my FOGScheduler service quite often. Version 1.2.0

[Tom Elliott]

I have not, but I’m constantly (as you can guess) on SVN so if there was some issue, I would have likely corrected on spot. That said, I don’t recall this being an issue. Thats not to say there isn’t one.