FOGScheduler needs started manually since upgrading to SVN 2912 from 1.2.0
-
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]
- Starting FOG Computer Imaging Solution: FOGScheduler [fail]
-
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.
-
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.
-
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] -
Also, this goes just before the:
[code]exit 0[/code] stanza. -
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…
-
We already have a “waiter” in the fog scripts, but something else is causing it to fail.
-
Can’t see the “waiter”. Is it in the bash script or in php? Can’t find anything in either…
-
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.
-
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
-
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.