Multicast service won't start automatically after reboot
-
My apologies if this question has already been asked. I tried to find the answer on the forum but couldn’t find it. I would like my FOG 1.5.7 server to start the mutlicast manager service automatically after a server reboot. I ran the “systemctl enable FOGMulticastManager” command but it seems to failt to start by default after a reboot. I have to start the service manually myself. When I check the service status after a reboot I get “failed”.
Is there something I need to be doing differently? I checked that the service is set to “enabled” but it still won’t start. Any thoughts?
After a reboot (ip and names blurred for security reasons):
-
@Tom-Elliott Thank you for all the assistance. I actually ended up testing dev versions 1.5.7.102, and 1.5.8 and I can confirm both indeed fix the issue. Both versions now start all the services correctly after several reboots. Thank you for all your assistance Tom and everyone!
-
Mod Note: Moving to bug reports.
IMO it sounds like the multicast manager is starting up before the database server is fully ready to accept connections.
-
@george1421 Thank you. I am going to update the FOG server to 1.5.8, and we will see if it fixes it. I checked and both my servers (we have 2 campuses so I set up a server on both locations) do this exact same behavior. Could be something I did wrong during install of course, but I will report back after the update to 1.5.8. Thank you for this speedy help!
-
@rogalskij Are you sure this is the only service that has issues?
Restarting the service seems to fix the issue. The problem, from what I can gather, is at the time the FOG services are slotted to start, the database (and possibly the network) are unavailable. This explains why manually restarting this service seems to fix the problem.
There’s quite a few FOG services:
FOGMulticastManager - Multicast
FOGScheduler - Scheduled and Power Management Tasks,
FOGImageReplicator - Image replicator
FOGSnapinReplicator - Snapin Replicator
FOGImageSize - Updates size information for Images
FOGSnapinHash - Updates snapin hash information
FOGPingHosts - Pings hosts and updates status’It would seem, to me, that there’s a likely potential that all of these services are failing to start (or at least multiple)
Again this leads me to think the problem is at the time these services are beginning, not all the elements needed from the reboot have completed.
-
@rogalskij AFAIK 1.5.8 hasn’t been released yet. I know they were targeting the end of Jan but a few last minute bugs popped up that the developers wanted to squeeze in because they were important to the 1.5.x series. It probably would be helpful if you switched to the dev branch and testing 1.5.7.98 (or what ever release they are on now) for one of your sites to ensure that 1.5.8 addresses your issue. Just be sure to switch back to the
master
branch when 1.5.8 is released (by mid Feb the last I heard).If 1.5.7.98 doesn’t address your issue, be sure to post back here so the devs can look into the problem a bit deeper. Looking through the fix list for 1.5.8 I don’t see any mention of the multicast manager.
-
@Tom-Elliott I noticed that a bunch of services haven’t started for me as you suspected! Wow my server is functional and works and I am not even sure how?!
I ran “systemctl --failed” and this is what I get:
[root@clone ~]# systemctl --failed
UNIT LOAD ACTIVE SUB DESCRIPTION
● FOGImageReplicator.service loaded failed failed FOGImageReplicator
● FOGImageSize.service loaded failed failed FOGImageSize
● FOGMulticastManager.service loaded failed failed FOGMulticastManager
● FOGPingHosts.service loaded failed failed FOGPingHosts
● FOGScheduler.service loaded failed failed FOGScheduler
● FOGSnapinHash.service loaded failed failed FOGSnapinHash
● FOGSnapinReplicator.service loaded failed failed FOGSnapinReplicator
● nrpe.service loaded failed failed SYSV: A simple script to autostart NRPE and allow us to easily rebootI am going to check my server. Poor thing is an older Dell Poweredge running CentOS 7 so maybe it is just tired and slow and network or the database doesn’t start fast enough for the services?
-
@george1421 Hey there George, I thought 1.5.8 was released this morning? At least that is what my FOG login page told me. Am I incorrect? Should I wait you think?
-
@rogalskij I am working to get 1.5.8 released, yes. So I updated all the information and even posted a news article. Though I wasn’t going to post an announcement until the latest init’s are completed due to the last minute bug found this morning (just before I made the branch changes toward 1.5.8)
-
@rogalskij I have updated the FOG Systemd scripts in working-1.6 and in Dev-branch.
You can download and replace them if you’d like.
wget -O /lib/systemd/system/FOGImageReplicator.service https://github.com/FOGProject/fogproject/raw/working-1.6/packages/systemd/FOGImageReplicator.service wget -O /lib/systemd/system/FOGImageSize.service https://github.com/FOGProject/fogproject/raw/working-1.6/packages/systemd/FOGImageSize.service wget -O /lib/systemd/system/FOGMulticastManager.service https://github.com/FOGProject/fogproject/raw/working-1.6/packages/systemd/FOGMulticastManager.service wget -O /lib/systemd/system/FOGPingHosts.service https://github.com/FOGProject/fogproject/raw/working-1.6/packages/systemd/FOGPingHosts.service wget -O /lib/systemd/system/FOGSnapinReplicator.service https://github.com/FOGProject/fogproject/raw/working-1.6/packages/systemd/FOGSnapinReplicator.service wget -O /lib/systemd/system/FOGSnapinHash.service https://github.com/FOGProject/fogproject/raw/working-1.6/packages/systemd/FOGSnapinHash.service wget -O /lib/systemd/system/FOGScheduler.service https://github.com/FOGProject/fogproject/raw/working-1.6/packages/systemd/FOGScheduler.service systemctl daemon-reload systemctl restart /lib/systemd/system/FOG*.service
That should update all the systemd files as well as restart each service. You can then see if the fixes work by restarting the server.
-
@Tom-Elliott Thank you for all the assistance. I actually ended up testing dev versions 1.5.7.102, and 1.5.8 and I can confirm both indeed fix the issue. Both versions now start all the services correctly after several reboots. Thank you for all your assistance Tom and everyone!