Replication has stopped after ugprade

[moses]

@Sebastian-Roth This is all I got as output from ps:

 1341 ?        S      0:00 /usr/bin/php -q /opt/fog/service/FOGTaskScheduler/FO TaskScheduler
 1364 ?        S      0:00 /usr/bin/php -q /opt/fog/service/FOGPingHosts/FOGPingHosts
 9595 ?        Z      0:00 [FOGPingHosts] <defunct>
 9596 ?        Z      0:00 [FOGTaskSchedule] <defunct>
10088 pts/1    S+     0:00 grep --color=auto FOG

So perhaps multiple services are failing on start? Is there any way to find logs that would indicate the why?

[moses]

@Sebastian-Roth Here’s the output of ip addr:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: em1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 9c:b6:54:f0:3e:0d brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.66/24 brd 192.168.1.255 scope global em1
       valid_lft forever preferred_lft forever
    inet6 fe80::9eb6:54ff:fef0:3e0d/64 scope link
       valid_lft forever preferred_lft forever

[moses]

@Sebastian-Roth After updating this morning, the services now appear to be running (they are not running after a restart), but replication still isn’t actually taking place, nor has the log for the Image Replicator changed from my original post.

[Tom Elliott]

@moses can you check the storage nodes all have their proper network interface set correctly? This is why the errors and would also cause issues with the services as they’re waiting for the interface to become available.

[moses]

@Tom-Elliott I checked the setting in Storage Mgmt > Storage Nodes and they all match what is shown using ifconfig on the nodes thru ssh.

[Tom Elliott]

@moses if you manual stop and start the services do things work?

[moses]

@Tom-Elliott Nope, though the behavior there is kind of odd:

If I restart, it says “failed”.

If I stop, then start, it says “OK” for both, but nothing in the logs, and an image that is supposed to be replicating is not.

[Tom Elliott]

@moses So you’re running a variant of Ubuntu, Just guessing?

[moses]

@Tom-Elliott ubuntu 14.04

[Tom Elliott]

@moses Can you run:

sudo service vsftpd stop
sudo service FOGImageReplicator stop
sudo service FOGSnapinReplicator stop
sudo service FOGPingHosts stop
sudo service FOGMulticastManager stop
sudo service FOGScheduler stop
sleep 5
sudo service vsftpd start
sudo service FOGImageReplicator start
sudo service FOGSnapinReplicator start
sudo service FOGPingHosts start
sudo service FOGMulticastManager start
sudo service FOGScheduler start

[moses]

@Tom-Elliott okay, did that:

administrator@SVR-HQ-IMAGING:~$ sudo service vsftpd stop
vsftpd stop/waiting
administrator@SVR-HQ-IMAGING:~$ sudo service FOGImageReplicator stop
 * Stopping FOG Computer Imaging Solution: FOGImageReplicator            [ OK ]
administrator@SVR-HQ-IMAGING:~$ sudo service FOGSnapinReplicator stop
 * Stopping FOG Computer Imaging Solution: FOGSnapinReplicator           [ OK ]
administrator@SVR-HQ-IMAGING:~$ sudo service FOGPingHosts stop
 * Stopping FOG Computer Imaging Solution: FOGPingHosts                  [ OK ]
administrator@SVR-HQ-IMAGING:~$ sudo service FOGMulticastManager stop
 * Stopping FOG Computer Imaging Solution: FOGMulticastManager           [ OK ]
administrator@SVR-HQ-IMAGING:~$ sudo service FOGScheduler stop
 * Stopping FOG Computer Imaging Solution: FOGScheduler                  [ OK ]
administrator@SVR-HQ-IMAGING:~$ sleep 5
administrator@SVR-HQ-IMAGING:~$ sudo service vsftpd start
vsftpd start/running, process 9607
administrator@SVR-HQ-IMAGING:~$ sudo service FOGImageReplicator start
 * Starting FOG Computer Imaging Solution: FOGImageReplicator            [ OK ]
administrator@SVR-HQ-IMAGING:~$ sudo service FOGSnapinReplicator start
 * Starting FOG Computer Imaging Solution: FOGSnapinReplicator           [ OK ]
