Description of problem: The try: except: handling in beaker-watchdog will not prevent a failed login from crashing the whole service. Version-Release number of selected component (if applicable): 0.7.03 0.8.0 How reproducible: cause a login to fail and beaker-watchdog will exit after it sleeps 20 seconds
Do you mean to say that you want the login error caught and then the program exit nicely, as there is not point for the process to be still running if we can't authenticate. That is to say we should have a nicer exit, but we should still exit.
(In reply to comment #1) > Do you mean to say that you want the login error caught and then the program > exit nicely, as there is not point for the process to be still running if we > can't authenticate. That is to say we should have a nicer exit, but we should > still exit. The patch I proposed will keep trying for the xmlrpc version. It does not deal with the qpid version, Thats where I needed your expertise.
Why do we keep trying though? Perhaps it does more harm then good. Imagine that there's a problem where we can see on the server that the watchdog doesn't seem to be updating properly, an admin goes onto beaker-watchdog and immediately sees that the process is dead, so they know that the beaker-watchdog process is the problem. They could then check the log and see that the Login failed. Otherwise they would check and see that the process is running, and possibly dismiss it as the cause of any problem (although they could always check the logs, but they may not think to) I can see a point in perhaps retrying if it can't make the connection (i.e perhaps the server has temporarily gone away, but will be up in a moment), but if the login fails because the labcontroller.cfg has the wrong user/pass it's not going to fix itself by bombarding the server with doomed login attempts.
So can we distinguish between a invalid login as opposed to a 500 ISE?
No, it seems that kobo won't pass on login errors.
I agree with Dan's assessment here: <dcallagh_work> imho the best behaviour for a daemon is to either refuse to start, or run forever Lets do an initial login before we daemonize and exit non-zero if we can't login. The outstanding issue is how to deal with re-login for the qpid routine..
Seeing as the the nature of watchdog via qpid is not to loop, we should perhaps add a seperate thread to handle a periodic session renewal. I'll add to the existing patch today
Bulk reassignment of issues as Bill has moved to another team.
Qpid-related stuff no longer applies. And I already wrote a patch to make the lab controller daemons log in before daemonising, but due to kobo bug 753006 it doesn't work anyway. So I'm closing this since I don't think there is anything else we can do here.