Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Hudson-ci/features/Restart Within Hudson

< Hudson-ci‎ | features
Revision as of 16:59, 23 June 2013 by Bobfoster.gmail.com (Talk | contribs) (New page: =Restart Within Hudson= Several Hudson administration changes require Hudson restart. Currently, restart is external, e.g., by sending SIGINT or SIGTERM to the process, by restarting the ...)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Restart Within Hudson

Several Hudson administration changes require Hudson restart. Currently, restart is external, e.g., by sending SIGINT or SIGTERM to the process, by restarting the Hudson application in the server or by using the CLI restart or soft-restart methods. When an administrator makes a change that requires restart to take effect, there should be a restart link or button within Hudson.

Design Approach

A simple way to implement restart is to call Hudson.safeRestart (which is what the CLI method does) which calls Hudson.restart. Unfortunately, restart doesn't work in a number of cases.

  • It doesn't work by default on Windows.
  • It always restarts the entire process, e.g., the server, not just the Hudson application.
  • It is better at stopping the process than restarting it in its correct state, e.g., as a daemon.

Correct restart is, thus, a multi-dimensional problem, different for each OS, service implementation and container (Tomcat, Jetty, GlassFish, etc.). The Lifecycle extension point is not well suited for multi-dimensional invocation, e.g., the OS is X AND the container is Y and (the container does not support single application restart OR the application name in the container is Z). To cover all the possibilites, Lifecycle would need a plugin for every possible combination. By default, it supports only Hudson running in Unix in the embedded Jetty container.

Yet, every system administrator already knows exactly how to restart any running Hudson and already has a command or script to do it correctly. The best and most likely to be correct restart mechanism would leverage those commands/scripts and not try to replace it with Java code. The feature described below does that.

Restart Command

In the Configure System page Hudson admins will be provided the ability to specify a Restart Command to be executed when Hudson.restart is called. Typically, the command would execute a shell script or bat file, though this is not required.

Since the command is presumed to restart Hudson, it may not return at all. If it does return, it is expected to return successfully. If no Restart Command is specified or if the command fails, the current Lifecycle mechanism will be invoked.

If the Restart Command is not specified, the existing Lifecycle mechanism will be invoked.

Default Restart Script

To make it easier for administrators to pre-configure Hudson for proper restart, if a Restart Script is present in HUDSON_HOME the initial value of the Restart Command will be set to invoke the script. The script will be named hudson_restart.extension.

The script must have an extension, e.g., .bat on Windows or .bat, .bat, .bat, etc. on Unix, but it doesn't matter what it is; in all cases, it will be invoked as a program.

The script must be executable.

The script should be specific to the environment in which the HUDSON_HOME is used.

Restart Options

Even if a Restart Script is present in HUDSON_HOME, a Hudson admin may change the Restart Command to do something else, effectively ignoring the script. This may be overridden by the command line switch:

--changeRestartCommand=true|false

If the option is not specified or is specified as true, the admin will be able to reconfigure the Restart Command as above. If it is <false>, the Restart Command will not appear in the Configure System page.

--restartCommand=value

The value of the restartCommand option will be used to initialize the Restart Command. The correct order of initialization is:

  • If --restartCommand is specified, use that.
  • Otherwise, if a Restart Script is present, use a command that invokes the script.
  • Otherwise, the Restart Command is initially not specified.

Back to the top