init man page on ElementaryOS

Man page or keyword search:  
man Server   4994 pages
apropos Keyword Search (all sections)
Output format
ElementaryOS logo
[printable version]

init(5)								       init(5)

NAME
       init - Upstart init daemon job configuration

SYNOPSIS
       /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, 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:

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

       ·   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:

       · A single configuration file.

       · 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
       /etc/init/net/apache.conf  is  named  net/apache.  Since override files
       only modify the way a configuration file is interpreted, they  are  not
       named.

       Configuration files are plain text and should not be executable.

   Chroot Support
       Upstart	is  able  to  manage  jobs within a chroot(2). To control jobs
       within the chroot environment, use the  standard	 initctl(8)  facility.
       Note  that  it  is not necessary to install D-Bus within the chroot (in
       fact it is not recommended).

       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:

       ·   $XDG_CONFIG_HOME/upstart/

       ·   $HOME/.init/

       ·   $XDG_CONFIG_DIRS/upstart/

       ·   /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
       The primary use of jobs is to define services or tasks to be run by the
       init(8) daemon.	Each job may have one or more different processes  run
       as  part	 of  its  lifecycle,  with  the	 most common known as the main
       process.

       The main process is defined using either the exec  or  script  stanzas,
       only  one of which is permitted.	 These specify the executable or shell
       script that will be run when the job is considered to be running.  Once
       this process terminates, the job stops.

       All  processes are run with the full job environment available as envi‐
       ronment variables in their process.

       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
	      directories.

       All of these processes, including the main process, are optional.  Ser‐
       vices  without  a main process will appear to be running until they are
       stopped: this is commonly used to define states such as runlevels.   It
       is  permissible	to  have  no  main  process, but to have pre-start and
       post-stop processes for the state.

	      pre-start exec ifup -a
	      post-stop exec ifdown -a

   Event definition
       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.

	      Note that no job processes are started until the overall expres‐
	      sion evaluates to true.

	      Note that if a new job is created which specifies that it starts
	      on one or more events that have already been destroyed, that job
	      will  not	 start	automatically  until  those events are emitted
	      again. Depending on the event, this may  not  happen  until  the
	      next time the system is booted.

	      Although	complex expressions are supported, it should be possi‐
	      ble to specify the start condition for the majority of jobs with
	      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:

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

	   All jobs contain the TERM and PATH variables.

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

	   These commands also allow unsetting of variables.

       ·   A set of special variables added by Upstart that relate to the  job
	   itself.

	   All jobs also contain the UPSTART_JOB and UPSTART_INSTANCE environ‐
	   ment variables, containing the name of the job and instance.	 These
	   are	mostly	used by the initctl(8) utility to default to acting on
	   the job the commands are called from.

       ·   Those variables introduced by the events or	command	 that  started
	   the job.

	   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.

       ·   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 an environment variable into the start‐
		  ing(7),  started(7),	stopping(7)  and stopped(7) events for
		  this job and to all resultant events (not just those	relat‐
		  ing to the current job).

       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
	      respawned.

       respawn limit COUNT INTERVAL
	      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.

	      This  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"

       author AUTHOR
	      This  stanza  may contain the author of the job, often used as a
	      contact for bug reports.

	      author "Scott James Remnant <scott@netsplit.com>"

       version VERSION
	      This stanza may contain version information about the job,  such
	      as  revision  control or package version number.	It is not used
	      or interpreted by init(8) in any way.

	      version "$Id$"

       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
		     replaced with the job name.

		     Jobs  started from within a chroot will have their output
		     logged to such a path within the chroot.

		     If log files already exist, they are appended to.

		     All slash ('/') characters in <job-log-file> are replaced
		     with underscore ('_') characters. For example, any output
		     from the 'wibble' instance of the 'foo/bar' job would  be
		     encoded  in  file	'foo_bar-wibble.log'  in  the log file
		     directory. This gives  the	 log  file  directory  a  flat
		     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
	      A common configuration is to set the file mode creation mask for
	      the  process.   UMASK should be an octal value for the mask, see
	      umask(2) for more details.

       nice NICE
	      Another common configuration is to  adjust  the  process's  nice
	      value, see nice(1) for more details.

       oom score ADJUSTMENT|never
	      Normally	the  OOM  killer  regards  all processes equally, this
	      stanza advises the kernel to treat this job differently.

	      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
	      both  this  and  the setuid stanza are unspecified, all job pro‐
	      cesses will run with their group ID set to 0 (root) in the  case
	      of system jobs, and as the primary group of the user in the case
	      of User Session jobs.

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

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

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

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

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

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

       · If both a configuration file and an override file exist for a job and
	 subsequently  the override file is deleted, the configuration file is
	 automatically reloaded with the effect that any changes introduced by
	 the  override	file  are  undone and the configuration file alone now
	 defines the job.

       · If both a configuration file and an override file exist for a job and
	 subsequently the configuration file is deleted, a new instance of the
	 job can no longer be started (since without a corresponding  configu‐
	 ration file an override file is ignored).

       · If both a configuration file and an override file exist for a job and
	 any of the contents of the override file are  invalid,	 the  override
	 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.

       expect stop
	      Specifies that the job's main process  will  raise  the  SIGSTOP
	      signal to indicate that it is ready.  init(8) will wait for this
	      signal before running the job's post-start script, or  consider‐
	      ing the job to be running.

	      init(8)  will send the process the SIGCONT signal to allow it to
	      continue.

       expect daemon
	      Specifies that the job's main process is a daemon, and will fork
	      twice  after being run.  init(8) will follow this daemonisation,
	      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
	      User  session job configuration files. See User Session Mode for
	      other locations.

       $XDG_CONFIG_HOME/upstart/*.override
	      User session job override files. See User Session Mode for other
	      locations.

       /var/log/upstart/*.log
	      Default location of system job output logs.

       $XDG_CACHE_HOME/upstart/*.log
	      Default location of user session job output logs.

       $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 © 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),  init(8),  initctl(8),  prctl(2),  pty(7), sh(1), upstart-
       events(7).

Upstart				  2013-01-25			       init(5)
[top]

List of man pages available for ElementaryOS

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Tweet
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
...................................................................
Vote for polarhome
Free Shell Accounts :: the biggest list on the net