Multicast Task is started to just 4 computers
-
I added 15 computers to a new group with a Image associated to the group and made a Multicast task for imaging this computers, but when the FOG server wakes up the machines via WoL the imaging process begins only to some of them (4) and the others are listed as queued in the web interface and even after the 4 machines are imaged the job does not continue to another 4 or all of the others which are queued.
I’m running the latest TRUNK fog (v. 2924) on CentOS Linux. I had no problems before when I was running 1.2 (stable) fog.
So is it some configurational setup I have to make or is it some kind of BUG?[ATTACH]1628[/ATTACH][ATTACH]1629[/ATTACH][url=“/_imported_xf_attachments/1/1628_Multicast-task-active.png?:”]Multicast-task-active.png[/url][url=“/_imported_xf_attachments/1/1629_Multicast-tasks-list.png?:”]Multicast-tasks-list.png[/url]
-
UPDATE: The 4 machines are imaged OK but the others are still in the QUEUE and the listing of the Active Multicast Tasks says there are NO multicast tasks.
-
Did FOG wake up all 15 clients? Did the others get the normal FOG iPXE Boot menu (list with ‘Boot from harddrive’ as the first item)? What if you start the job again?
[CODE]# ps ax | grep “udp-sender”[/CODE]
You should see several processes. Keep your eyes open for the command option ‘–min-receivers’. As far as I know (FOG 1.2.0) multicast is not going to start if hosts are missing. Not sure if this is still true in current SVN. But check your process list anyway! -
I believe there is a timeout value for all multicast tasks.
-
Confirmed, the --max-wait parameter is in the data as well.
-
'Cause I wasn’t on site and deployed the task remotely It turned out that FOG couldn’t wake all the computers from Lan in that particular case. But still not all the computers join the Multicast session, some of them are just waiting on the screen with partclone. And I think is because of the [FONT=Ubuntu][COLOR=#555555]FOG_UDPCAST_MAXWAIT[/COLOR][/FONT]
It’s set to 10 in the config of FOG the hint says this is in MINUTES but I think (I’m sure) It’s in seconds, so I increased it to 100 and set the value define( “UDPSENDER_MAXWAIT”, null ); to define( “UDPSENDER_MAXWAIT”, 180 ); in the var/www/html/fog/lib/fog/Config.class.php file. Now I’m having more machines joining and actually participating in the Multicast Image Process. -
[quote=“nikonaum, post: 41320, member: 2897”]'Cause I wasn’t on site and deployed the task remotely It turned out that FOG couldn’t wake all the computers from Lan in that particular case. But still not all the computers join the Multicast session, some of them are just waiting on the screen with partclone. And I think is because of the [FONT=Ubuntu][COLOR=#555555]FOG_UDPCAST_MAXWAIT[/COLOR][/FONT]
It’s set to 10 in the config of FOG the hint says this is in MINUTES but I think (I’m sure) It’s in seconds, so I increased it to 100 and set the value define( “UDPSENDER_MAXWAIT”, null ); to define( “UDPSENDER_MAXWAIT”, 180 ); in the var/www/html/fog/lib/fog/Config.class.php file. Now I’m having more machines joining and actually participating in the Multicast Image Process.[/quote]UDPSENDER_MAXWAIT is the variable that was used for 1.2.0 and the value is in seconds.
You are correct that the FOG_UDPCAST_MAXWAIT currently is set to seconds. That’s a mistake I did, I’m sorry. The value is supposed to be in minutes on the GUI, but in my minor change over to try making the cmd lines generated more dynamically, I forgot to multiply this value by 60, which is what it really should be. I’ll have it corrected shortly.
[php]$this->FOGCore->getSetting(‘FOG_UDPCAST_MAXWAIT’) ? sprintf(’ --max-wait %d’, $this->FOGCore->getSetting(‘FOG_UDPCAST_MAXWAIT’)) : null,[/php]
I, now, have it more dynamic and fall back to UDPSENDER_MAXWAIT in the case where FOG_UDPCAST_MAXWAIT is set to zero.
SVN 2926.
-
CONFIRMED! It was an update (trunk ver. 2924) issue. The [FONT=Ubuntu][COLOR=#555555]FOG_UDPCAST_MAXWAIT [/COLOR][/FONT][COLOR=#000000]was set as default to 10 in the config settings of the web interface but the latest update as of the time (trunk 2924) was wrongly set up to seconds not minutes, so there was no enough time for all the multicast participants to join the multicast task. I can confirm it is fixed in [/COLOR]SVN 2926 like [URL=‘http://fogproject.org/forum/members/tom-elliott.7271/’][SIZE=13px][B]Tom Elliott[/B][/SIZE][/URL] says.
-
This post is deleted!
