Tomás Abad 2 months ago • updated by Guillaume Rousse 1 month ago 3

   Before FusionInventory-Agent v2.3.18 the tasks that the agent executed and its order were hard-code defined: first the task Inventory, afterwards the task Deploy, afterwards the task NetDiscovery, and so on (sorry, this probably isn't the real order); the only way to modify that was installing or not the tasks or making use of --no-task option, that was all. But FusionInvenotry-Agent v2.3.18 changed this behaviour.

   FusionInventory-Agent v2.3.18 introduced the new --tasks option with which it was possible not only to indicate which tasks to run but, also, in what order. But not only that, it allowed to run a task more than one time.

   The --tasks option allows to do interesting things. Regarding to deploy packages, for example, it now allows to maintain an inventory more faithful to reality since it isn't necessary to wait for the agent refresh the inventory data so that deployed packages appear in FusionInventory for GLPI.

   Now it's enough to set tasks=Inventory,Deploy,Inventory,... (don't forget the last three dots; it means exactly "and the other tasks") to be sure than a) FusionInventory for GLPI going to have got an up to date information before to try an hipothetical or possible Deploy task execution and b) FusionInventory for GLPI going to have got an up to date information after that hipothetical or possible Deploy task execution.

   The new --tasks option introduces the advantage of modify the task schedules behaviour of the FusionInventory-Agent but it also introduces a side effect not so desirable. The side effect is an inefficient task execution and waste of resources. This is an example.

   Set the --tasks option to Inventory,Deploy,Inventory,... (that is our configuration for more than fifteen thousand computers) is a good choice whether you have planned deploy packages because with it it's possible to maintain an inventory more faithful to reality. And yes, this is true, but you pay a high price in consumption of CPU, time and bandwidth, and not only in the side of the client. Why?. It's very simple. Most of time, the FusionInventory-Agent will not have to do any Deploy task so it will run two consecutive Inventory tasks with practically the same result; and that is a waste of resources.

   But also it's possible to set the --tasks option to esoteric configurations like this: Inventory,Inventory,Inventory,.... And yes, I know this is a stupidity, but this stupidity may be possible.

   I have thought about this problem during some time and I think that there could be a simple solution for both problems (that really are the same): keep track of what has been the last executed task and skip the execution of the next one whether it is of the same kind.

   That is all. Regards,

I agree with this solution, good idea.


Reducing the wast of resources is just mandatory all the time. But I fully agree with the case you exposes. The execution plan can just waste resources if wrongly used.

Also thinking about future 2.4 developments, I think supporting some kind of triggers could be a solution. For example, during a deployment task, we may trigger the event "a software has been installed", then if the condition "trigger an inventory if a new software has been installed" is enabled, then start en inventory asap.


If "avoiding waste of ressource" just means "preprocess the list of scheduled tasks before running any of them, so as to coalesce consecutive tasks of the same type" (additional question: what about two consecutive tasks, but with different options, such as a SNMP-only network discovery, then an ICMP only one ?), that's quite easy to do, but it is just some hardcoded safeguard for unwary users. Harmless, but useless: for this kind of issue, a better documentation would be a  better solution IMHO.

Introducing an event systems and predicate languages allowing to express conditional chaining of actions, however, would be much more useful, I think, but it seems unrealistic. The day we'll have a documented, comprehensive and consistent import rules systems, for comparison with a similar subsytem, allowing every users to efficiently manage discovery of new devices without having to ask for help, I may reconsider my thought.

A much simpler way to avoid wasting resources, without introducing software complexity, which is supposed to happen in 2.4, is to switch from the 'opt-out' inventory mode, where you have to exclude unwanted inventory elements, from an 'opt-in' mode, where you have to explicitly select what you want.