1.5.2 on Debian - Multicast Session

[maxabercrombie]

Good Morning All

I’ve recently implemented a new FOG solution at my place of work, and everything was running great under 1.5.0. However, after upgrading to 1.5.2 (due to the slow login issue) I have found that starting a Multicast session no-longer works. We can still do it ‘the old fashioned’ way by creating a group in FOG and adding hosts, and then Multicastiing, but this is not really adequate.

The symptoms I’m seeing are that I will click ‘images’ from the banner and then ‘Multicast’ from the left hand menu, enter the details (session name, number of hosts, timeout and image name) but when I click start, nothing happens. And I mean NOTHING! no logs, no sessions in progress, nothing presented on the screen (i’m just taken back to the same screen that you get when you click on Multicast with the default values) - nothing to indicate why it has failed. The button pops in and and out again and that’s about it.

Apart from that, 1.5.2 is working OK, but this one particular problem is driving me around the bend, so if anyone has any suggestions it will be much appreciated as we have a big roll out in a few months. I would post logs, but like I said, there aren’t any that give an idea as to why it’s broken.

Thanks

Regards

Max

P.S. Admin, Please delete my ‘UPDATE - 1.5.2 on Debian - Multicast Session’ post. I’m new to the site and I tried to edit this topic and ended up creating a new topic! I do not have sufficient privileges to delete the new post apparently - Thanks!

[maxabercrombie]

An update - It seems that the task does start but terminates immediately after starting. I have the timeout set to 600 minutes for testing and UDPCAST MAXWAIT to 60 in fog settings.

Spotted the following in the multicast log:

[05-02-18 1:00:17 pm]  | Task (7) test020503 is new!
[05-02-18 1:00:17 pm]  | Task (7) /images/dep_04 image file found.
[05-02-18 1:00:17 pm]  | Task (7) test020503 2 clients found.
[05-02-18 1:00:17 pm]  | Task (7) test020503 sending on base port: 59568.
[05-02-18 1:00:17 pm]  | Command: /usr/local/sbin/udp-sender --min-receivers 2 --max-wait 3600 --portbase 59568 --full-duplex --ttl 32 --nokbd --nopointopoint --file /images/dep_04/d1p1.img;/usr/local/sbin/udp-sender --min-receivers 2 --max-wait 10 --portbase 59568 --full-duplex --ttl 32 --nokbd --nopointopoint --file /images/dep_04/d1p2.img;
[05-02-18 1:00:17 pm]  | Task (7) test020503 has started!
[05-02-18 1:00:17 pm]  | Cleaning 1 task as they have been removed
[05-02-18 1:00:17 pm]  | Task (7) test020503 is being cleaned.
[05-02-18 1:00:17 pm]  | Task (7) test020503 has been completed.

Again, any help much appreciated.

Thanks

[maxabercrombie]

Another Update - So it seems that I’m hitting some sort of timeout issue.

I’m not convinced that this is working correctly, but I can get this to ‘work’ by doing the following:

1. in Fog settings --> FOG Linux Service Sleep Times --> MULTICASTSLEEPTIME, Change the default value from 10 to 25 seconds
2. Cue up a couple of machines with join multicast session from pxe boot, and enter the session name ready to go on the client machine before creating the session in the Fog console
3. Fill out the fields to create the session in the fog console with a unique name that I’ve not used before
4. Create session, and immediately hitting enter on the client machines

This then kicks of the multicast on both test machines. If I miss the 25 second time frame set in MULTICASTSLEEPTIME, the multicast fails and I see again:

[XX-XX-XX X:XX:X pm] | Cleaning 1 task as they have been removed
[XX-XX-XX X:XX:X pm] | Task (7) test020503 is being cleaned.
[XX-XX-XX X:XX:X pm] | Task (7) test020503 has been completed.

I thought that I had found a solution and extended the MULTICASTSLEEPTIME to a larger number, but alas this was not to be. If I extend MULTICASTSLEEPTIME to much more than about 45 seconds, the multicast does not start and I’m presented with ‘Please Wait’ at the Partimage screen.

I don’t think I’m a million miles away now from a solution, so again, if anyone has any suggestions it would be much appreciated.

It is also worth noting that if I create a group in Fog and set up a multicast that way, there are no issues and the multicast goes through quite happily. We tested this today in a room of 21 PCs.

Thanks Again

Max

[Tom Elliott]

@maxabercrombie I’m aware of a problem with multicast sessions though I’m not quite sure how to address the issue. Multicast is a beefy fickle thing under the hood so it may take me a bit before I can figure out what’s going on.

I know this isn’t the answer you are hoping for but at least you know I am aware there is a problem. I just have no knowledge right now on how to address it.

[maxabercrombie]

@tom-elliott Thanks Tom

Glad to have confirmation of issues. I was starting to lose my mind! Thank you for taking the time to look at this.

I’ll keep checking back, and with new information/logs if and when I find them.

Regards

Max

[Tom Elliott]

@maxabercrombie There’s one trick that could do to fix this, though I don’t like it much.

Essentially clear the multicastSessions and multicastSessionsAssoc tables:

TRUNCATE TABLE `fog`.`multicastSessions`;
TRUNCATE TABLE `fog`.`multicastSessionsAssoc`;

While logged into mysql itself. (mysql -u root)

[maxabercrombie]

@tom-elliott Excellent stuff! I’ll give this a go tomorrow when I’m back in the office. If this can get around our immediate issues it will help us greatly in the short term.

Thanks for the support. Much appreciated

Regards

Max

[Solkre]

I’m running 1.5.4 and have this issue. Are there any updated workarounds?