Nagios check goes UNKNOWN when check-failed

Bug #1778447 reported by William Grant
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Canonical Livepatch Charm
Fix Released
Medium
Barry Price

Bug Description

check_canonical-livepatch.py returns 3 when it tries to return 2, so goes UNKNOWN rather than critical:

$ /usr/lib/nagios/plugins/check_canonical-livepatch.py
Check failed
<function check_status at 0x7f6050841b90> raised unknown exception '<type 'exceptions.SystemExit'>'
============================================================
Traceback (most recent call last):
  File "/usr/lib/nagios/plugins/nagios_plugin.py", line 32, in try_check
    function(*args, **kwargs)
  File "/usr/lib/nagios/plugins/check_canonical-livepatch.py", line 69, in check_status
    sys.exit(2)
SystemExit: 2
============================================================
$ echo $?
3

Revision history for this message
Haw Loeung (hloeung) wrote :

Related to LP: #1744092 where service is unavailable. I think this plugin should handle it better and keep it critical rather than unknown.

|12:59 <wgrant> I've just had a dozen or so units show up with livepatch check failures
|13:00 <wgrant> Shows up as UNKNOWN in nagios for some reason, but:
|13:00 <wgrant> Bad server status code: 504. URL: https://livepatch.canonical.com/api/machine/aca1b9797a4143adbfdd1da59c4468f4
<html><body><h1>504 Gateway Time-out</h1>#012The server didn't respond in
time.#012</body></html>

Barry Price (barryprice)
Changed in canonical-livepatch-charm:
status: New → Triaged
importance: Undecided → Medium
assignee: nobody → Barry Price (barryprice)
Barry Price (barryprice)
Changed in canonical-livepatch-charm:
status: Triaged → In Progress
Barry Price (barryprice)
Changed in canonical-livepatch-charm:
status: In Progress → Fix Committed
Barry Price (barryprice)
Changed in canonical-livepatch-charm:
status: Fix Committed → Fix Released
Revision history for this message
Barry Price (barryprice) wrote :

Hmm this actually seems to have reintroduced the behaviour rather than fixing it.

I hadn't seen this myself, I'm now wondering if this was perhaps filed after seeing the behaviour in an older deploy...

Changed in canonical-livepatch-charm:
status: Fix Released → In Progress
Revision history for this message
Barry Price (barryprice) wrote :

We'd previously fixed this a year ago:

https://git.launchpad.net/canonical-livepatch-charm/commit/?id=cc09d2f048f96d7964331388afd62fd56387e80e

Which my "fix" in the linked MP above has now undone, so I'm reversing all action taken and we can reexamine this after the weekend.

Revision history for this message
Barry Price (barryprice) wrote :

Sorry about the mess here, first instinct was correct - something went wrong with testing, which is likely another completely separate bug.

I've reinstated the initial fix, and released.

Changed in canonical-livepatch-charm:
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.