upstart

       /etc/init/
              Default location of system job configuration files.

       $XDG_CONFIG_HOME/upstart/, $XDG_CONFIG_DIRS/upstart/
              Default locations of user session job configuration files.

       $HOME/.init/
              Deprecated  location of user job configuration files (still hon-
              oured by User Session Mode).

DESCRIPTION
       On startup, the Upstart init(8) daemon reads its job configuration from
       files  in  the  /etc/init/ directory by default, and watches for future
       changes to these files using inotify(7).

       If Upstart was invoked as a user process with --user  option,  it  will
       run in User Session mode. See User Session Mode for further details.

       To be considered by Upstart, files in this directory must have a recog-
       nized suffix and may also be present in sub-directories.  There are two
       recognized suffixes:

       o   Files  ending  in  .conf  are called configuration files, or simply
           "conf files" for short.  These are the primary vehicle for specify-
           ing a job.

       o   Files  ending  in .override are called override files.  If an over-
           ride file is present, the stanzas it contains take precedence  over
           those equivalently named stanzas in the corresponding configuration
           file contents for a particular job.   The  main  use  for  override
           files  is to modify how a job will run without having to modify its
           configuration file directly.  See the section  Override  File  Han-
           dling below for further details.

       A job can thus be defined by either:

       o A single configuration file.

       o A single configuration file and a single override file.

       Unless  explicitly stated otherwise, any reference to a jobs configura-
       tion can refer both to a configuration file or an override file.

       Each configuration file defines  the  template  for  a  single  service
       (long-running process or daemon) or task (short-lived process).

       Note that a configuration file is not itself a job: it is a description
       of an environment a job could be run in.  A job is the runtime  embodi-
       ment of a configuration file.

       The  configuration  file  name  as  displayed by Upstart and associated
       tooling is taken from its relative path within  the  directory  without
       the   extension.    For  example  a  configuration  file  /etc/init/rc-
       sysinit.conf  is  named  rc-sysinit,   while   a   configuration   file
       Note that this facility is distinct from the chroot stanza (see Process
       environment below).

   User Session Mode
       Upstart  can manage complete User Sessions. In this mode it runs with a
       process id greater than 1 and will read job  configuration  files  from
       the following list of directories in the order shown:

       o   $XDG_CONFIG_HOME/upstart/

       o   $HOME/.init/

       o   $XDG_CONFIG_DIRS/upstart/

       o   /usr/share/upstart/sessions/

       Note  that the first directory to contain a job is considered the owner
       of that job name: any subsequently searched directory that  contains  a
       job  of  the  same  name will be ignored. The same applies for override
       files: only the first override file found in the search order  will  be
       applied.  Note  that  an  override file can be in the same directory or
       earlier to that directory which contains the job file.

       Jobs in these locations are expected  to  launch  the  user's  session.
       Upstart  will  try  to  parent  all  spawned  process  with  the aid of
       prctl(2).  If successful this will ensure that even double-forking dae-
       mons  will  be  reparented  to the User Session process, and not to the
       init(8) daemon running with process id 1.

       When running in User Session mode, Upstart will kill all job  processes
       on session logout or shutdown.

       All  log  output  will  be in $XDG_CACHE_HOME/upstart which defaults to
       $HOME/.cache/upstart

   Configuration File Format
       Each line begins with a configuration stanza and continues until either
       the end of the line or a line containing a closing stanza.  Line breaks
       within a stanza are permitted within single or  double  quotes,  or  if
       preceded by a blackslash.

       If  a  stanza  is duplicated, the last occurence will be used. Unrecog-
       nized stanzas will generate parse errors, which will stop  a  job  from
       running.

       Stanzas and their arguments are delimited by whitespace, which consists
       of one or more space or tab  characters  which  are  otherwise  ignored
       unless placed within single or double quotes.

       Comments  begin  with  a  `#'  and  continue until the end of the line.
       Blank lines and lines consisting only of  whitespace  or  comments  are
       ignored.

   Process definition

       exec COMMAND [ ARG ]...
              This stanza defines the process to be run as the name of an exe-
              cutable  on  the  filesystem,  and  zero or more arguments to be
              passed to it.  Any special characters, e.g. quotes or `$' speci-
              fied  will  result in the entire command being passed to a shell
              for expansion.

              exec /usr/sbin/acpid -c $EVENTSDIR -s $SOCKET

       script ... end script
              This stanza defines the process to be run as a shell script that
              will  be  executed  using  sh(1).  The -e shell option is always
              used, so any command that fails will terminate the script.

              The script stanza appears on its own on a line,  the  script  is
              everything up until the first end script stanza appearing on its
              own on a line.

              script
                  dd bs=1 if=/proc/kmsg of=$KMSGSINK
                  exec /sbin/klogd -P $KMSGSINK
              end script

       There are an additional four processes that may be run as part  of  the
       job's  lifecycle.  These are specified as the process name, followed by
       an exec or script stanza.

       pre-start exec|script...
              This process will be run after the job's starting(7)  event  has
              finished,  but  before the main process is run.  It is typically
              used to prepare the environment, such as making necessary direc-
              tories,  and  it may also call the stop(8) command without argu-
              ments to cancel the start.

       post-start exec|script...
              This process will be run before the job's  started(7)  event  is
              emitted,  but  after  the  main process has been spawned.  It is
              typically used to send necessary commands to the  main  process,
              or to delay the started(7) event until the main process is ready
              to receive clients.

       pre-stop exec|script...
              This process is run if the job is stopped by an event listed  in
              its  stop  on  stanza or by the stop(8) command.  It will be run
              before the job's stopping(7) event is  emitted  and  before  the
              main process is killed.  It is typically used to send any neces-
              sary shutdown commands to the main process, and it may also call
              the start(8) command without arguments to cancel the stop.

       post-stop exec|script...
              This  process  is run after the main process has been killed and
              before the job's stopped(7) event is emitted.  It  is  typically
              used  to  clean  up  the environment, such as removing temporary

       Jobs can be manually started and stopped at any time by a system admin-
       istrator  using  the start(8) and stop(8) tools, however it is far more
       useful for jobs to be started and stopped automatically by the  init(8)
       daemon when necessary.

       This  is  done  by  specifying which events should cause your job to be
       started, and which cause your process to be stopped again.

       The set of possible events is limitless, however there are a number  of
       standard events defined by the init(8) daemon and telinit(8) tools that
       you will want to use.

       When first started, the init(8) daemon will emit the startup(7)  event.
       This  will  activate jobs that implement System V compatibility and the
       runlevel(7) event.  As jobs are started and stopped, the init(8) daemon
       will  emit  the  starting(7),  started(7),  stopping(7)  and stopped(7)
       events on their behalf.

       start on EVENT [[KEY=]VALUE]... [and|or...]
              The start on stanza defines the set of events  that  will  cause
              the job to be automatically started.  Each EVENT is given by its
              name.  Multiple events are permitted using the and & or  logical
              operators,  and complex expressions may be performed with paren-
              theses (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.

              If  an event is emitted for which no jobs have registered inter-
              est (via either start on or stop on), the event is destroyed.

              If a job specifies a single event in  its  start  condition  and
              that  event  is emitted and matches any specifies event environ-
              ment variables, the overall condition becomes true, the  job  is
              started  and -- assuming no other job has registered an interest
              in it -- the event is destroyed.

              However, if an event is emitted which matches  part  of  a  jobs
              start condition, the job is said to be blocking the event (since
              the event is unable to change state until the job  has  started)
              and  will both cause the event to persist and the job start con-
              dition to be marked as partially completed. Once all  events  in
              the  start  condition  have  been emitted, the overall job start
              condition becomes true and the job will be started. If no  other
              jobs  have registered interest in the events in the start condi-
              tion, they will then be destroyed.
              very  simple  expressions (between one and four events as a very
              approximate guide). A large number  or  complex  combination  of
              events  is  often  an  indication  that  the condition should be
              refactored.

              Examples of start on conditions:

              start on started gdm or started kdm

              start on stopped JOB=foo RESULT=failed PROCESS=pre-start

              start on device-added SUBSYSTEM=tty DEVPATH=ttyS*

              start on net-device-added INTERFACE!=lo

              start on (A and B C=D and E F=G)

       stop on EVENT [[KEY=]VALUE]... [and|or...]
              The stop on stanza defines the set of events that will cause the
              job  to  be  automatically  stopped.   It has the same syntax as
              start on.

              VALUE may additionally expand the value  of  any  variable  that
              came  from  the job's start environment (either the event or the
              command that started it).

              Examples of stop on conditions:

              stop on A

              stop on starting B and stopped JOB=C

              stop on stopping gdm or stopping kdm

              stop on device-removed DEVPATH=$DEVPATH

       manual This stanza will disregard any previously seen start on  defini-
              tion.  By adding this stanza on any line below the start on def-
              inition, it provides the ability to stop a job from being  auto-
              matically started.  When specified, the only way to start such a
              job is via start (8).

   Job environment
       Each job is run with an environment constructed from the following cat-
       egories:

       o   A minimal set of standard system variables added by Upstart.

           All jobs contain the TERM and PATH variables.

       o   Variables  set  using the initctl(8) job environment commands (such
           as set-env).

           These commands also allow unsetting of variables.
           The  special  UPSTART_EVENTS environment variable contains the list
           of events that started the job, it will not be present if  the  job
           was started manually.

           The  pre-stop and post-stop scripts are run with the environment of
           the   events   or   commands   that   stopped   the    job.     The
           UPSTART_STOP_EVENTS  environment  variable  contains  the  list  of
           events that stopped the job, it will not be present if the job  was
           stopped manually.

       o   Variables  set within the job itself using the env and export stan-
           zas. These provide default values - if the command or  event  which
           causes  the  job  to  start specifies alternative values, those are
           given priority over the defaults.

           env KEY[=VALUE]
                  Defines a default environment variable, the value  of  which
                  may  be  overridden  by the event or command that starts the
                  job.  If 'KEY=VALUE' is specified, the variable KEY is given
                  the  value VALUE.  If only 'KEY' is given, then the value is
                  taken from the init(8) daemon's own environment.

           export KEY...
                  Exports the value of one or more environment variables  into
                  the  starting(7),  started(7),  stopping(7)  and  stopped(7)
                  events for this job and to all resultant  events  (not  just
                  those relating to the current job).

                  Note that each KEY is the name of a variable; it is not pre-
                  fixed with a dollar ('$') sign.

       The first two categories above comprise the job environment table which
       is  applied  to  all jobs. Note that changing the job environment table
       will only affect newly-started jobs.

   Services, tasks and respawning
       Jobs are services by default.  This means that the act of starting  the
       job is considered to be finished when the job is running, and that even
       exiting with a zero exit status means the service will be respawned.

       task   This stanza may be used to  specify  that  the  job  is  a  task
              instead.   This  means  that  the act of starting the job is not
              considered to be finished until the job itself has been run  and
              stopped  again,  but  that exiting with a zero exit status means
              the task has completed successfully and will not be respawned.

       The start(8) command, and any starting(7) or  stopping(7)  events  will
       block only until a service is running or until a task has finished.

       respawn
              A service or task with this stanza will be automatically started
              if it should stop abnormally.  All reasons for a  service  stop-
              ping,  except  the stop(8) command itself, are considered abnor-
              mal.  Tasks may exit with a zero exit status  to  prevent  being
              will be  respawned  indefinitely.  Specifying  either  COUNT  or
              INTERVAL as zero implies unlimited.

              This  stanza  only  applies  to  automatic  respawns and not the
              restart(8) command.

       normal exit STATUS|SIGNAL...
              Additional exit statuses or even signals may be  added,  if  the
              job  process terminates with any of these it will not be consid-
              ered to have failed and will not be respawned. A signal  can  be
              specified  either  as  a  full name (for example "SIGTERM") or a
              partial name (for example "TERM").

              normal exit 0 1 TERM SIGHUP

   Instances
       By default, only one instance of any job is permitted to exist  at  one
       time.   Attempting to start a job when it's already starting or running
       results in an error. Note that a job is considered to be running if its
       pre-start process is running.

       Multiple  instances  may  be  permitted  by defining the names of those
       instances.  If an instance with the same name is not  already  starting
       or  running,  a  new  instance  will be started instead of returning an
       error.

       instance NAME
              This stanza defines the names of instances, on its own  its  not
              particularly  useful  since it would just define the name of the
              single permitted instance, however  NAME  expands  any  variable
              defined in the job's environment.

              These  will  often  be  variables  that  you need to pass to the
              process anyway, so are an excellent way to limit the instances.

              instance $CONFFILE
              exec /sbin/httpd -c $CONFFILE

              instance $TTY
              exec /sbin/getty -8 38300 $TTY

              These jobs appear in the initctl(8)  output  with  the  instance
              name  in parentheses, and have the INSTANCE environment variable
              set in their events.

   Documentation
       Upstart provides several stanzas useful for documentation and  external
       tools.

       description DESCRIPTION
              This stanza may contain a description of the job.

              description "This does neat stuff"


       emits EVENT...
              All processes on the system are free to emit their own events by
              using the initctl(8) tool, or by communicating directly with the
              init(8) daemon.

              This stanza allows a job to document in  its  job  configuration
              what events it emits itself, and may be useful for graphing pos-
              sible transitions.

              The initctl(8) check-config command attempts to use this  stanza
              to resolve events.

              EVENT can be either a literal string or a string including shell
              wildcard meta-characters (asterisk ('*'), question  mark  ('?'),
              and  square brackets ('[' and ']')).  Meta-characters are useful
              to allow initctl(8) check-config to resolve a class  of  events,
              such as those emitted by upstart-udev-bridge(8).

       usage USAGE
              This  stanza  may contain the text used by initctl(8) usage com-
              mand. This text  may  be  also  shown  when  commands  start(8),
              stop(8) or status(8) fail.

              usage "tty DEV=ttyX - where X is console id"

   Process environment
       Many  common  adjustments  to the process environment, such as resource
       limits, may be configured directly in the job  rather  than  having  to
       handle them yourself.

       console none|log|output|owner
              none
                     If  none  is specified, the jobs standard input, standard
                     output and standard error file descriptors are  connected
                     to /dev/null.  Any output generated by a job will be dis-
                     carded.  This used to be the default prior to the  intro-
                     duction of log in Upstart 1.4.

              log
                     If  log  is  specified,  standard  input  is connected to
                     /dev/null, and standard output  and  standard  error  are
                     connected to a pseudo-tty which logs all job output.

                     Output  is logged to file /var/log/upstart/<job-log-file>
                     or $XDG_CACHE_HOME/upstart/<job-log-file> for system  and
                     user session jobs respectively.

                     If  a  job  has  specified  instance, <job-log-file> will
                     equate  to  <job>-<instance>.log  where  '<instance>'  is
                     replaced  by  the  specific instance value and '<job>' is
                     replaced with the job name (job configuration file  name,
                     without  the  extension).   If instance is not specified,
                     <job-log-file>  will  be  <job>.log  where   '<job>'   is
                     structure.

                     If the directory for system jobs does not exist, job out-
                     put for each job will be cached until the  job  finishes.
                     Thus,  the boot process must ensure that the directory is
                     available as soon as possible since any job that finishes
                     before  a writeable disk is available will not be able to
                     take advantage of this facility.

                     If it is not possible to write to any  log  file  due  to
                     lack  of  disk  space, the job will be considered to have
                     specified a console value of none and all subsequent  job
                     output will be discarded.

                     If  the logger detects that the file it is about to write
                     to was deleted, it will re-open the file first.

                     Care should be taken if the  log  directory  is  a  mount
                     point  since  any  job  that  starts before that mount is
                     available and which produces output will then attempt  to
                     write  logs to the mount point, not to the mounted direc-
                     tory. This may give the impression that log data has  not
                     been  recorded. A strategy to handle this situation is to
                     ensure the mount point directory is  not  writeable  such
                     that  logs  will  only be written when the mount has suc-
                     ceeded (assuming the mount itself is  writeable  and  has
                     sufficient space).

                     Note  that  since  log  utilizes pseudo-ttys, your kernel
                     must support these. If it does  not,  the  console  value
                     will  be  modified  automatically to none.  Further, note
                     that it may be necessary to increase the number of avail-
                     able pty devices; see pty(7) for details.

                     Under  Linux,  full Unix 98 pty support requires that the
                     devpts filesystem be mounted.

                     If pty setup fails for any reason, an error message  will
                     be displayed and the job's console value will be reset to
                     none.

              output
                     If output is specified, the standard input, standard out-
                     put  and standard error file descriptors are connected to
                     /dev/console.

              owner
                     The owner value is special: it not only connects the  job
                     to the system console but sets the job to be the owner of
                     the system console, which means it will  receive  certain
                     signals  from  the  kernel  when special key combinations
                     such as Control-C are pressed.

       umask UMASK
              ADJUSTMENT may be an integer value from -999 (very  unlikely  to
              be  killed  by  the  OOM  killer)  up to 1000 (very likely to be
              killed by the OOM killer).  It may also  be  the  special  value
              never to have the job ignored by the OOM killer entirely.

       chroot DIR
              Runs  the  job's processes in a chroot(8) environment underneath
              DIR

              Note that DIR must have all the necessary system  libraries  for
              the process to be run, often including /bin/sh

       chdir DIR
              Runs the job's processes with a working directory of DIR instead
              of the root of the filesystem.

       limit LIMIT SOFT|unlimited HARD|unlimited
              Sets initial system resource limits  for  the  job's  processes.
              LIMIT  may  be one of core, cpu, data, fsize, memlock, msgqueue,
              nice, nofile, nproc, rss, rtprio, sigpending or stack.

              Limits are specified as both a SOFT value and a HARD value, both
              of which are integers.  The special value unlimited may be spec-
              ified for either.

       setuid USERNAME
              Changes to the user USERNAME before running any job process.

              The job process will run with the primary group of user USERNAME
              unless  the  setgid  stanza is also specified in which case that
              group will be used instead.

              For system jobs initgroups(3) will be called to set  up  supple-
              mentary group access.

              Failure  to  determine  and/or  set  user and group details will
              result in the overall job failing to start.

              If this stanza is unspecified, all job processes will  run  with
              user  ID 0 (root) in the case of system jobs, and as the user in
              the case of user jobs.

              Note that system jobs using the setuid stanza are  still  system
              jobs, and can not be controlled by an unprivileged user, even if
              the setuid stanza specifies that user.

       setgid GROUPNAME
              Changes to the group GROUPNAME before running any job process.

              For system jobs initgroups(3) will be called to set  up  supple-
              mentary group access.

              If  this  stanza  is  unspecified, the primary group of the user
              specified in the setuid block is used for all job processes.  If

              This  stanza  will also be ignored if the init(8) daemon has had
              cgroup support disabled at boot time (see init (8)).

              A job which specifies this stanza will not be started until both
              its start on condition is met and the address of the cgroup man-
              ager has been communicated  to  the  init(8)  daemon  using  the
              initctl(8) command notify-cgroup-manager-address.

              If only the cgroup controller (such as memory, cpuset, blkio) is
              specified, a job-specific cgroup will be  created  and  the  job
              processes placed in it. The form of this cgroup is

              upstart/$UPSTART_JOB

              or  if  the  job specifies the instance stanza the group will be
              the expanded value of:

              upstart/$UPSTART_JOB-$UPSTART_INSTANCE

              Any forward slashes in $UPSTART_JOB and  $UPSTART_INSTANCE  will
              be replaced with underscore ('_') characters.

              This  default  cgroup  for  the  job may be specified explicitly
              within a NAME using the special variable $UPSTART_CGROUP.   This
              variable is not an environment variable and is only valid within
              the context of the cgroup stanza.

              If NAME is not specified or does  not  contain  $UPSTART_CGROUP,
              the job processes will not be placed in an upstart-specific

              Note that this special variable cannot be specified with enclos-
              ing braces around the name.

              No validation is performed on the specified values until the job
              is due to be started.

              If  the  CONTROLLER is invalid, or the NAME cannot be created or
              the KEY or VALUE are invalid, the job will be failed.

              The NAME argument may contain any valid variable  and  can  also
              contain  forward  slashes  to  run  the  job processes in a sub-
              cgroup.

              If any argument contains space characters, it must be quoted.

              If a KEY is specified, a VALUE must also be specified  (even  it
              is simply an empty string).

              The  stanza  maybe  specified multiple times. The last occurence
              will be used except in the scenario where each occurence  speci-
              fies  a different KEY in which case all the keys and values will
              be applied.


              Explicit name with setting.
                     cgroup CONTROLLER NAME KEY VALUE

              Examples:

              o      Run all job processes in  the  default  cpu  cgroup  con-
                     troller group.

                     cgroup cpu

              o      As above.

                     cgroup cpu $UPSTART_CGROUP

              o      As above.

                     cgroup cpu "$UPSTART_CGROUP"

              o      Attempt  to place the job processes in a non-job-specific
                     cgroup.

                     cgroup cpu "a-well-known-cgroup"

              o      The job will only start once the manager is up  and  run-
                     ning  and will have a 50MB memory limit, be restricted to
                     CPU ids 0 and 1 and have a 1MB/s write limit to the block
                     device 8:16. The job will fail to start if the system has
                     less than 50MB of RAM or less than 2 CPUs.

                     cgroup memory $UPSTART_CGROUP limit_in_bytes 52428800
                     cgroup cpuset $UPSTART_CGROUP cpus 0-1
                     cgroup blkio slowio throttle.write_bps_device "8:16 1048576"

   Override File Handling
       Override files allow a jobs environment to be changed without modifying
       the jobs configuration file. Rules governing override files:

       o If  a job is embodied with only a configuration file, the contents of
         this file define the job.

       o If an override files exists where there is no  existing  cofiguration
         file, the override file is ignored.

       o If both a configuration file and an override file exist for a job and
         both files are syntactically correct:

         o stanzas in the override file  will  take  precedence  over  stanzas
           present in the corresponding configuration file.

         o stanzas  in  the  override file which are not present in the corre-
           sponding configuration file will be honoured when the job runs.

       o If both a configuration file and an override file exist for a job and
         file  is  ignored and only the contents of the configuration file are
         considered.

   AppArmor support
       Upstart provides several stanzas for loading and switching to different
       AppArmor  profiles.  If AppArmor isn't enabled in the currently running
       kernel, the stanzas will be silently ignored.

       apparmor load PROFILE
              This stanza specifies an AppArmor profile to load into the Linux
              kernel  at  job  start. The AppArmor profile will confine a main
              process automatically using  path  attachment,  or  manually  by
              using  the  apparmor switch stanza.  PROFILE must be an absolute
              path to a profile and a failure will occur if the  file  doesn't
              exist.

              apparmor load /etc/apparmor.d/usr.sbin.cupsd

       apparmor switch NAME
              This  stanza  specifies  the name of an AppArmor profile name to
              switch to before running the main process.   NAME  must  be  the
              name  of a profile already loaded into the running Linux kernel,
              and will result in a failure if not available.

              apparmor switch /usr/sbin/cupsd

   Miscellaneous
       kill signal SIGNAL
              Specifies the stopping signal, SIGTERM by default, a job's  main
              process  will  receive when stopping the running job. The signal
              should be specified as a full name (for example "SIGTERM") or  a
              partial  name  (for example "TERM"). Note that it is possible to
              specify the signal as a number (for example "15") although  this
              should  be  avoided  if at all possible since signal numbers may
              differ between systems.

              kill signal INT

       reload signal SIGNAL
              Specifies the reload signal, SIGHUP by  default,  a  job's  main
              process  will receive when reloading the running job. The signal
              should be specified as a full name (for example "SIGHUP")  or  a
              partial  name  (for  example "HUP"). Note that it is possible to
              specify the signal as a number (for example "1")  although  this
              should  be  avoided  if at all possible since signal numbers may
              differ between systems.

              reload signal USR1

       kill timeout INTERVAL
              Specifies the interval between sending the  job's  main  process
              the "stopping" (see above) and SIGKILL signals when stopping the
              running job. Default is 5 seconds.

              and will wait  for  this  to  occur  before  running  the  job's
              post-start script or considering the job to be running.

              Without  this  stanza init(8) is unable to supervise daemon pro-
              cesses and will believe them to have stopped  as  soon  as  they
              daemonise on startup.

       expect fork
              Specifies that the job's main process will fork once after being
              run.  init(8) will follow this fork, and will wait for  this  to
              occur  before running the job's post-start script or considering
              the job to be running.

              Without this stanza init(8) is unable to supervise forking  pro-
              cesses  and  will  believe  them to have stopped as soon as they
              fork on startup.

