Multicast Issues on Centos 7
-
I’ve verified that the interface is set correctly in the storage management on the web gui. It has em2 listed there. I’ve also truncated the tables specified in the first link and restarted the services. Still hanging.
I am getting in the multicast log
12:42:29.341277 UDP sender for /opt/fog/.fogsettings at xxx.xxx.xxx.xxx on em1
12:42:29.341288 Broadcasting control to xxx.xxx.xxx.xxx
12:44:54.434308 Using mcast address xxx.xxx.xxx.xxxIt seems to be ignoring the specified interface in the .fogsettings file.
I had to make one modification to the UDP-Cast command in that it shows the clients connecting if I specify em2 instead of em1.
-
The interface to check would be at the Storage Node, not the Global Settings (those are just a failsafe if everything else fails to work right.)
-
Sorry… I’ve verified this as above and the settings are what I would expect for both the IP Address and the interface.
-
I’m facing same problem
-
I’m going to work on a far more simplified multicast test that people can set up using udpsender and udpreciever
-
Using one of the links, can’t remember which. I was able to get the server and client to send using the udp-sender and udp-receiver. So I know they can talk, but I had to use the command.
udp-sender --file /opt/fog/.fogsettings --log /opt/fog/log/multicast.log --ttl 32 --nopointopoint --interface em2
if I dropped the last bit off then it would still try to grab em1 instead of em2.
-
@BedCruncher said in Multicast Issues on Centos 7:
Using one of the links, can’t remember which. I was able to get the server and client to send using the udp-sender and udp-receiver. So I know they can talk, but I had to use the command.
udp-sender --file /opt/fog/.fogsettings --log /opt/fog/log/multicast.log --ttl 32 --nopointopoint --interface em2
if I dropped the last bit off then it would still try to grab em1 instead of em2.
wiki
-
@BedCruncher said:
if I dropped the last bit off then it would still try to grab em1 instead of em2.
Can you please schedule another multicast job and check with
ps ax | grep udp
to see if the started commands are missing the--interface
parameter on your system? -
@Sebastian-Roth said in Multicast Issues on Centos 7:
ps ax | grep udp
Are you saying I need to do this from the debug boot or schedule a normal multicast and run something along the lines of
watch -n 5 'ps aux | grep udp'
-
I’ve updated my current install version to 7300 earlier today and tried to again reapply the fix specified in the wiki to change the command for the function getIPAddress in the file fogbase.class.php and not in the file FOGCore.Class.php
exec("/sbin/ip addr list em2 | grep -o '[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}/[0-9]\{1,2\}' | cut -d/ -f1", $arR, $retVal);
-
@BedCruncher I didn’t have much time to replicate this on one of my test machines yet. So I kind of just throw ideas at you, sorry.
Running
ps aux | grep udp
on the FOG server - to see all the command line options…The command in function getIPAddress (fogbase.class.php) lookes like this in current trunk:
exec("/sbin/ip addr | awk -F'[ /]+' '/global/ {print $3}'",$IPs,$retVal);
-
@Sebastian-Roth said in Multicast Issues on Centos 7:
exec(“/sbin/ip addr | awk -F’[ /]+’ ‘/global/ {print $3}’”,$IPs,$retVal);
No worries Sebastian, I’m just trying to get the exact information you’re requesting. Want to make sure that you get the pertinent information for your question so that we can get this figured out 100%.
I changed the function back to what you posted from current trunk. I had attempted to change it in relation to the
FOG .32 Centos 7 Instructions, but to no avail.Keep the ideas coming. I’d love to put this one to bed and get back to using this awesome software!
-
@BedCruncher Ok, I finally had some time to spin up my test machine and give it a try. Setting
ens4
instead ofeth0
in the storage settings I get this in the logs:[04-26-16 9:46:58 pm] | CMD: cat /images/foo/d1p1.img | /usr/local/sbin/udp-sender --interface ens4 --min-receivers 2 --max-wait 600 --portbase 58038 --full-duplex --ttl 32 --nokbd --nopointopoint...
As well I see the command (options) in the process tree on the FOG server with
ps ax | grep udp
:3350 ? S 0:00 sh -c cat /images/foo/d1p1.img | /usr/local/sbin/udp-sender --interface ens4 --min-receivers 2 --max-wait 600 --portbase 62258 --full-duplex --ttl 32 --nokbd --nopointopoint
This is with FOG trunk unmodified. I don’t think you need to change fogbase.class.php! Please see what you have in your process list on the FOG server after starting the multicast task.
-
So I started the multicast session from my server this morning and checked the Multicast Log from the webgui, but I am not seeing that that command has fired off in the logs. Also, I don’t see the udp task showing up in my process list. Excuse my ignorance, but did I do something incorrect?
EDIT:
The command to at least trigger the process has worked though as it starts the process of trying to do the imaging but hangs at the same spot as before. Any guidance would be helpful.Just realized maybe you were referring to have me run the UDP-Sender / UDP-Receiver commands manually?
-
@BedCruncher said:
Just realized maybe you were referring to have me run the UDP-Sender / UDP-Receiver commands manually?
Nope, I was asking you to run the command
ps ax | grep udp
and show the output to us. From what I get you don’t seem to have any udp-sender processes running after you started multicast task. Please make sure you have a valid image on your server:ls -al /images/<img-name>
(please post the output here as well!)… -
Here’s the result of the
ls -al
ls -al /images/ total 4 drwxrwxrwx. 5 root root 81 Apr 27 10:39 . dr-xr-xr-x. 20 root root 4096 Apr 27 10:08 .. drwxrwxrwx. 2 root root 22 Apr 27 10:39 dev -rwxrwxrwx. 1 root root 0 Apr 27 08:48 .mntcheck drwxrwxrwx. 2 root root 29 Apr 27 08:48 postdownloadscripts drwxrwxrwx. 2 root root 69 Apr 27 10:39 W7Px64PreSysprep
and
ps -aux | grep udp
ps aux | grep udp root 25751 0.0 0.0 112644 960 pts/1 S+ 10:45 0:00 grep --color=auto udp
-
@BedCruncher No UDP-sender processes… please check you multicast.log to see if it actually starts any…
As stated in one of my earlier posts I see this in my multicast.log:
[04-26-16 9:46:58 pm] | CMD: cat /images/foo/d1p1.img | /usr/local/sbin/udp-sender --interface ens4 ...
You might want to upgrade to the latest version as Tom has fixed a bug which truncated the log file every so often. So you might miss the output. Upgrade and then see what you have in the logfile!
As well, show us what you have in the image directory:
ls -al /images/W7Px64PreSysprep
-
@Sebastian-Roth
Results ofls -al /images/W7Px64PreSysprep/ total 22338008 drwxrwxrwx. 2 root root 69 Apr 27 10:39 . drwxrwxrwx. 5 root root 81 Apr 27 10:39 .. -rwxrwxrwx. 1 root root 1048576 Apr 27 10:12 d1.mbr -rwxrwxrwx. 1 root root 8561702 Apr 27 10:12 d1p1.img -rwxrwxrwx. 1 root root 22864501047 Apr 27 10:39 d1p2.img -rwxrwxrwx. 1 root root 190 Apr 27 10:12 d1.partitions
On a side note, I went in earlier and completely wiped out my current install according to Uninstall Fog and then reinstalled earlier this morning and the multicast portion didn’t show up at all until manually ran
touch /opt/fog/log/multicast.log
and the selection was also missing from the Log Viewer menu. I verified the file permissions of that file compared to the other longs under that directory.Just downloaded build 7348 and am now getting
-
Following that screen, I let it run for a bit, then while it was doing the invalid session scrolling, I deleted and reinitiated a multicast session and it’s hanging at the same spot as previous.
-
@BedCruncher I am very sorry but without information (log file for example) I am not able to help. Posting the partclone picture is nice but does not really help I am afraid. Hope this does not sound ignorant, it’s not meant to!
We need to get some log output from the FOGMulticastManager (multicast.log)! Or at least see the udp-sender processes on the FOG server. Otherwise multicast will not work. Please try this:
service FOGMulticastManager restart tail -f /var/log/fog/multicast.log
Notice the log path! Multicast daemon writes the log to /var/log…