FOGMulticastManager won't start

[gwhitfield]

Going to try going back to my snapshot just after server was created to see what’s happening there and try updating that to see if it is working after the update. I can go back and forth between snapshots to troubleshoot if anyone sees something.

[Wayne Workman]

MySQL looks fine. Try to clear out the tables in that “troubleshoot downloading - multicast” article, then restart the FOGMulticastManager service. Steps on this are in that article.

The log issues look permission related, it says permission denied. Check permissions on the logs out. /opt/fog/log

[Tom Elliott]

@gwhitfield Just a wild stab here. I’ve seen this issue before in the case of Ubuntu (maybe others?) where you are using GUI interface to interact with a Terminal session of user’s?

What user are you logged in as on the GUI if you are indeed on a gui? If this is headless, I can try to help further.

The issue I’ve seen with GUI based terminals and Ubuntu is the load up of the root user (especially if you’re logged into the GUI as ROOT – otherwise it’s mostly user error (not bad, just unknowing) is the root user doesn’t load the profile information properly. This leaves some very strange things in the dark for us.

If you reopen the terminal, but this time run – sudo -i after getting in, and try rerunning the installer, does this help, hurt, or no difference?

Speaking of the user-error part, if you are in as a different user (regardless of head or headless environment) and you don’t source the environment correctly, things will go strange. All things will seem to work properly, but permissions of the root user aren’t established as it is still under the user sourcing that logged in.

For example:

sudo su root or sudo su is not the same as sudo -i or sudo su -

[gwhitfield]

@Tom-Elliott I created a user “Administrator” for all GUI interaction so I’m always logged into the GUI as that user. I don’t really ever use the GUI terminal though I have been using root when connected on my Win10 desktop via “WinSCP” to move or copy files such as the scripts for hardware independent driver installs or copying the drivers themselves. I also use PuTTY regularly to do the trunk upgrades but log in as “administrator” and use “sudo” when necessary. This was the case on 5/18 when every one of the servers I updated appears to have stopped working (as far as logging goes).

Since I don’t use the GUI terminal I’m understanding that I should still try running installer through PuTTY but use “sudo -i” instead of just “sudo”?

@Wayne-Workman I did try clearing tables on one server and it didn’t appear to work but I’ll try a couple others since that one server is now currently in the process of rebuilding from a previous snapshot.

Thank you both for your replies!

[Tom Elliott]

@gwhitfield That is absolutely correct.

[gwhitfield]

@Tom-Elliott It doesn’t appear to help any, the log files still aren’t being created and the FOGMulticastManager service still isn’t starting. Unfortunately I don’t really understand how to use “sudo” I guess. When in terminal mode (using PuTTY, not GUI) I only append it to a command if I get an “access denied” response to the user “administrator” that I’ve created and I’ve done that a thousand times when upgrading to trunk.

I’m wondering now if there isn’t something in my upgrading process that left me vulnerable to this issue. I follow these instructions I got off another post:

1. Log in as Administrator
2. Run “sudo apt-get autoremove”, enter root password and approve
3. Reboot server (“sudo reboot now”)
4. Run “sudo apt-get update”, enter password
5. Run “sudo apt-get upgrade”
6. Run “sudo apt-get install subversion” - (Go to Step 9 for any server already at Trunk since svn folder is already created)
7. Enter “cd ~”
8. Enter “mkdir svn”
9. Enter “cd svn”
10. Enter “sudo svn co https://svn.code.sf.net/p/freeghost/code/trunk”
11. Enter “cd ~/svn/trunk/bin”
12. Enter “sudo ./installfog.sh”
13. When prompted, open WEB GUI and update database per the prompt

[Tom Elliott]

@gwhitfield I say that is correct because, first, the source code of the installfog.sh file is already going to call sudo in the case it is detected that a non-root user started the installer, however there’s not a really feasible way for it to know if the environment of root is sourced properly. It’s most likely safer to place yourself in the root environment directly with sudo -i. I don’t know if this IS the case, but I can be more certain knowing the environment is being used as one would normally expect. Even if it still doesn’t cause help you, at least we have a partial stepping stone to work from.

[gwhitfield]

@Tom-Elliott My best bet may be to simply rebuild these servers and quit everyone chasing this. I have tested saving the hosts and images on the original server to another location then replacing them once the update to trunk is done from 1.2 (where I last snapshotted it). I’m multicasting just fine with this one now. Not knowing what caused it leaves me open to doing it to myself again but with good backups I don’t suppose it’s necessary to get too wrapped up in it unless there’s something we can all learn from it. I’m going to have a couple problem servers available for a while as I’m not going to get to them all in the next several weeks.

@Wayne-Workman - I have yet to compare the folder rights but will do so tomorrow in HIGH hopes its as simple as changing them to mimic a working installation.

Thanks to both of you gentlemen!!

[Wayne Workman]

@gwhitfield the senior developer suggested changing to sudo -i and then running the installer. This is simple to do, why not just do it?

[gwhitfield]

@Wayne-Workman Simply trying to not waste anyone’s time, that’s all. I don’t look forward to re-doing 15 FOG servers but being a linux noob makes troubleshooting super difficult.

So anyway I just now tried what Tom suggested and it didn’t work. Logged in as my “administrator” account. Entered “sudo -i” and re-ran the installer. Rebooted and logged back in as “administrator”, FOGMulticastManager service is not running. Ran "sudo -i " and tried to restart service and it would not. Tried stopping the service, then starting again and it would not. tried restarting and it would not. I also believe it probably has something to do with dependencies and permissions that got changed somehow by the process I was following to do trunk updates but I have no idea where to begin, just not that Linux savvy.

[Wayne Workman]

@gwhitfield You’re not wasting our time. We help people willingly. If you can wait until about 4 PM central standard, I can offer some help through team viewer.

[gwhitfield]

@Wayne-Workman I can do that. Thank you!

[gwhitfield]

@Wayne-Workman I have been working on this as much as possible today and realize that my process was built on old instructions, that there are more recent instructions to do this. Specifically in how I have been logged in as my admin account rather than root (sudo -i) and using sudo to get me by, as well as the location of the installation not being /root/fogproject/. I have cleaned that up and feel pretty confident I can produce a better server. My boss has allocated a bit more time to this so I’m prepared to rebuild these servers. We can skip the TeamViewer session if it’s a hassle for you, I just don’t want to cause you any troubles. If you feel it’s something important to look at I’m all for it though?

[Wayne Workman]

@gwhitfield I’m all for you doing it yourself l. If you hit a bump in the new build, make a new thread and you’ll generally get help fast.

[gwhitfield]

@Wayne-Workman Thanks a ton for you offer to assist!!! I’m going to put these servers right. Need to read up on how environments change in Linux as I’m guessing it has to do with my problem. Live and learn! This should be marked solved I think as we can reasonable guess the problem is hidden in how the server was built/upgraded in the first place.