A job does not necessarily need a stop on stanza. If it lacks one, any running instances can still be stopped by an Administrator running either of:
initctl stop
stop
4.7.1 Display Runlevel
To display your current and previous runlevels separated by a space character, run the /sbin/runlevel command. Note that if this command is unable to determine the system runlevel, it may display simply "unknown":
$ runlevel
N 2
The output above shows that:
there was no previous runlevel (the system was booted and went straight to the current runlevel).
the current runlevel is "2".
4.7.2 Change Runlevel Immediately
To change runlevel immediately, use one of the commands below:
reboot(8)
shutdown(8)
telinit(8)
6.33 start on
This stanza defines the set of Events that will cause the Job to be automatically started.
Syntax:
start on EVENT [[KEY=]VALUE]... [and|or...]
Each event EVENT is given by its name. Multiple events are permitted using the operators "and" and "or" and complex expressions may be performed with parentheses (within which line breaks are permitted).
You may also match on the environment variables contained within the event by specifying the KEY and expected VALUE. If you know the order in which the variables are given to the event you may omit the KEY.
VALUE may contain wildcard matches and globs as permitted by fnmatch(3) and may expand the value of any variable defined with the env stanza.
Negation is permitted by using "!=" between the KEY and VALUE.
Note that if the job is already running and is not an instance job, if the start on condition becomes true (again), no further action will be taken.
Note that the start on stanza expects a token to follow on the same line. Thus:
# ERROR: invalid
start on
foo or bar
# OK
start on foo or bar
If no environment variables are specified via KEY to restrict the match, the condition will match all instances of the specified event.
See Really understanding start on and stop on for further details.
6.33.1 Normal start
If you are just writing an upstart job that needs to start the service after the basic facilities are up, either of these will work:
start on (local-filesystems and net-device-up IFACE!=lo)
or:
start on runlevel [2345]
The difference in whether to use the more generic 'runlevel' or the more explicit local-filesystems(7) and net-device-up events should be guided by your job's behaviour. If your service will come up without a valid network interface (for instance, it binds to 0.0.0.0, or uses setsockopt(2) SO_FREEBIND), then the runlevel event is preferable, as your service will start a bit earlier and start in parallel with other services.
However if your service requires that a non-loopback interface is configured for some reason (i.e., it will not start without broadcasting capabilities), then explicitly saying "once a non loopback device has come up" can help.
In addition, services may be aggregated around an abstract job, such as network-services:
start on started network-services
The network-services job is a generic job that most network services should follow in releases where it is available. [19] This allows the system administrator and/or the distribution maintainers to change the general startup of services that don't need any special case start on criteria.
We use the started(7) event so that anything that must be started before all network services can do "start on starting network-services".
6.33.2 Start depends on another service
start on started other-service
6.33.3 Start must precede another service
start on starting other-service
Example: your web app needs memcached to be started before apache:
start on starting apache2
stop on stopped apache2
respawn
exec /usr/sbin/memcached
6.34 stop on
This stanza defines the set of Events that will cause the Job to be automatically stopped if it is already running.
Syntax:
stop on EVENT [[KEY=]VALUE]... [and|or...]
Like the stop on stanza, start on expects a token to follow on the same line:
# ERROR: invalid
stop on
foo or bar
# OK
stop on foo or bar
See start on for further syntax details.
6.34.1 Normal shutdown
stop on runlevel [016]
Or if a generic job is available such as network-services [19]
stop on stopping network-services
6.34.2 Stop before depended-upon service
stop on stopping other-service
Note that this also will stop when other-service is restarted, so you will generally want to couple this with the start on condition:
start on started other-service
6.34.3 Stop after dependent service
stop on stopped other-service
6.28 respawn
Note
If you are creating a new Job Configuration File, do not specify the respawn stanza until you are fully satisfied you have specified the expect stanza correctly. If you do, you will find the behaviour potentially very confusing.
Without this stanza, a job that exits quietly transitions into the stop/waiting state, no matter how it exited.
With this stanza, whenever the main script/exec exits, without the goal of the job having been changed to stop, the job will be started again. This includes running pre-start, post-start and post-stop. Note that pre-stop will not be run.
There are a number of reasons why you may or may not want to use this. For most traditional network services this makes good sense. If the tracked process exits for some reason that wasn't the administrator's intent, you probably want to start it back up again.
Likewise, for tasks, (see below), respawning means that you want that task to be retried until it exits with zero (0) as its exit code.
One situation where it may seem like respawn should be avoided, is when a daemon does not respond well to SIGTERM for stopping it. You may believe that you need to send the service its shutdown command without Upstart being involved, and therefore, you don't want to use respawn because Upstart will keep trying to start your service back up when you told it to shutdown.
However, the appropriate way to handle that situation is a pre-stop which runs this shutdown command. Since the job's goal will already be 'stop' when a pre-stop is run, you can shutdown the process through any means, and the process won't be re-spawned (even with the respawn stanza).
Note that if a job is respawned, the variable "$PROCESS" will be set to the name of the job process that failed (for example "pre-start" or "main"). See stopped(7) for further details.
Further note that if the job does not specify the respawn limit stanza as well as the respawn stanza, the job will have the default respawn limit applied (see respawn limit).
6.29 respawn limit
Yes, this is different to a plain respawn: specifying respawn limit does not imply respawn.
Syntax:
respawn limit COUNT INTERVAL | unlimited
Example:
# respawn the job up to 10 times within a 5 second period.
# If the job exceeds these values, it will be stopped and
# marked as failed.
respawn
respawn limit 10 5
# respawn the job indefinitely
respawn limit unlimited
Respawning is subject to a limit. If the job is respawned more than COUNT times in INTERVAL seconds, it will be considered to be having deeper problems and will be stopped. Default COUNT is 10. Default INTERVAL is 5 seconds.
To have the job respawn indefinitely, specify an argument of "unlimited". However, care should be taken using this option: does your service really stop that frequently? Should it?
Specifying either COUNT or INTERVAL as 0 (zero) implies unlimited.
Note that respawn only applies to automatic respawns and not the restart(8) command.
If the job has been respawned up to its respawn limit, the variable "$PROCESS" will be set to "respawn" to denote that the respawn limit was reached. See stopped(7) for further details.
Aucun commentaire:
Enregistrer un commentaire