runlevel
output previous and current runlevel
see also :
init - telinit - shutdown - who
Synopsis
runlevel
[OPTION]... [UTMP]
add an example, a script, a trick and tips
examples
source
Kill Infinite loop at Upstart's run level
A clean way to do this would be to use update-rc.d. You can configure the
program to not run at all during runlevel 1:
$update-rc.d script_name stop 1 .
where script_name is the init.d script. So for
example, to stop Apache from running in runlevel 1:
$update-rc.d apache2 stop 1 .
If you want to completely disable the specified
service:
$update-rc.d -f script_name remove
If you are going to disable a service, you should also stop it
from running in all runlevels. Next time a service is upgraded,
the init.d scripts may be recreated, essentially re-enabling your
service.
To disable it in all runlevels:
$update-rc.d script_name stop 80 0 1 2 3 4 5 6 .
source
Copy Linux liveUSB causes errors with init.d scripts - Impossible..?
Given your description of the problem I suspect something other
than you describe is happening. In any case, try this:
# sda2
mount /dev/sda2 /mnt/tmp
tar -C /mnt/tmp -cf ~/Desktop/sda2.tar .
umount /dev/sda2
# ... repeat for sda3 ...
# do your create partition shenanigans
mount /dev/newsda2 /mnt/tmp
tar -C /mnt/tmp -xpf ~/Desktop/sda2.tar
umount /dev/newsda2
# repeat ...
# test ..
If that works then chances are your /home is mounted noexec or is
some fubar'ed filesystem because the problem was the execute bit
being removed.
If it doesn't work, edit your start up script to give you debug
info such as the output of mount, content of syslog etc and look
for help there.
You could also generate checksums for every file and compare copy
vs original with:
find . -type f -exec sha1sum {} ';' > /tmp/sda2_checksums.txt
for each mounted partition & diff the /tmp/*_checksums.txt files
source
How does one tell u-boot to tell the Linux kernel which runlevel to boot to?
After a lot of digging before and after my question, I discovered
that it's as simple as appending the number of the runlevel onto
the end of the environment variable bootargs.
For instance, to enter into runlevel 3:
setenv bootargs ${bootargs} 3
and you can use
printenv bootargs
before and after to check your changes.
I found a huge hint for this at http://www.novell.com/coolsolutions/tip/14818.html
source
How to boot runlevel 3 as non-root user?
-
systemd does not cause booting into any default
runlevel to go to arch's "rescue mode" runlevel
-
Using the old way of specifying runlevels causes arch to
default to rescue mode
-
runlevel is now specified by a unit - the (new) proper way to
get to multi-user is not to add ro/rw 3
-
Instead add systemd-unit=multi-user.target, to
the end of the boot line
(5. still not super excited about systemd)
source
Is the /etc/inittab file read top down?
First, note that the format of inittab is like so:
Identifier:RunLevel:Action:Command
The key point here being the runlevel. Given the
following example code:
a:3::
b:123::
c:23::
d:123::
e:23::
Then the order of execution of the various IDs, starting from
runlevel 1 would be:
init 1: b d
init 2: c e
init 3: a
overall: b d c e a
As you can see, it will run them in the order that they are
listed in the file, group by runlevel! Also remember, if
the identifier is not in the specified runlevel, it will be
issued a SIGTERM and then a SIGKILL.
source
enabling options from shopt terminal output in ubuntu server 12.4 LTS
The last line is the only part of your "question" that looks like
a question, so I will answer that.
You can enable a shopt option for bash with the following command
shop -s OPTION where 'OPTION' is the option you wish
to enable.
Please read the man page for shopt...
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
Run script in runlevel 1
Debian documentation isn't explicit, init(8)
cautions only that runlevels S,0,1,6 are reserved, and also:
On a Debian system, entering runlevel 1 causes all processes to
be killed except for kernel threads and the script that does
the killing and other processes in its session. As a
consequence of this, it isn’t safe to return from runlevel 1 to
a multi-user runlevel: daemons that were started in runlevel S
and are needed for normal operation are no longer running. The
system should be rebooted.
Run level 1 in /etc/inittab is:
l1:1:wait:/etc/init.d/rc 1
/etc/init.d/rc 1 will call
/etc/rc1.d/S* including S01killprocs
which kills most things it can find, and S21single,
which performs "exec init -t1 S", to switch to
single-user mode, so runlevel 1 is very short-lived. Single-user
mode "S" in /etc/inittab is:
~~:S:wait:/sbin/sulogin
which means that init will simply wait until wait
until sulogin returns before doing anything else.
In short, runlevels "1" and "S" are "hands-off" in Debian (and
probably most other unixen too).
If you put your inittab entry above the system "S" entry, then
init respawning and the S01killprocs
script will fight it out for a while (you may not get to observe
that without a running syslog), which is probably racy, and
probably won't do what you want.
You may be able to some of what you need by either or
both of modifying the startup scripts, and implementing an
/etc/initscipt to monitor and log the various
actions of init. These are a really good
way to hose a working system, so I suggest experimenting in a vm
first ;-).
I think your other options, neither of which seem very appealing,
are to try a different init, or see if you can do
what you want via a kernel thread.
source
What are the recommended runlevels for httpd?
Don't believe everything you read on Wikipedia.
Taken from a live, recently installed CentOS 6 system: The
network is started in runlevels 2, 3, 4 and 5.
# chkconfig --list network
network 0:off 1:off 2:on 3:on 4:on 5:on 6:off
As a practial matter, only runlevels 3 and 5 ever really get
used. Runlevel 3 is the usual "no-graphical-desktop" runlevel,
while runlevel 5 is used to start a graphical desktop.
source
Graceful shutdown - runlevel 0 scripts not getting called
As this is RHEL you can run sos and raise that with
RHEL support.
What is the poweroff signal? IPMI? Have you got
this:
yum install OpenIPMI OpenIPMI-tools
chkconfig ipmi on
service ipmi start
There is a chance that IPMI have some bugs or you are sending a
wrong signal. See if you can update some things as you should not
be running RHEL 5.0 any more due to millions of critical patches
to it!
description
runlevel
reads the system UTMP file, which defaults to
/var/run/utmp when no alternate filename is given, to
locate the most recent runlevel record.
The previous
and current runlevel from that record are output separated
by a single space. If there is no previous runlevel in the
record, the letter N will be substituted.
If no runlevel
record can be found, runlevel outputs the word
unknown and exits with an error.
During system
boot, the environment variables RUNLEVEL and
PREVLEVEL will be set by the init(8) daemon,
these come from the runlevel(7) event generated by
telinit(8) or shutdown(8).
When these
environment variables are set, runlevel will output
the values from these instead. Thus runlevel can be
used in rc scripts as a replacement for the System-V
who(1) -r command.
options
--quiet
Does not output the current and
previous runlevel, nor does it output unknown in the
case of error (but it will exit with an error code).
This may be
used to test for the presence of a runlevel entry, or to
check for errors reading from the file.
copyright
Copyright © 2009 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
RUNLEVEL
runlevel will read the current runlevel from this
environment variable if set in preference to reading from
/var/run/utmp
PREVLEVEL
runlevel will read the previous runlevel from this
environment variable if RUNLEVEL
was given, in preference to reading from /var/run/utmp
exit status
runlevel will exit with status 0 if a UTMP
record was found, otherwise it will exit with status 1.
files
/var/run/utmp
Where the current and previous runlevels will be read from.
notes
The Upstart init(8) daemon does not keep track of
runlevels itself, instead they are implemented entirely by its
userspace tools.
A change of runlevel is signalled by the runlevel(7)
event, generated by either the telinit(8) or
shutdown(8) tools. This event includes the new runlevel in
the RUNLEVEL environment variable, as well as the previous
runlevel (obtained from their own environment or from
/var/run/utmp) in the PREVLEVEL variable.
As well as generating the event, both tools write the new
runlevel back to /var/run/utmp and append a new entry to
/var/log/wtmp.
reporting bugs
Report bugs at <https://launchpad.net/upstart/+bugs>
see also
runlevel
init telinit shutdown
who
author
Written by
Scott James Remnant <scott[:at:]netsplit[:dot:]com>