RESTRICTIONS
       The use of symbolic links in job configuration file directories is  not
       supported  since  it can lead to unpredictable behaviour resulting from
       broken or inaccessible links (such as would be caused by a link  cross-
       ing  a  filesystem  boundary  to  a  filesystem  that  has not yet been
       mounted).

BUGS
       The and and or operators allowed with start on and stop on do not  work
       intuitively:  operands  to the right of either operator are only evalu-
       ated once and state information is then discarded.  This  can  lead  to
       jobs  with  complex  start  on  or  stop  on conditions not behaving as
       expected when restarted. For example, if a job  encodes  the  following
       condition:

              start on A and (B or C)

       When  'A'  and  'B'  become true, the condition is satisfied so the job
       will be run. However, if the job ends  and  subsequently  'A'  and  'C'
       become  true,  the  job  will not be re-run even though the condtion is
       satisfied.  Avoid using complex conditions with jobs which need  to  be
       restarted.

FILES
       /etc/init/*.conf
              System job configuration files.

       /etc/init/*.override
              System job override files.

       $HOME/.init/*.conf
              User job configuration files (deprecated).

       $HOME/.init/*.override
              User job override files.  (deprecated).

       $XDG_CONFIG_HOME/upstart/*.conf

       $XDG_RUNTIME_DIR/upstart/sessions/*.session
              Location  of  session files created when running in User Session
              mode.

AUTHOR
       Manual page written by Scott  James  Remnant  <scott@netsplit.com>  and
       James Hunt <james.hunt@canonical.com>.

REPORTING BUGS
       Report bugs at <https://launchpad.net/upstart/+bugs>

COPYRIGHT
       Copyright (C) 2009-2013 Canonical Ltd.
       This is free software; see the source for copying conditions.  There is
       NO warranty; not even for MERCHANTABILITY or FITNESS FOR  A  PARTICULAR
       PURPOSE.

SEE ALSO
       apparmor(7),   cgmanager(8),  init(8),  initctl(8),  prctl(2),  pty(7),
       sh(1), upstart-events(7).

Upstart                           2014-05-09                           init(5)
Man Pages Copyright Respective Owners. Site Copyright (C) 1994 - 2019 Hurricane Electric. All Rights Reserved.