Bug 1823545

This issue is caused by the removal of the libssh library in restraint 0.2.0.

/usr/bin/extendtesttime.sh is created by /distribution/reservesys, which runs once, on first boot.

When the script is created, RSTRNT_RECIPE_URL is hard coded. This variable contains hostname and port for restraintd, and it's used by rstrnt-adjust-watchdog,

 export RSTRNT_RECIPE_URL=http://localhost:39673/recipes/42

In 0.2.0, the port for restraintd is dynamic. A new port is randomly chosen for each run. So after the reboot, the value in RSTRNT_RECIPE_URL is no longer valid, because restraintd is not listening on that port.

We can solve this by making restraintd port persist after reboot. Meanwhile, as a workaround, current restraintd port can be checked in journal,

 journalctl -u restraintd

 Apr 14 05:29:24 hostname restraintd[4242]: Listening on http://localhost:34507
 Apr 14 05:29:24 hostname restraintd[4242]: * Fetching recipe: http://labcontroller:8000//recipes/30363/

Then rstrnt-adjust-watchdog can be used passing RECIPE_URL variable with correct port and recipe, like,

 RECIPE_URL=http://localhost:34507/recipes/30363 rstrnt-adjust-watchdog 50h

Daniel:

Perhaps you'd like to take advantage of

rstrnt-adjust-watchdog -c --pid <pid of restraint service> 50h

Carol

(In reply to Daniel Rodríguez from comment #1)
> This issue is caused by the removal of the libssh library in restraint 0.2.0.
> 
> /usr/bin/extendtesttime.sh is created by /distribution/reservesys, which
> runs once, on first boot.
> 
> When the script is created, RSTRNT_RECIPE_URL is hard coded. This variable
> contains hostname and port for restraintd, and it's used by
> rstrnt-adjust-watchdog,
> 
>  export RSTRNT_RECIPE_URL=http://localhost:39673/recipes/42
> 
> In 0.2.0, the port for restraintd is dynamic. A new port is randomly chosen
> for each run. So after the reboot, the value in RSTRNT_RECIPE_URL is no
> longer valid, because restraintd is not listening on that port.
> 
> We can solve this by making restraintd port persist after reboot. Meanwhile,
> as a workaround, current restraintd port can be checked in journal,
> 
>  journalctl -u restraintd
> 
>  Apr 14 05:29:24 hostname restraintd[4242]: Listening on
> http://localhost:34507
>  Apr 14 05:29:24 hostname restraintd[4242]: * Fetching recipe:
> http://labcontroller:8000//recipes/30363/
> 
> Then rstrnt-adjust-watchdog can be used passing RECIPE_URL variable with
> correct port and recipe, like,
> 
>  RECIPE_URL=http://localhost:34507/recipes/30363 rstrnt-adjust-watchdog 50h

Thank you for the quick response with an effective work-around.

                       -Lenny.

(In reply to Carol Bouchard from comment #2)
> Daniel:
> 
> Perhaps you'd like to take advantage of
> 
> rstrnt-adjust-watchdog -c --pid <pid of restraint service> 50h
> 
> Carol

 rstrnt-adjust-watchdog from restraint-0.2.0-1.el8bkr.aarch64 does not have the -c nor --pid options.

Is this something available in a newer version?

                       -Lenny.

Lenny:

My comment on arguments for rstrnt-adjust-watchdog pertains to newer code not yet released.  These are arguments which are useful when working outside a job.  More details coming for next release.

Carol

Another workaround is to use the bkr tool from an external system, e.g., your laptop.

I was able to add 48 hours to this /distribution/reservesys task:
  https://beaker.engineering.redhat.com/recipes/8137732#task108995117

By running from my laptop:
  $ bkr watchdog-extend --by=$((60 * 60 * 48)) T:108995117

This issue is fixed in https://github.com/beaker-project/restraint/pull/31

In 0.2.1, the port for the restraintd running as a service in the system will be static by default, set to 8081. Therefore, variables in extendtesttime.sh will be valid after reboot.