administrator@SVR-HQ-IMAGING:~$ sudo service FOGPingHosts start
 * Starting FOG Computer Imaging Solution: FOGPingHosts                  [ OK ]
administrator@SVR-HQ-IMAGING:~$ sudo service FOGMulticastManager start
 * Starting FOG Computer Imaging Solution: FOGMulticastManager           [ OK ]
administrator@SVR-HQ-IMAGING:~$ sudo service FOGScheduler start

Still no change, however (no replication or log changes)

[Wayne Workman]

I just updated to the latest, then deleted all images on my slave node, and quickly rebooted both master and slave machines… we’ll see how it goes.

[moses]

@Wayne-Workman See anything on that slave? Trying to determine if this is just an issue somewhere on the master I’m running.

[Wayne Workman]

@moses It replicated every image back perfectly. There’s something with your setup. Keep in mind it could still be FOG-related though, such as a credentials issue, it could be firewall related, or SELinux related. You might even be out of space on the storage node?? There are many possibilities.

I know you have said you’ve verified the FTP credentials, but let’s make doubly sure? There are instructions here for testing it: https://wiki.fogproject.org/wiki/index.php?title=Troubleshoot_FTP

Basically you should ssh into your main and try to open an FTP connection to the other nodes using the user/pass they have set in their respective listing under storage management.

Then the opposite, from the nodes, try to open an FTP connection to the main using the main’s credentials that are set in it’s respective Storage Management listing.

[Sebastian Roth]

@moses Did you find out what’s going wrong with the services? Any errors in the apache log when you try starting the service?

We’ve fixed the bandwidth.php issue. Can you please update to the latest version to see if those errors stop and the bandwidth monitor on the dashboard works for you.

[moses]

Unfortunately, even with some hands-on help, I wasn’t able to determine what the cause was. At this point my best bet was that it’s related to Linux. Even upgrading to a newer distro didn’t help. I’m currently in the process of moving my configuration over to CentOS, once I back up my images.

[Sebastian Roth]

@moses Are the services actually running after you started them by hand? ps ax | grep FOG

[Junkhacker]

if you run top, how much of your cpu do these services utilize?

[moses]

After moving my installation over to CentOS, the Image Replication service now starts. Hooray!

But alas, I run into another issue. See the last line of the fogreplicator.log:

  ###########################################
  #     Free Computer Imaging Solution      #
  #     Credits:                            #
  #     http://fogproject.org/credits       #
  #     GNU GPL Version 3                   #
  ###########################################

[03-08-16 2:00:59 pm] Interface Ready with IP Address: 8.67.5.309
[03-08-16 2:00:59 pm] Interface Ready with IP Address: 192.168.1.66
[03-08-16 2:00:59 pm] Interface Ready with IP Address: SVR-HQ-IMAGING
[03-08-16 2:00:59 pm]  * Starting ImageReplicator Service
[03-08-16 2:00:59 pm]  * Checking for new items every 600 seconds
[03-08-16 2:00:59 pm]  * Starting service loop
[03-08-16 2:00:59 pm]  * Starting Image Replication.
[03-08-16 2:00:59 pm]  * We are group ID: #1
[03-08-16 2:00:59 pm]  | We are group name: HQ
[03-08-16 2:00:59 pm]  * We have node ID: #1
[03-08-16 2:00:59 pm]  | We are node name: SVR-HQ-IMAGING
[03-08-16 2:00:59 pm]  * Found Image to transfer to 3 group(s)
[03-08-16 2:00:59 pm]  | Image name: Universal-W7P-x64-ENGINEERING
[03-08-16 2:01:00 pm]  * Type: 8, File: /var/www/html/fog/lib/fog/fogbase.class.php, Line: 55, Message: Undefined index: REQUEST_METHOD

This error only appears if I add an image to one specific storage group. Should I maybe delete the storage group or the node there and re-create them?

[Sebastian Roth]

@moses Thanks for reporting! I am sure Tom will fix this in a second. Anyhow, I don’t think this is a show stopper for you. Usually those “Undefined index” messages are just notices, not real PHP errors. Log should be going on… I hope!

By the way. Do you still have the fopen warnings in your apache error log? A fix has been pushed this morning.