Project

General

Profile

Actions

Bug #1974

closed

If an error happen during boostrap, the webapp starts but is in a zombie state and the error page is not displayed

Added by François ARMAND over 12 years ago. Updated almost 7 years ago.

Status:
Released
Priority:
2
Category:
System integration
Target version:
Severity:
Major - prevents use of part of Rudder | no simple workaround
UX impact:
User visibility:
Getting started - demo | first install | level 1 Techniques
Effort required:
Priority:
0
Name check:
Fix check:
Regression:

Description

Today, if there is an initialisation error in the inventory endpoint webapp or in Rudder webapp, the application container is nonetheless started but the application does not work. That is the expected behaviour (a servlet container may and generally run several application, it won't be good to have an error on one of them to shutdown the whole thing).

But in our case, we have one application container by application, and we manage the full environment. So it would be much much much more easy to diagnosis a boot error for an admin if the whole application was clearly stopped.

Option I see for now:

  • a System.exit(Int)
    • but that's bad because it brutally stops the servlet container, maybe letting open resources not cleaned
  • a container proprietary method (to be investigated for Jetty)
  • a syscall to a shell script that call the normal app container shutdown (well, I know, it's ugly, but it's the most configurable for an admin who want to add things for that case and portable and simple)

Subtasks 1 (0 open1 closed)

Bug #10654: If an error happen during boostrap, the webapp starts but is in a zombie state and the error page is not displayedReleasedFrançois ARMANDActions

Related issues 5 (0 open5 closed)

Related to Rudder - Architecture #2630: Rudder Webapp and Rudder Inventory should be two different applicationRejectedActions
Related to Rudder - Bug #10567: Infinite "rudder is loading" page if rudder-init didn't runReleasedNicolas CHARLESActions
Related to Rudder - Bug #15387: Clean-up Jetty abort on bootReleasedVincent MEMBRÉActions
Has duplicate Rudder - Bug #1466: Rudder should halt on fatal errors during initializationRejected2011-07-15Actions
Has duplicate Rudder - Bug #10430: Broken pages served by Rudder 4.1 with no explanation (missing JS/CSS due to unavailable LDAP server)RejectedActions
Actions #1

Updated by François ARMAND over 12 years ago

The ideal case for an admin is be able to:

  • run /etc/init.d/theservice start
  • see [FAIL] in red

So that should be acheviable, perhaps with some little tweak of the jetty start-stop script.

For jetty, it seems to be allowed to stop ip from a servlet: http://stackoverflow.com/questions/4650713/jetty-stopping-programatically-causes-1-threads-could-not-be-stopped

Actions #2

Updated by François ARMAND over 12 years ago

  • Target version changed from 18 to 24
Actions #3

Updated by Jonathan CLARKE almost 12 years ago

  • Target version changed from 24 to Ideas (not version specific)
Actions #4

Updated by François ARMAND over 11 years ago

  • Assignee deleted (François ARMAND)
Actions #5

Updated by François ARMAND about 7 years ago

  • Subject changed from Error in webapp bootstrap must prevent full application bootstrap to If an error happen during boostrap, the webapp starts but is in a zombie state
  • Severity set to Minor - inconvenience | misleading | easy workaround
  • User visibility set to Getting started - demo | first install | level 1 Techniques
Actions #6

Updated by François ARMAND about 7 years ago

  • Severity changed from Minor - inconvenience | misleading | easy workaround to Major - prevents use of part of Rudder | no simple workaround

Making it major, because in fact, it is not easy to understand what goes wrong and what should be done. A lot of first time user get stuck at that point.

Actions #7

Updated by François ARMAND almost 7 years ago

  • Related to Bug #10430: Broken pages served by Rudder 4.1 with no explanation (missing JS/CSS due to unavailable LDAP server) added
Actions #8

Updated by François ARMAND almost 7 years ago

  • Subject changed from If an error happen during boostrap, the webapp starts but is in a zombie state to If an error happen during boostrap, the webapp starts but is in a zombie state and the error page is not displayed
  • Priority set to 0

I'm updating the title to convey the other problem: we do have an error page displayed by apache if the webapp is down (answer 500 code or node up), but in the case at hand, we don't even have that page because the application replies, even if it's full of error or without CSS (because of #10430)

Actions #9

Updated by François ARMAND almost 7 years ago

  • Related to Bug #10567: Infinite "rudder is loading" page if rudder-init didn't run added
Actions #10

Updated by François ARMAND almost 7 years ago

So, after looking to it with a fresh eyes, the problem is not in Jetty but in Lift, which is shadowing UnavailableException error and does as if everything is ok: https://groups.google.com/forum/#!topic/liftweb/BHYjE5C-kIk

Putting the bootstrap check out of Lift boot() method will do as we want.

Actions #11

Updated by François ARMAND almost 7 years ago

  • Category changed from Architecture - Code maintenance to System integration
  • Assignee set to François ARMAND
  • Target version changed from Ideas (not version specific) to 3.1.20
Actions #12

Updated by François ARMAND almost 7 years ago

  • Status changed from New to In progress
Actions #13

Updated by François ARMAND almost 7 years ago

  • Status changed from In progress to Pending technical review
  • Assignee changed from François ARMAND to Nicolas CHARLES
  • Pull Request set to https://github.com/Normation/rudder/pull/1642
Actions #14

Updated by François ARMAND almost 7 years ago

  • Status changed from Pending technical review to Pending release
Actions #15

Updated by François ARMAND almost 7 years ago

  • Related to deleted (Bug #10430: Broken pages served by Rudder 4.1 with no explanation (missing JS/CSS due to unavailable LDAP server))
Actions #16

Updated by François ARMAND almost 7 years ago

  • Has duplicate Bug #10430: Broken pages served by Rudder 4.1 with no explanation (missing JS/CSS due to unavailable LDAP server) added
Actions #17

Updated by Vincent MEMBRÉ almost 7 years ago

  • Status changed from Pending release to Released

This bug has been fixed in Rudder 3.1.20, 4.0.5 and 4.1.2 which were released today.

Actions #18

Updated by François ARMAND over 4 years ago

  • Related to Bug #15387: Clean-up Jetty abort on boot added
Actions

Also available in: Atom PDF