FOGMulticastManager won't start
-
@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:
- Log in as Administrator
- Run “sudo apt-get autoremove”, enter root password and approve
- Reboot server (“sudo reboot now”)
- Run “sudo apt-get update”, enter password
- Run “sudo apt-get upgrade”
- Run “sudo apt-get install subversion” - (Go to Step 9 for any server already at Trunk since svn folder is already created)
- Enter “cd ~”
- Enter “mkdir svn”
- Enter “cd svn”
- Enter “sudo svn co https://svn.code.sf.net/p/freeghost/code/trunk”
- Enter “cd ~/svn/trunk/bin”
- Enter “sudo ./installfog.sh”
- When prompted, open WEB GUI and update database per the prompt
-
@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. -
@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!!
-
@gwhitfield the senior developer suggested changing to
sudo -iand then running the installer. This is simple to do, why not just do it? -
@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.
-
@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.
-
@Wayne-Workman I can do that. Thank you!
-
@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?
-
@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.
-
@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.
