Incomplete timeout information
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
UTAH |
Fix Released
|
Low
|
Javier Collado |
Bug Description
When looking at rsyslog related timeout problems, it turns out that there is
some information that is missing and that should be useful to troubleshoot
problem. For example, in this log:
-------
Apr 1 09:48:29 finish-install: info: Running /usr/lib/
...
Traceback (most recent call last):
...
raise UTAHException(
UTAHException: Timeout occurred for system booted
-------
The pattern that was matched probably was "94save-logs" and the exception was
raised after 180 seconds (as in the default configuration file). However, it
would be a good idea to have these two pieces of information to be sure that
the timeout wasn't because of a configuration problem (being that another
pattern matched or that the timeout value is different than the default value).
Related branches
- Andy Doan (community): Approve
- Javier Collado (community): Needs Resubmitting
-
Diff: 43 lines (+12/-1) (has conflicts)2 files modifieddebian/changelog (+4/-0)
utah/provisioning/rsyslog.py (+8/-1)
Changed in utah: | |
status: | New → Triaged |
importance: | Undecided → Low |
assignee: | nobody → Javier Collado (javier.collado) |
Changed in utah: | |
status: | Triaged → In Progress |
Changed in utah: | |
status: | In Progress → Fix Committed |
Changed in utah: | |
status: | Fix Committed → Fix Released |