Linux Commands Examples

A great documentation place for Linux commands

init

Upstart process management daemon


see also : initctl - runlevel - telinit

Synopsis

init [OPTION]...


add an example, a script, a trick and tips

: email address (won't be displayed)
: name

Step 2

Thanks for this example ! - It will be moderated and published shortly.

Feel free to post other examples
Oops ! There is a tiny cockup. A damn 404 cockup. Please contact the loosy team who maintains and develops this wonderful site by clicking in the mighty feedback button on the side of the page. Say what happened. Thanks!

examples

0
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

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

0
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

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

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

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

0
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

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

0
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

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

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

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

0
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>

How can this site be more helpful to YOU ?


give  feedback