Multicast interface binding issue
-
what version of fog 1.+ are you running?
-
v1.1.1.
Thanks.
-
The only nasties I can find in the logs were:
[LIST]
[]Gripes about not being able to open something in the database (even though the UI seemed to work fine) - Corrected by putting the MySQL root password into config.php.
[]Multicast log not recording anything at all.
[]Apache log: File does not exist /var/www/fog/management/css/images referrer [url]http://192.168.4.1/fog/management/css/jquery-ui.css[/url]
[]Apache log: Favicon.ico missing.
[/LIST]Nothing that looks bad in kern.log or dmesg.
-
What is the interface you’re trying to run from.
You’ll likely need to adjust it in /var/www/fog/commons/config.php for the multicast interface.
-
Hi Tom,
I’ve changed every occurrence of eth0 to eth1 in /var/www/fog/commons/config.php. I also checked the executable path for udp-sender is correct. There’s no sign or any error but “ps aux” on the server doesn’t reveal an incidence of the sender running after the task starts even though the task list shows the tasks as started. Partclone starts on the clients but just sits there doing nothing,
Bests,
Paul. -
Is the FOGMulticastManager service actually running?
-
Hi,
It appears not. [I]ps aux | grep -i fog[/I] returned only the grep process itself so the scheduler and replicator aren’t running either (The machine hadn’t got any scheduled jobs and isn’t part of a replication group so I don’t know if that is normal.).
When I ran [I]/etc/init.d/FOGMulticastManager restart[/I] it complained it couldn’t kill the current instance because the process for the PID it listed couldn’t be found. At this point, the multicast imaging started working.
Since the service restart went looking for a PID, my first assumption would be that the service was running but stopped unexpectedly. I guess the next job is to find out why it died…
Thanks.
-
My guess as to why it died unexpectedly was during an upgrade point. It’s probably more related to the rc.local script you’re using?
-
Hi,
This isn’t an upgrade, it’s a fresh install so I could write a machine build guide.
FOG was applied to a freshly installed Ubuntu 12.04LTS machine so none of the rc scripts have any custom mods.
Thanks,
Paul. -
The only guess I have as to why it died like that is it couldn’t find the mysql db. This is similar to the tftpd-hpa issue where it tries starting the service before there’s even been a network interface opened to run on.
The fix, from my testing, has been to remove all of the needed services of fog from initial boot up with:
[code]update-rc.d mysql disable
update-rc.d FOGMulticastManager disable
update-rc.d FOGImageReplicator disable
update-rc.d FOGScheduler disable
update-rc.d tftpd-hpa disable[/code]Then edit the /etc/rc.local file to contain:
[code]sleep 30 && service tftpd-hpa start
service mysql start
service FOGMulticastManager start
service FOGImageReplicator start
service FOGScheduler start
exit 0
[/code]That way all the services are still started at boot time, but after enough time has passed to establish network connectivity. The disabling of the services in the first code block just ensures nothing from the rc.local is trying to start something that is already started and may die.
-
Hi Tom,
Thank you.
I tried that and unfortunately, it doesn’t work for me. I checked the permissions for /etc/rc.local and tried using the full path name of service (/usr/sbin/service) to no avail. I would welcome your suggestions of what to try next.
Would it be possible for future versions of the services to syslog something meaningful if they die and try to respawn themselves a couple of times with a delay for each please?
Thanks,
Paul.
