I run EVE PRO 4.0.1-65 and we are encountering slight issue with startup-config on JunOS VCP as of 21.4R1.
I promise my cluster and satellite are not overloaded with heavy labs. I shut all the labs but mine and i only started 2 nodes. This is a vendor-version related issue.
JunOS 21.2 and lower are getting their startup-config loaded without any problem.
JunOS 21.4 images take longer to start and the timeout value that is used by the wrapper (300sec) is too short. The box hasn't finished to boot when 300sec timer expires. Therfore startup-config is not loaded
For teh reccord, here is the unl_wrapper log that shows the 300sec timer.
Code: Select all
Jan 14 20:46:53 INFO: importing nohup sh -c '/opt/unetlab/config_scripts/config_vmxvcp.py -a put -p 36809 -f /opt/unetlab/tmp/1/6bc93f36-b1dd-4695-b124-8043b3665d18/10/startup-config -t 300 > /dev/null 2>&1 && rm /opt/unetlab/tmp/1/6bc93f36-b1dd-4695-b124-8043b3665d18/10.lock' >/dev/null &QUESTION:
Is there a clean way to increase this timeout value in EVE for a specific vendor (Juniper) or in general in an official release/update ? Or to modify the value for a specific vendor version (or a list of versions) ?
For the time being, i modified the config_vmxvcp.py script itself by making it forget about the <-t> option value given in argument and override it with 600sec but I assume this could lead to other issues in other scenarios, couldn't it ? And anyway, after the next EVE upgrade, the modification could be overwritten
Furthermore, other customers might also be facing this issue sooner or later I guess, nope ?PS : When I manually launch the same CLI (when the box is fully loaded), this works fine but I cannot tell every user to log as root the the master and look for the port and launch the CLI
