init
Upstart process management daemon
see also :
initctl - runlevel - telinit
Synopsis
init
[OPTION]...
add an example, a script, a trick and tips
examples
source
Linux services: is there a GUI for services?
Try sysv-rc-conf to alter the runlevel settings.
and chkconfig to see what's running
Don't forget that ubuntu (and others?) are starting to use the
Upstart Startup Manager, so you'll have to keep an eye on the
/etc/init directory too
source
Where can I config service startup options in Ubuntu?
Ubuntu and Debian use Upstart as a replacement for init,
but legacy init scripts are supported. Chances are
that you can add the option in a script in
/etc/init.d with the same name as the service. Also
look in /etc/init for .conf files that
control the runlevels that services are started and stopped on
and how they're respawned, etc.
source
LANG=C is in a number of the /etc/init.d/* scripts. What does LANG=C do and why do you need to set LANG=C.
LANG=C is a way to disable localization. It's used in scripts to
predict program output which may vary based on current language.
For more information read this
source
How do I debug an upstart job?
You can redirect stdout and stderr of
the entire shell using the script pragma (instead of
exec) in conjunction with exec >FILE
2>&1, like so:
script
exec >/path/to/some_log_file 2>&1
exec your_command_here
end script
That should hopefully give you better insight into what's going
on. I've found this useful for catching all sorts of problems in
my upstart scripts. You could pipe your command's
stdout/stderr directly, but you'll miss
out on errors originating in the shell (like syntax errors).
On the other hand, if service is hanging, it
might not even be hitting your script, in which case
none of this will help, of course.
source
Why do scripts beginning with an 'S' exist in /etc/rc.d/rc{0,6}.d?
Yes, the traditional system V init style (what that is) makes
symlinks that start with S, or K. those with S means "start", and
they are run with the "start" parameter when that runlevel is
entered. Those with K means "kill", those services are run with
the "stop" parameter when that runlevel is entered. This makes
the different run levels have different sets of services running.
If you cange one from S to K the server won't be started, it will
be stopped then. That may or may not be a problem depending on
whether or not it was a critical service.
BTW, this method is being obsoleted by newer, dependency based
startup systems in newer Linux distros.
source
Where and how are custom startup commands configured in Linux?
The init system handles startup. That said, however,
this question belongs on superuser.com or serverfault.com.
source
Slackware init rd_local problem
Do you mean rc.local file?
Anyway, if you want to edit files but do not want (or can't) boot
from hard disc, do this:
1) Boot your system with the Slackware install DVD or first CD
using whatever kernel options you need to see your hard disk.
Once logged in and presented with the console, mount your root
partition to /mnt with the following command (assuming your root
partition is /dev/hda3)
mount /dev/hda3 /mnt
2) chroot into the system with this command
chroot /mnt
3) Once chrooted, you may edit configuration files
source
What does "switching runlevel" mean exactly?
My understand of changing runlevels is that init
"diffs" the old and new runlevel and starts / kills services
whose status will changed.
In the given example, /etc/rc.multi would not be
re-executed because it's already running. If you had
rm:45:wait:/etc/rc.multi in your
/etc/inittab, and went from runlevel 5 -> 3 ->
5, /etc/rc.multi would be killed (-> 3) and then
started (-> 5) because it's not set for runlevel 3.
From the manpage:
When init is requested to change the runlevel, it sends the
warning signal SIGTERM to all processes that are undefined in
the new runlevel. It then waits 5 seconds before forcibly
terminating these processes via the SIGKILL signal.
/etc/inittab is rescanned as you described:
After it has spawned all of the processes specified, init waits
for one of its descendant processes to die, a powerfail signal,
or until it is signaled by telinit to change the system's
runlevel. When one of the above three conditions occurs, it
re-examines the /etc/inittab file. New entries can be added to
this file at any time. However, init still waits for one of the
above three conditions to occur.
source
How to execute a command under Linux after booting without a TTY session?
you can modify your ServerFlags section in xorg.conf without the
need to fiddle with inittab:
Section "ServerFlags"
Option "DontVTSwitch" "true"
EndSection
source
Automatic script launch after booting on Debian
ln -sf /etc/init.d/datalogger-serveur /etc/rc2.d
You need also to prefix the link name with S (for start) and two
digits for the execution order in the same runlevel:
/etc/rc2.d/S99datalogger-serveur
As if you want to kill the script entering some runlevel you need
to prefix the link with K (for kill)
/etc/rc3.d/K99datalogger-serveur
Scripts beginning with other chars are just ignored.
source
Why will dmesg have message from user space?
A root process can write to /dev/kmsg. This is used
for logging that occurs very early, before regular logging
systems are ready to do any logging.
source
How do I prevent Apache service from auto-starting on Linux?
Depending on your distro, you should be able to execute a command
to disable the service on startup. Doing this it will be stopped
until you manually start it. Here are some examples on different
distros:
- Ubuntu/Debian:
update-rc.d -f apache2 remove
- Gentoo:
rc-update del apache2
- ArchLinux:
systemctl disable apache2
source
Kill xserver from command line (init 3/5 does not work)
The easiest way to kill your X server is to press
Ctrl+Alt+Backspace.
For example, on Ubuntu, the keyboard shortcut is called
"DontZap", and can be re-enabled by following these
instructions. It should be the same on Linux Mint.
It's best not to run startx. It is independent from
init 3/init 5, and will confuse things.
These days, pkill is preferred over
killall. It basically does the same thing, but it
has a partner command pgrep you can use to see what
it would kill before doing it.
So try pgrep X or pgrep Xorg, and then
run pkill X or pkill Xorg if
pgrep lists only programs you want to kill.
On my Ubuntu system, the most reliable command I can find is:
pgrep -f '^/usr/bin/X '
which means you can kill all X servers using
pkill -f '^/usr/bin/X '
(but I haven't tested it).
Finally, don't forget to have a look in
/var/log/X.0.log and
~/.xsession-errors. Maybe you can figure out what is
causing the X server hangs.
source
At what point are cgroups initialized for systemd?
systemd is an init system, even if you
manage to get it running as PID != 1, there surely
will be many things going wrong (e.g. which init
process will be responsible for starting/stopping processes?)
There are ways of using cgroups without using
systemd, if that is what you need, as they are
implemented in the kernel, not in systemd, which is
"only" using those capabilities.
As per information from the devs, the systemd web page lists all kinds of resources,
including several mailing lists, the URL of the git repository
and the project documentation, which is very comprehensive.
description
init is
the parent of all processes on the system, it is executed by
the kernel and is responsible for starting all other
processes; it is the parent of all processes whose natural
parents have died and it is responsible for reaping those
when they die.
Processes
managed by init are known as jobs and are defined by
files in the /etc/init directory. See init(5)
for more details on configuring Upstart.
Events
init(8) is an event-based init daemon. This means that
jobs will be automatically started and stopped by changes
that occur to the system state, including as a result of
jobs starting and stopping.
This is
different to dependency-based init daemons which start a
specified set of goal jobs, and resolve the order in which
they should be started and other jobs required by iterating
their dependencies.
For more
information on starting and stopping jobs, as well as
emitting events that will automatically start and stop jobs,
see the manual page for the initctl(8) tool.
The primary
event is the startup(7) event, emitted when the
daemon has finished loading its configuration. Other useful
events are the starting(7), started(7),
stopping(7) and stopped(7) events emitted as
jobs change state.
See
upstart-events(7) for a summary of well-known
events.
System V
compatibility
The Upstart init(8) daemon does not keep track of
runlevels itself, instead they are implemented entirely by
its userspace tools. The event emitted to signify a change
of runlevel is the runlevel(7) event. For more
information see its manual page.
options
Options are
passed to init(8) by placing them on the kernel
command-line.
--confdir directory
Read job configuration files
from a directory other than /etc/init. For user
session mode, read job configuration files from this
directory at highest priority.
--default-console
value
Default value for jobs that do
not specify a 'console' stanza. This could be used
for example to set the default to 'none' but still
honour jobs that specify explicitly 'console log'.
See init(5) for all possible values of
console.
--no-inherit-env
Stop jobs from inheriting the
initial environment. Only meaningful when running in user
mode.
--logdir
directory
Write job output log files to a
directory other than /var/log/upstart (system mode)
or $XDG_CACHE_HOME/upstart (user session mode).
--no-log
Disable logging of job output.
Note that jobs specifying 'console log' will be
treated as if they had specified 'console none'. See
init(5) for further details.
--no-sessions
Disable chroot sessions.
--no-startup-event
Suppress emission of the
initial startup event. This option should only be used for
testing since it will stop the init(8) daemon from
starting any jobs automatically.
--session
Connect to the D-Bus
session bus. This should only be used for testing.
--startup-event
event
Specify a different initial
startup event from the standard
startup(7).
--user
Starts in user mode, as used for user sessions. Upstart
will be run as an unprivileged user, reading configuration
files from configuration locations as per roughly XDG Base
Directory Specification. See init(5) for further
details.
-q,
--quiet
Reduces output messages to
errors only.
-v,
--verbose
Outputs verbose messages about
job state changes and event emissions to the system console
or log, useful for debugging boot.
--version
Outputs version information and
exits.
copyright
Copyright © 2009-2012 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.
environment variables
When run as a user process, the following variables may be used
to find job configuration files:
•
$XDG_CONFIG_HOME
•
$XDG_CONFIG_DIRS
See User Session Mode in init(5) for further
details.
files
/etc/init.conf
/etc/init/
$HOME/.init/
$XDG_CONFIG_DIRS/upstart/
$XDG_CONFIG_HOME/upstart/
notes
init is not normally executed by a user process, and
expects to have a process id of 1. If this is not the case, it
will actually execute telinit(8) and pass all arguments to
that. See that manual page for further details. However, if the
--user option is specified, it will run as a Session
Init and read alternative configuration files and manage the
individual user session in a similar fashion.
Sending a Session Init a SIGTERM signal is taken as a
request to shutdown due to an impending system shutdown. In this
scenario, the Session Init will emit the session-end event
and request all running jobs stop. It will attempt to honour jobs
kill timeout values (see init(5) for further
details). Note however that system policy will prevail: if jobs
request timeout values longer than the system policy allows for
complete system shutdown, it will not be possible to honour them
before the Session Init is killed by the system.
reporting bugs
Report bugs at <https://launchpad.net/upstart/+bugs>
see also
control-alt-delete
init initctl runlevel
startup starting started
stopping stopped telinit
upstart-events
author
Written by
Scott James Remnant <scott[:at:]netsplit[:dot:]com>