Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1601566 - Default timeouts are the same for one command as for all commands per insights client run.
Summary: Default timeouts are the same for one command as for all commands per insight...
Alias: None
Product: Red Hat Insights
Classification: Red Hat
Component: Client
Version: unspecified
Hardware: Unspecified
OS: Linux
Target Milestone: ---
Assignee: jcrafts
QA Contact: Jeff Needle
Depends On:
TreeView+ depends on / blocked
Reported: 2018-07-16 17:29 UTC by Dave Baker
Modified: 2018-09-25 13:28 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2018-09-25 13:28:18 UTC
Target Upstream Version:

Attachments (Terms of Use)

Description Dave Baker 2018-07-16 17:29:38 UTC
Description of problem:

The default cmd_timeout for one (each) command in the insights-client run is the same as the overall watchdog timeout for all to run.

The effect of this is that a single command timing out causes the entire client run to fail.

Version-Release number of selected component (if applicable):


How reproducible:

Depends on server.  I can reproduce on demand on a server that happens to take approx 50 minutes (!) to run "lsof", which is one of the data gathering commands.

Steps to Reproduce:
1. Run insights-client
2. Look at log file and/or insights web interface and confirm system still reports as being stale.

Actual results:

One command timing out causes no data to upload to insights system.

Expected results:

I would expect multiple sub-commands to need to time out before the entire client timed out.

Additional info:

The default "cmd_timeout" is 600s, which can be overridden in /etc/insight-client/insight-client.conf.

The overall watchdog timeout is 600s, which is set in /usr/lib/systemd/system/insights-client.service

Setting the first one lower, or the second one higher, permits a single command timeout to be ignored.

My tentative workaround is to lower cmd_timeout to 180s.  This means three commands can timeout (taking 9m total) and the whole process can still succeed so long that the remaining commands and data upload all take place within the remaining 1m of the watchdog timer.

Comment 1 Pavlo Yakovlev 2018-09-25 13:26:46 UTC
Currently we have PR (  and changed the timeout for each command from 10 min. to 3 min.

Note You need to log in before you can comment on or make changes to this bug.