Multicast task cancelled when you erase one task from WEBUI

[Fernando Gietz]

Server

• FOG Version: 1.4.0
• OS: RedHat 7.3

Client

• Service Version: 0.11.12
• OS: windows 7

Description

I created one multicast task with three hosts, one of them was powered off and I deleted his task from the active task list and … surprise!! the multicast tasks was cancelled by the daemon

From multicast.log file:

[05-18-17 7:47:47 pm]  | Task (197) Multi-Cast Task is already running with pid: 17556.
[05-18-17 7:47:57 pm]  | Task (197) Multi-Cast Task is no longer running.
[05-18-17 7:47:57 pm]  | Task (197) Multi-Cast Task has been cancelled.
[05-18-17 7:48:07 pm]  * No tasks found!

the udp-sender command in the server was killed and the two host powered on are waiting forever :)

[Fernando Gietz]

Thank you :)

[Tom Elliott]

I’ll work on this, I still don’t like it much due to how we create tasks.

I’ve moved it from bugs to feature requests as that’s what this sounds like to me.

[Fernando Gietz]

The situation:

I send a multicast task to 30 hosts and the image has 3 partitions.
For several causes someones of these hosts doesn’t power on (the net wire is not connected, the WOL packet doen’t reach to the host …). At last 25 hosts are power on and 5 power off. The task begins and, after timeout, the download process begins in 25 hosts, you go to the classroom and … Oh my God!!! I need all PC for the next hour!!! You can not stop the task because has downloaded the middle. The solution would be easy, cancel the five ones, and create a new multicast task with these five.

With the actual behaviour you can do this.

[Tom Elliott]

@Fernando-Gietz The problem is when you create a “grouped” multicast task as you did here, you’re kind of requiring all of those hosts to join in the imaging. So cancelling the task, doesn’t update the whole command. This “mid-imaging” cancellation would cause all the other hosts to fall out.

It’s confusing to try to explain I suppose.

[Fernando Gietz]

Then, is a normal behaviour? :)
I would like not cancel the multicast task.

[Tom Elliott]

Not a bug. The idea of Multicast is to be a “grouped” thing. They would be stuck “waiting forever” at least until the timeout occurred in this case.

The method to use to allow “hosts to come in and leave” would be “multicast session” from the image menu.