FOGScheduler needs started manually since upgrading to SVN 2912 from 1.2.0

  • 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}

  • Senior Developer

    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.

  • 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

  • Senior Developer

    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.

  • Senior Developer

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

  • Senior Developer

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

  • Senior Developer

    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

    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…

  • Senior Developer

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

  • Senior Developer

    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]

  • 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.

  • Senior Developer

    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.

  • 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

  • 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

  • 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

    FOG is displaying in red if that helps

  • Senior Developer

    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]