Softpanorama

Home Switchboard Unix Administration Red Hat TCP/IP Networks Neoliberalism Toxic Managers
May the source be with you, but remember the KISS principle ;-)
Skepticism and critical thinking is not panacea, but can help to understand the world better

Linux Run Levels

News

Recommended Books

Recommended Links Linux Startup and Shutdown Xinetd Boot Directly into a Shell
RHEL Runlevels Red Hat Startup Scripts Suse Runlevels Suse init scripts Creating your own init scripts  
service chkconfig /etc/inittab Changing Runlevels Linux root password recovery Booting into Rescue Mode
Linux Troubleshooting Incomplete LSB comment, missing `Required-Start:' entry Linux Tips Admin Horror Stories Humor Etc

Introduction

The idea of runlevels came from System V and is pretty neat idea, which unfortunately was made more complex then necessary in recent Linux distributions (especially Suse, Red Hat is more reasonable).  

In its initial form it allows, without increasing complexity of the system , substantial flexibility in defining set of running daemons for the one of several "final" stages to which system can be booted. With runelvels there can be multiple such states.  This about it as a neat generalization of MS DOS authoexec.bat file.

Each runlevel is defined by a set of daemons that it should be started on entering this runlevel (and by extension a set of daemons that it need to be shut down, when you exit this runlevel). In other words, each runlevel is configured to start its specified services when starting and to shut down its services when switching to a different runlevel.

Availability of different  system states (runlevels), each with own set of running daemons can be used for recovery and for optimizing system for running a particular application. This scheme also provides an opportunity to set a default level to which system is booted.  As a side effect of this scheme you can change from one runlevel to another dynamically without rebooting the system. This is another big plus of runlevel as implemented in System V. In this scheme shutting down the system becomes just a switch to a special (fake) runlevel. 

Switching from higher runlevel to lower, for example from 5 to 3,  usually involves killing some daemons. And vise versa, switching to high runlevel, for example from 3 to 5,  involves starting some daemons.  But please note that notions or higher runlevels and lower runlevels are human-defined. For init each runlevel is just a set of daemons to kill plus a set of daemons to start. Numeric value of the runlevel does not have any meaningful semantic in init. All runlevels are treated atomically, completely independently of each other.

So you can (for example, as a joke) switch set of daemons on runlevel 5 to runlevel 3 and vise versa (by renaming the directories) and init will eat this change as if this is what mother ordered.  Urban legend that Unix enters lower runlevels before reaching specified does not have any real ground. It is just a myth. 

For Unix OS runlevels do not have any meaningful order. They are treated by OS atomically, completely independently of each other.  Urban legend that Unix enters lower runlevels before reaching specified does not have any real ground. It is just a myth. 

Typically System V based flavors of Unix has the following four runlevels defined:

  1. Single user,
  2. Multi-user without networking,
  3. Full multiuser
  4. Full multi-user with X11. 

Meaning of runlevels differs between various Linux flavors. There are two big camp:

Runlevels in Red Hat, Suse and all other members of Red Hat family:

In addition two "pseudo-runlevels ( 0 (halt) and 6 (reboot) in linux) are assigned for shutting system down and rebooting it.  So we have 4+2=6 different runlevels.  Sometimes (in Solaris) level S is defined for runlevel that does not run any init scripts. As some levels are not used and you can define your own (see below).

Root user can switch from any runlevel to any. Switching to the single user mode and back to multi-user with networking is equivalent to "soft reboot" as it restarts all major daemons and is much quicker then full reboot of the server. 

Switching to the single user mode and back to multi-user with networking or multi user with X11 is equivalent to "soft reboot" as it restarts all major daemons and is much quicker then full reboot of the server.  

Runlevel structure in different flavors of Linux

While both Solaris and Linux are based on System V, Linux uses different set of runlevels then Solaris. Moreover meaning of runlevels differs between various Linux flavors. There are two big camps:

Structure on init scripts

There are multiple directories involved in storage of init scripts. There is one directory that stores the scripts, called /etc/init.d. And there are additional directories, one for each runlevel (/etc/rc.0.d, /etc/rc1.d, ... /etc/rc6.d) which stores links to those scripts. Links can be of two types:

Changing Runlevels

Two sets of init scripts are involved in switching runlevels: K-scripts from the runlevel on which we are currently running and S-scripts from a new (target) runlevel. It is important to understand that there are two runlevels involved in switching:

Simplifying the rc script which is responsible for changing runlevels performs the following two operations.

  1. All K-scripts that exist on the current runlevel l_from are processed. For each K-script for which S-script does not exists at the target runlevel l_to, the  K-script from l_from is executed.
  2. Each S script that exist at target runlevel l_to is executed

In other words when you change the runlevel first stop scripts of the current runlevel are launched, closing down some daemons running on the current runlevel that are not necessary on a new runlevel (do not have S-script defined for them). Then all start scripts of the new runlevel are run in the order defined by their numeric priorities (lexographic order).

For example, the following occurs when changing from runlevel 3 to 5:

  1. The administrator (root) enter the command init 5 which tells init to change the current runlevel to 5. 
  2. The init consults its configuration file (/etc/inittab) and determines it should start /etc/init.d/rc with the new runlevel as a parameter.
  3. Now rc calls all the stop scripts of the current runlevel, but only those for which there is no start script in the new runlevel. In this example, these are all the scripts that reside in /etc/init.d/rc3.d (old runlevel was 3) and start with a K. The number following K specifies the order to start, because there are some dependencies to consider.
  4. The last things to start are the start scripts of the new runlevel. These are, in this example, in /etc/init.d/rc5.d and begin with an S. The same procedure regarding the order in which they are started is applied here.

When changing into the same runlevel as the current runlevel, init only checks /etc/inittab for changes and starts the appropriate scripts. 

The init command allows you to reboot computer using as a switch to runlevel 0. Here is an example:

# init 0

A shutdown command should generally be used instead as it prompts you  if your action is correct and can delay actual shutdown so that that user can close their programs befors reboot; you can also specify interval before reboot or exact time when it should happen. By default the command requires acknowledgement (which can be cancelled using the -y switch). The -h switch forces the system to halt, and the first argument tells it how long to wait before starting the shutdown process. minutes.  For example (you can use the word now intstead of 0):

# shutdown -hy 0

Broadcast message from root (pts/0) (Sat Nov  6 13:15:27 2004):

The system is going down for system halt NOW!
#

You can also use the init command to reboot the system immediately by entering runlevel 6.

# init 6

The "reboot" command has the same effect, but it also sends a warning message to all users.

# reboot

Broadcast message from root (pts/0) (Sat Nov  6 12:39:31 2004):

The system is going down for reboot NOW!
#

More graceful reboots can be done with the shutdown command using the -r switch and specifying a delay. For example reboot with the delay of 10 minutes:

# shutdown -ry 10

Broadcast message from root (pts/0) (Sat Nov  6 13:26:39 2004):

The system is going DOWN for reboot in 10 minutes!

Broadcast message from root (pts/0) (Sat Nov  6 13:27:39 2004):

The system is going DOWN for reboot in 9 minutes!
...
...
...
Broadcast message from root (pts/0) (Sat Nov  6 13:36:39 2004):

The system is going down for reboot NOW!

Some activities require you to force the system to log off all users, third-party applications and networking so that only the systems administrator has access to the system. This can be done by using the  command init 1. It is best to do this from the console, because if you do it from a remote terminal session you'll be logged out.

# init 1

In this case there  no prior warning to users. To broadcase a warning, you can run the shutdown command with a delay in minutes as the only argument.

# shutdown 1

Broadcast message from root (pts/0) (Sat Nov  6 13:44:59 2004):

The system is going DOWN to maintenance mode in 1 minute!

Broadcast message from root (pts/0) (Sat Nov  6 13:45:59 2004):

The system is going down to maintenance mode NOW!

...
...
#

Entering Single-user Mode At The Grub Splash Screen

You can enter single user mode directly after turning on the power to your system. The steps to do this are listed below.

1. Power on your system. Wait for the "Grub loading" message to appear and, depending on your Linux distribution, get ready to hit either any key or the ESC key to enter the grub boot menu.

Grub loading, please wait ...
Press ESC to enter the menu

or

Grub loading, please wait ...
Press any key to enter the menu

2. You will then get grub's main menu which will display a list of available kernels. Use the arrow keys to scroll to your desired version of the kernel and then press e for "edit".

Fedora Core (2.6.18-1.2239.fc5smp)
 

3. The kernel's boot menu will appear. Use the arrow keys to scroll to the "kernel" line and then press e for "edit".

root (hd0,0)
kernel /vmlinuz-2.6.18-1.2239.fc5smp ro root=LABEL=/
initrd /initrd-2.6.18-1.2239.fc5smp.img

4. A grub edit prompt will appear. Use the arrow keys to move to the end of the line and add the word "single" to the end, separated by a space. Change

grub edit> kernel /vmlinuz-2.6.18-1.2239.fc5smp ro root=LABEL=/

to

grub edit> kernel /vmlinuz-2.6.18-1.2239.fc5smp ro root=LABEL=/ single

5. Press enter to save your changes, and then b for "boot".

6. The system will continue to boot, but will go straight to the root # prompt without first asking for a username and password.

Reverting To Your Default runlevel From Single User Mode

The exit command forces the system to exit runlevel 1 and revert to the default runlevel for the system. You can also use the init command (for example, init 3 and init 5) to alter this default behavior:

# exit
INIT: Entering runlevel: 3
...
...
...
Fedora Core release 2 (Tettnang)
Kernel 2.6.8-1.521 on an i686
bigboy login:

Root Password Recovery

Sometimes you might forget the root password, or the previous systems administrator may move on to a new job without giving it to you. To do this by booting either directly to bash (see Boot Directly into a Shell) or, if single mode is not password protected, to a single user mode. See Linux root password recovery

Defining new runlevels

Typically you can define new runlevel by copying /etc/rc5.d or other already existing runlevel directories and then making the necessary changes.  There are two issues here:

Like in many other cases it make sense to leave existing single digit runlevels as "system runlevels" and copy the content and then modify it under a new, unused runlevel number (4, 7, 8, or 9).  Here are some possibilities that are connected with new runlevels: 

Sometimes instead of calling script that starts several products you can incorporate each step as a separate init script.  For example this can be done with such products as Oracle Fusion and LDAP server, In this case the start priorities for consequent steps should be sequential 

Comparing Runlevels

To see the difference between levels you can use diff  command, for example:

root@nti01:/etc/rc.d # diff <(ls rc2.d) <(ls rc3.d)
2,3d1
< K02cups-config-daemon
< K02haldaemon
5,6d2
< K03messagebus
< K05atd
17d12
< K44rawdevices
21,25d15
< K50xinetd
< K56acpid
< K68rpcidmapd
< K69rpcgssd
< K72autofs
29,30d18
< K74ntpd
< K75netfs
32d19
< K86nfslock
34,35d20
< K87irqbalance
< K87portmap
42d26
< K95kudzu
47a32
> S05kudzu
54a40,42
> S13irqbalance
> S13portmap
> S14nfslock
55a44,46
> S18rpcidmapd
> S19rpcgssd
> S25netfs
57a49
> S28autofs
58a51
> S44acpid
60a54,56
> S56rawdevices
> S56xinetd
> S58ntpd
65a62,63
> S95atd
> S97messagebus
66a65,66
> S98cups-config-daemon
> S98haldaemon

The default runlevel for a system is specified in the /etc/inittab file, which will contain an entry such as id:3:initdefault: if the system starts in runlevel 3, or id:5:initdefault: if it starts in runlevel 5.

There are three method of determining the current runlevel

  1.  who -r command:
    # who -r
    run-level 3  Aug 27 10:12                   last=5
  2. Using runlevel command which produces essentially the same result but in a form of just two numbers. Runlevel command retrieves information from the /var/run/utmp to locate the runlevel record.
  3. The last method is not working in mainstream flavors of Linux (Red Hat 4 & 5 and Suse 10 & 11) but is an interesting option.  In some versions of init the environment variables RUNLEVEL and PREVLEVEL are populated and changed with each change, similar to $PWD and other system variables. In this case you can simply type:
    echo $RUNLEVEL

Runlevel Utilities

One of the best ways to configure runlevels is to use an init-script utility. These tools are designed to simplify the task of maintaining files in the SysV init directory hierarchy and relieves system administrators from having to directly manipulate the numerous symbolic links in the subdirectories of /etc/rc.d/. Red Hat Enterprise Linux provides three such utilities:


Top Visited
Switchboard
Latest
Past week
Past month

NEWS CONTENTS

Old News ;-)

[Feb 05, 2020] How to disable startup graphic in CentOS

Feb 05, 2020 | forums.centos.org

Post by neuronetv " 2014/08/20 22:24:51

I can't figure out how to disable the startup graphic in centos 7 64bit. In centos 6 I always did it by removing "rhgb quiet" from /boot/grub/grub.conf but there is no grub.conf in centos 7. I also tried yum remove rhgb but that wasn't present either.

<moan> I've never understood why the devs include this startup graphic, I see loads of users like me who want a text scroll instead.</moan>
Thanks for any help.

See also https://www.youtube.com/watch?v=oFl40XzlXp4

[Feb 05, 2020] Disable startup graphic

This is still a problem today... See also centOS 7 hung at "Starting Plymouth switch root service"
Feb 05, 2020 | forums.centos.org
disable startup graphic

Post by neuronetv " 2014/08/20 22:24:51

I can't figure out how to disable the startup graphic in centos 7 64bit. In centos 6 I always did it by removing "rhgb quiet" from /boot/grub/grub.conf but there is no grub.conf in centos 7. I also tried yum remove rhgb but that wasn't present either.
<moan> I've never understood why the devs include this startup graphic, I see loads of users like me who want a text scroll instead.</moan>
Thanks for any help. Top
User avatar TrevorH
Forum Moderator
Posts: 27492
Joined: 2009/09/24 10:40:56
Location: Brighton, UK
Re: disable startup graphic

Post by TrevorH " 2014/08/20 23:09:40

The file to amend now is /boot/grub2/grub.cfg and also /etc/default/grub. If you only amend the defaults file then you need to run grub2-mkconfig -o /boot/grub2/grub.cfg afterwards to get a new file generated but you can also edit the grub.cfg file directly though your changes will be wiped out next kernel install if you don't also edit the 'default' file. CentOS 6 will die in November 2020 - migrate sooner rather than later!
CentOS 5 has been EOL for nearly 3 years and should no longer be used for anything!
Full time Geek, part time moderator. Use the FAQ Luke Top
neuronetv
Posts: 76
Joined: 2012/01/08 21:53:07
Re: disable startup graphic

Post by neuronetv " 2014/08/21 13:12:45

thanks for that, I did the edits and now the scroll is back. Top
larryg
Posts: 3
Joined: 2014/07/17 04:48:28
Re: disable startup graphic

Post by larryg " 2014/08/21 19:27:16

The preferred method to do this is using the command plymouth-set-default-theme.

If you enter this command, without parameters, as user root you'll see something like
>plymouth-set-default-theme
charge
details
text

This lists the themes installed on your computer. The default is 'charge'. If you want to see the boot up details you used to see in version 6, try
>plymouth-set-default-theme details

Followed by the command
>dracut -f

Then reboot.

This process modifies the boot loader so you won't have to update your grub.conf file manually everytime for each new kernel update.

There are numerous themes available you can download from CentOS or in general. Just google 'plymouth themes' to see other possibilities, if you're looking for graphics type screens. Top

User avatar TrevorH
Forum Moderator
Posts: 27492
Joined: 2009/09/24 10:40:56
Location: Brighton, UK
Re: disable startup graphic

Post by TrevorH " 2014/08/21 22:47:49

Editing /etc/default/grub to remove rhgb quiet makes it permanent too. CentOS 6 will die in November 2020 - migrate sooner rather than later!
CentOS 5 has been EOL for nearly 3 years and should no longer be used for anything!
Full time Geek, part time moderator. Use the FAQ Luke Top
MalAdept
Posts: 1
Joined: 2014/11/02 20:06:27
Re: disable startup graphic

Post by MalAdept " 2014/11/02 20:23:37

I tried both TrevorH's and LarryG's methods, and LarryG wins.

Editing /etc/default/grub to remove "rhgb quiet" gave me the scrolling boot messages I want, but it reduced maxmum display resolution (nouveau driver) from 1920x1080 to 1024x768! I put "rhgb quiet" back in and got my 1920x1080 back.

Then I tried "plymouth-set-default-theme details; dracut -f", and got verbose booting without loss of display resolution. Thanks LarryG! Top

dunwell
Posts: 116
Joined: 2010/12/20 18:49:52
Location: Colorado
Contact: Contact dunwell
Re: disable startup graphic

Post by dunwell " 2015/12/13 00:17:18

I have used this mod to get back the details for grub boot, thanks to all for that info.

However when I am watching it fills the page and then rather than scrolling up as it did in V5 it blanks and starts again at the top. Of course there is FAIL message right before it blanks :lol: that I want to see and I can't slam the Scroll Lock fast enough to catch it. Anyone know how to get the details to scroll up rather than the blank and re-write?

Alan D. Top

aks
Posts: 2915
Joined: 2014/09/20 11:22:14
Re: disable startup graphic

Post by aks " 2015/12/13 09:15:51

Yeah the scroll lock/ctrl+q/ctrl+s will not work with systemd you can't pause the screen like you used to be able to (it was a design choice, due to parallel daemon launching, apparently).
If you do boot, you can always use journalctrl to view the logs.
In Fedora you can use journalctl --list-boots to list boots (not 100% sure about CentOS 7.x - perhaps in 7.1 or 7.2?). You can also use things like journalctl --boot=-1 (the last boot), and parse the log at you leisure. Top
dunwell
Posts: 116
Joined: 2010/12/20 18:49:52
Location: Colorado
Contact: Contact dunwell
Re: disable startup graphic

Post by dunwell " 2015/12/13 14:18:29

aks wrote: Yeah the scroll lock/ctrl+q/ctrl+s will not work with systemd you can't pause the screen like you used to be able to (it was a design choice, due to parallel daemon launching, apparently).
If you do boot, you can always use journalctrl to view the logs.
In Fedora you can use journalctl --list-boots to list boots (not 100% sure about CentOS 7.x - perhaps in 7.1 or 7.2?). You can also use things like journalctl --boot=-1 (the last boot), and parse the log at you leisure.
Thanks for the followup aks. Actually I have found that the Scroll Lock does pause (Ctrl-S/Q not) but it all goes by so fast that I'm not fast enough to stop it before the screen blanks and then starts writing again. What I am really wondering is how to get the screen to scroll up when it gets to the bottom of the screen rather than blanking and starting to write again at the top. That is annoying! :x

Alan D. Top

aks
Posts: 2915
Joined: 2014/09/20 11:22:14
Re: disable startup graphic

Post by aks " 2015/12/13 19:14:29

Yes it is and no you can't. Kudos to Lennard for making or lives so much shitter....

[Feb 05, 2020] How do deactivate plymouth boot screen?

Jan 01, 2012 | askubuntu.com

Ask Question Asked 8 years ago Active 7 years, 7 months ago Viewed 57k times


> ,

11

Jo-Erlend Schinstad , 2012-01-25 22:06:57

Lately, booting Ubuntu on my desktop has become seriously slow. We're talking two minutes. It used to take 10-20 seconds. Because of plymouth, I can't see what's going on. I would like to deactivate it, but not really uninstall it. What's the quickest way to do that? I'm using Precise, but I suspect a solution for 11.10 would work just as well.

WinEunuuchs2Unix , 2017-07-21 22:08:06

Did you try: sudo update-initramfs – mgajda Jun 19 '12 at 0:54

> ,

17

Panther ,

Easiest quick fix is to edit the grub line as you boot.

Hold down the shift key so you see the menu. Hit the e key to edit

Edit the 'linux' line, remove the 'quiet' and 'splash'

To disable it in the long run

Edit /etc/default/grub

Change the line – GRUB_CMDLINE_LINUX_DEFAULT="quiet splash" to

GRUB_CMDLINE_LINUX_DEFAULT=""

And then update grub

sudo update-grub

Panther , 2016-10-27 15:43:04

Removing quiet and splash removes the splash, but I still only have a purple screen with no text. What I want to do, is to see the actual boot messages. – Jo-Erlend Schinstad Jan 25 '12 at 22:25

Tuminoid ,

How about pressing CTRL+ALT+F2 for console allowing you to see whats going on.. You can go back to GUI/Plymouth by CTRL+ALT+F7 .

Don't have my laptop here right now, but IIRC Plymouth has upstart job in /etc/init , named plymouth???.conf, renaming that probably achieves what you want too more permanent manner.

Jānis Elmeris , 2013-12-03 08:46:54

No, there's nothing on the other consoles. – Jo-Erlend Schinstad Jan 25 '12 at 22:22

[Aug 31, 2019] Linux on your laptop A closer look at EFI boot options

Aug 31, 2019 | www.zdnet.com
Before EFI, the standard boot process for virtually all PC systems was called "MBR", for Master Boot Record; today you are likely to hear it referred to as "Legacy Boot". This process depended on using the first physical block on a disk to hold some information needed to boot the computer (thus the name Master Boot Record); specifically, it held the disk address at which the actual bootloader could be found, and the partition table that defined the layout of the disk. Using this information, the PC firmware could find and execute the bootloader, which would then bring up the computer and run the operating system.

This system had a number of rather obvious weaknesses and shortcomings. One of the biggest was that you could only have one bootable object on each physical disk drive (at least as far as the firmware boot was concerned). Another was that if that first sector on the disk became corrupted somehow, you were in deep trouble.

Over time, as part of the Extensible Firmware Interface, a new approach to boot configuration was developed. Rather than storing critical boot configuration information in a single "magic" location, EFI uses a dedicated "EFI boot partition" on the desk. This is a completely normal, standard disk partition, the same as which may be used to hold the operating system or system recovery data.

The only requirement is that it be FAT formatted, and it should have the boot and esp partition flags set (esp stands for EFI System Partition). The specific data and programs necessary for booting is then kept in directories on this partition, typically in directories named to indicate what they are for. So if you have a Windows system, you would typically find directories called 'Boot' and 'Microsoft' , and perhaps one named for the manufacturer of the hardware, such as HP. If you have a Linux system, you would find directories called opensuse, debian, ubuntu, or any number of others depending on what particular Linux distribution you are using.

It should be obvious from the description so far that it is perfectly possible with the EFI boot configuration to have multiple boot objects on a single disk drive.

Before going any further, I should make it clear that if you install Linux as the only operating system on a PC, it is not necessary to know all of this configuration information in detail. The installer should take care of setting all of this up, including creating the EFI boot partition (or using an existing EFI boot partition), and further configuring the system boot list so that whatever system you install becomes the default boot target.

If you were to take a brand new computer with UEFI firmware, and load it from scratch with any of the current major Linux distributions, it would all be set up, configured, and working just as it is when you purchase a new computer preloaded with Windows (or when you load a computer from scratch with Windows). It is only when you want to have more than one bootable operating system – especially when you want to have both Linux and Windows on the same computer – that things may become more complicated.

The problems that arise with such "multiboot" systems are generally related to getting the boot priority list defined correctly.

When you buy a new computer with Windows, this list typically includes the Windows bootloader on the primary disk, and then perhaps some other peripheral devices such as USB, network interfaces and such. When you install Linux alongside Windows on such a computer, the installer will add the necessary information to the EFI boot partition, but if the boot priority list is not changed, then when the system is rebooted after installation it will simply boot Windows again, and you are likely to think that the installation didn't work.

There are several ways to modify this boot priority list, but exactly which ones are available and whether or how they work depends on the firmware of the system you are using, and this is where things can get really messy. There are just about as many different UEFI firmware implementations as there are PC manufacturers, and the manufacturers have shown a great deal of creativity in the details of this firmware.

First, in the simplest case, there is a software utility included with Linux called efibootmgr that can be used to modify, add or delete the boot priority list. If this utility works properly, and the changes it makes are permanent on the system, then you would have no other problems to deal with, and after installing it would boot Linux and you would be happy. Unfortunately, while this is sometimes the case it is frequently not. The most common reason for this is that changes made by software utilities are not actually permanently stored by the system BIOS, so when the computer is rebooted the boot priority list is restored to whatever it was before, which generally means that Windows gets booted again.

The other common way of modifying the boot priority list is via the computer BIOS configuration program. The details of how to do this are different for every manufacturer, but the general procedure is approximately the same. First you have to press the BIOS configuration key (usually F2, but not always, unfortunately) during system power-on (POST). Then choose the Boot item from the BIOS configuration menu, which should get you to a list of boot targets presented in priority order. Then you need to modify that list; sometimes this can be done directly in that screen, via the usual F5/F6 up/down key process, and sometimes you need to proceed one level deeper to be able to do that. I wish I could give more specific and detailed information about this, but it really is different on every system (sometimes even on different systems produced by the same manufacturer), so you just need to proceed carefully and figure out the steps as you go.

I have seen a few rare cases of systems where neither of these methods works, or at least they don't seem to be permanent, and the system keeps reverting to booting Windows. Again, there are two ways to proceed in this case. The first is by simply pressing the "boot selection" key during POST (power-on). Exactly which key this is varies, I have seen it be F12, F9, Esc, and probably one or two others. Whichever key it turns out to be, when you hit it during POST you should get a list of bootable objects defined in the EFI boot priority list, so assuming your Linux installation worked you should see it listed there. I have known of people who were satisfied with this solution, and would just use the computer this way and have to press boot select each time they wanted to boot Linux.

The alternative is to actually modify the files in the EFI boot partition, so that the (unchangeable) Windows boot procedure would actually boot Linux. This involves overwriting the Windows file bootmgfw.efi with the Linux file grubx64.efi. I have done this, especially in the early days of EFI boot, and it works, but I strongly advise you to be extremely careful if you try it, and make sure that you keep a copy of the original bootmgfw.efi file. Finally, just as a final (depressing) warning, I have also seen systems where this seemed to work, at least for a while, but then at some unpredictable point the boot process seemed to notice that something had changed and it restored bootmgfw.efi to its original state – thus losing the Linux boot configuration again. Sigh.

So, that's the basics of EFI boot, and how it can be configured. But there are some important variations possible, and some caveats to be aware of.

[Aug 03, 2019] Creating Bootable Linux USB Drive with Etcher

Aug 03, 2019 | linuxize.com

There are several different applications available for free use which will allow you to flash ISO images to USB drives. In this example, we will use Etcher. It is a free and open-source utility for flashing images to SD cards & USB drives and supports Windows, macOS, and Linux.

Head over to the Etcher downloads page , and download the most recent Etcher version for your operating system. Once the file is downloaded, double-click on it and follow the installation wizard.

Creating Bootable Linux USB Drive using Etcher is a relatively straightforward process, just follow the steps outlined below:

  1. Connect the USB flash drive to your system and Launch Etcher.
  2. Click on the Select image button and locate the distribution .iso file.
  3. If only one USB drive is attached to your machine, Etcher will automatically select it. Otherwise, if more than one SD cards or USB drives are connected make sure you have selected the correct USB drive before flashing the image.

[Oct 16, 2018] How to Enable or Disable Services on Boot in Linux Using chkconfig and systemctl Command by Prakash Subramanian

Oct 15, 2018 | www.2daygeek.com
It's a important topic for Linux admin (such a wonderful topic) so, everyone must be aware of this and practice how to use this in the efficient way.

In Linux, whenever we install any packages which has services or daemons. By default all the services "init & systemd" scripts will be added into it but it wont enabled.

Hence, we need to enable or disable the service manually if it's required. There are three major init systems are available in Linux which are very famous and still in use.

What is init System?

In Linux/Unix based operating systems, init (short for initialization) is the first process that started during the system boot up by the kernel.

It's holding a process id (PID) of 1. It will be running in the background continuously until the system is shut down.

Init looks at the /etc/inittab file to decide the Linux run level then it starts all other processes & applications in the background as per the run level.

BIOS, MBR, GRUB and Kernel processes were kicked up before hitting init process as part of Linux booting process.

Below are the available run levels for Linux (There are seven runlevels exist, from zero to six).

Below three init systems are widely used in Linux.

What is System V (Sys V)?

System V (Sys V) is one of the first and traditional init system for Unix like operating system. init is the first process that started during the system boot up by the kernel and it's a parent process for everything.

Most of the Linux distributions started using traditional init system called System V (Sys V) first. Over the years, several replacement init systems were released to address design limitations in the standard versions such as launchd, the Service Management Facility, systemd and Upstart.

But systemd has been adopted by several major Linux distributions over the traditional SysV init systems.

What is Upstart?

Upstart is an event-based replacement for the /sbin/init daemon which handles starting of tasks and services during boot, stopping them during shutdown and supervising them while the system is running.

It was originally developed for the Ubuntu distribution, but is intended to be suitable for deployment in all Linux distributions as a replacement for the venerable System-V init.

It was used in Ubuntu from 9.10 to Ubuntu 14.10 & RHEL 6 based systems after that they are replaced with systemd.

What is systemd?

Systemd is a new init system and system manager which was implemented/adapted into all the major Linux distributions over the traditional SysV init systems.

systemd is compatible with SysV and LSB init scripts. It can work as a drop-in replacement for sysvinit system. systemd is the first process get started by kernel and holding PID 1.

It's a parant process for everything and Fedora 15 is the first distribution which was adapted systemd instead of upstart. systemctl is command line utility and primary tool to manage the systemd daemons/services such as (start, restart, stop, enable, disable, reload & status).

systemd uses .service files Instead of bash scripts (SysVinit uses). systemd sorts all daemons into their own Linux cgroups and you can see the system hierarchy by exploring /cgroup/systemd file.

How to Enable or Disable Services on Boot Using chkconfig Commmand?

The chkconfig utility is a command-line tool that allows you to specify in which
runlevel to start a selected service, as well as to list all available services along with their current setting.

Also, it will allows us to enable or disable a services from the boot. Make sure you must have superuser privileges (either root or sudo) to use this command.

All the services script are located on /etc/rd.d/init.d .

How to list All Services in run-level

The -–list parameter displays all the services along with their current status (What run-level the services are enabled or disabled).

# chkconfig --list
NetworkManager     0:off    1:off    2:on    3:on    4:on    5:on    6:off
abrt-ccpp          0:off    1:off    2:off    3:on    4:off    5:on    6:off
abrtd              0:off    1:off    2:off    3:on    4:off    5:on    6:off
acpid              0:off    1:off    2:on    3:on    4:on    5:on    6:off
atd                0:off    1:off    2:off    3:on    4:on    5:on    6:off
auditd             0:off    1:off    2:on    3:on    4:on    5:on    6:off
.
.

How to check the Status of Specific Service

If you would like to see a particular service status in run-level then use the following format and grep the required service.

In this case, we are going to check the auditd service status in run-level

[Jan 11, 2011] Learn Linux, 101 Runlevels, shutdown, and reboot by Ian Shields

developerWorks

Changing runlevels

There are several ways to change runlevels. To make a permanent change, you can edit /etc/inittab and change the default level as you just saw above.

If you only need to bring the system up in a different runlevel for one boot, you can do this. For example, suppose you just installed a new kernel and need to build some kernel modules after the system booted with the new kernel, but before you start the X Window System. You might want to bring up the system in runlevel 3 to accomplish this. You do this at boot time by editing the kernel line (GRUB) or adding a parameter after the selected system name (LILO). Use a single digit to specify the desired runlevel (3, in this case). We'll illustrate the process with a GRUB example. Suppose your /boot/grub/menu.lst file contains the stanza shown in Listing 2.

Listing 2. Typical GRUB stanza to boot Fedora 8
                           
title Fedora (2.6.26.8-57.fc8)
        root (hd0,5)
        kernel /boot/vmlinuz-2.6.26.8-57.fc8 ro root=LABEL=FEDORA8 rhgb quiet
        initrd /boot/initrd-2.6.26.8-57.fc8.img

To bring this system up in runlevel 3, wait till the boot entries are displayed, select this entry and enter 'e' to edit the entry. Depending on your GRUB options, you may need to press a key to display the boot entries and also enter 'p' and a password to unlock editing.

...

In this example, you should now see the root, kernel, and initrd lines displayed. Move the cursor to the line starting with "kernel" and press 'e' to edit the line.

... ... ...

Finally, move the cursor to the end of the line, and add a space and the digit '3'. You may remove 'quiet' if you wish, or modify any other parameters as needed.

... ... ...

Finally, press Enter to save the changes, then type 'b' to boot the system.

Note: The steps for doing this using LILO or GRUB2 differ from those for GRUB, but the basic principle of editing the way the kernel is started remains. Even GRUB screens on other systems or other distributions may look quite different to those shown here. Prompts will usually be available to help you.

Once you have finished your setup work in runlevel 3, you will probably want to switch to runlevel 5. Fortunately, you do not need to reboot the system. You can use the telinit command to switch to another runlevel. Use the runlevel command to show both the previous runlevel and the current one. If the first output character is 'N', the runlevel has not been changed since the system was booted. Listing 3 illustrates verifying and changing the runlevel.


Listing 3. Verifying and changing the runlevel
                    
[root@pinguino ~]# runlevel
N 3
[root@pinguino ~]# telinit 5

After you enter telinit 5 you will see several messages flash by and your display will switch to the configured graphical login screen. Open a terminal window and verify that the runlevel has been changed as shown in Listing 4.


Listing 4. Confirming the new runlevel
                    
[root@pinguino ~]# runlevel
3 5

If you use the ls command to display a long listing of the telinit command, you will see that it really is a symbolic link to the init command. We illustrate this in Listing 5


Listing 5. telinit is really a symbolic link to init
                    
[root@pinguino ~]# ls -l $(which telinit)
lrwxrwxrwx 1 root root 4 2008-04-01 07:50 /sbin/telinit -> init

The init executable knows whether it was called as init or telinit and behaves accordingly. Since init runs as PID 1 at boot time, it is also smart enough to know when you subsequently invoke it using init rather than telinit. If you do, it will assume you want it to behave as if you had called telinit instead. For example, you may use init 5 instead of telinit 5 to switch to runlevel 5.

Red Hat Magazine Run-levels Create, use, modify, and master by Noah Gift

Here is a chart of Red Hat-specific run-levels:

LEVEL NAME DESCRIPTION
0 Halt Immediately shuts down system and powers it off, if it can
1 Single user Brings system to a bare essentials mode for maintenance
2 User-defined Custom
3 Multi-user with console only All services are running but X11
4 User-defined Custom
5 Multi-user with display and console All services are running including X11 (or GUI)
6 Reboot Reboots the machine

What run-level am I?

Just like life, with an operating system you need to know where you are now, in order to get to where you want to go next. If you are planning on modifying your run-level, you need to first know what your current run-level is. In order to do this, you can use one of two commands, like so:

[root@localhost ~]# who -r
         run-level 3  2008-04-29 08:17                   last=5
[root@localhost ~]# runlevel
5 3

If we look at the output of who -r, we can tell that we are currently running at run-level 3–which is multi-user, but console only.We can also tell that we were previously running at run-level 5, which is multi-user with console and X11 login.

Changing run-levels

Once you know what run-level you are at, it is very simple to change to a different one. All you need to do is type: "init" followed by number of the runlevel you would like to switch to. Here is an example of switching to single user mode, or runlevel 1:

init 1

This command will change your system to single user mode, and it will ask you for the root password. When you arrive in single user mode, there are no services running, as this level it is most often used for maintenance, backup, or recovery. Once you are in single user mode it is quite common to enable, for example, network and NFS to backup your operating system, like so:

service network start; service nfs start

When you are done with your work, type in the run-level you would like to go to–perhaps run-level 5 which brings up the X11 login window:

init 5

Later in this article, we will write our own run-level and then use it to script a maintenance operation.

Permanently changing the default run-level

While changing the runlevel manually is most common, sometimes it is useful to change the default run-level from level 5 to level 3 permanently. This can help conserve resources inside of, for example, a virtual machine. You may also choose to define your own custom run-level, and wish to make that the default.

You will need to edit /etc/inittab and change this line with your favorite text editor:

id:5:initdefault:

Change '5′ to the run-level you wish your machine to be at when it boots. To change the run-level so that it never loads the GUI on boot would look like this:

id:3:initdefault:
Note:
A word of caution on editing /etc/inittab. It is very important to keep /etc/inittab in version control, and/or keep a backup of it when you are editing the file. If you make a change incorrectly you can render your operating system unbootable.
Tip:
If you happen to get yourself in this pickle, there is a way out. You can interrupt the Grub boot loader and press "A", and then append the word "emergency" to the end of the kernel arguments. This will boot the operating system without using init. Then, you can fix what you altered by copying back the original version of /etc/inittab.

Creating your own run-level HACK

First, a word of caution. Do not do this on a production machine, period! This section is a VERY dirty hack that you should only use on a virtual machine you can experiment with, or a machine you don't mind rebuilding.. It is always a good idea to do testing inside of a virtual machine before doing something that could potentially render a box unbootable. This is a very quick and dirty way to alter a run-level for the purposes of learning, but perhaps you can get some ideas from it that can be used in a more production-oriented way. Ideally, some of the readers of this article will post some production quality hacks to creating custom run levels.

  1. cd to /etc/rc.d/rc4.d/
  2. do a sanity check to make sure you are running Red Hat: cat /etc/redhat-release
  3. backup existing run-level directory:
    mkdir /tmp/rc4.d.original/
    cp /etc/rc.d/rc4.d/* /tmp/rc4.d.original/
    
  4. rm -f /etc/rc.d/rc4.d/*

At this point

 cp /etc/rc.d/rc1.d/* /etc/rc.d/rc4.d/

We have now copied the run-level scripts for single user mode into our own custom run-level 4. We can hijack the the S99single script and tell it to do something different. In this example, we are going to write a custom Python script that gets forked to the background and backs up the machine over rsync. Let's edit that file we copied:

vim /etc/rc.d/rc4.d/S99single

Change the last part of it to look like this:

# Now go to the single user level.
echo $"Telling INIT to go to single user mode."
echo "This is a custom code. Forking custom script"
/custom.py &
exec init -t1 S

We've inserted two lines. One echoes that we are forking off a custom script. The second line forks a python script, shown below, that backs up the machine via rsync. Note that this assumes you have set up ssh keys on the remote backup server.

custom.py script:

#!/usr/bin/env python
import time
import subprocess

rsync = "rsync -av / 10.0.1.3:/Volumes/Backup/server_backup/"
network = "service network start"
init = "init 3"

cmds = [rsync, network]

def single_user_backup():
    """Starts network service, creates backup and returns to init 3"""
    try:
        subprocess.call(network, shell=True)
        subprocess.call(rsync, shell=True)
    finally:
        subprocess.call(init, shell=True)

def main():
    """Runs program"""
    print "sleeping for 60 seconds"
    #time.sleep(60)  #Gives machine time to quiesce
    single_user_backup()

main()

The main function runs a sleep command for 60 seconds, just to give the single user mode scripts time to quiesce the box. Remember, this script is forked to the background. Next, function single_user_backup attempts to start network services and run rsync to remotely back up the whole / volume to another server. This is obviously crude and there will be lots of errors trying to back up /proc, for example, but it give you an idea of how an automated backup could work with a custom run-level. Finally, the machine gets called back to init 3, which is console only multi-user mode.

Tip:
Again, this is just an idea for a backup script, but not one I would actually run in production in my wildest dreams. One problem with this technique is that because of symbolic links in run level 1, we actually, changed run level 1 and our run level 4. This is not acceptable, obviously, for any sane user, but it is acceptable as a way to have fun with a disposable virtual machine!

If you can think of a more realistic backup script that would work from a custom run-level, I would love to see it. Create a how to on your blog, and then post a response to this article. Also, it would interesting to see other things such as database backups and migration done with custom run-levels as well. Leave a comment and let me know what you'd do.

Running your own run-level

To run the newly created run-level, you only need to type:

init 4

You will then see the custom print statements we inserted. The machine
will sleep for 60 seconds, and then run the rsync backup.

Summary

This article covered quite a bit of ground in a short while. We went over what a run-level was, how to tell what run-level you are at, how to change run-levels, and, finally, how to make your own run-level with custom, frankenstein quality, code. Hopefully, this showed you some new tricks and spurs some ideas for further innovation with run-levels.

References

[Jun 09, 2010] Booting and Shutting Down Your SuSE Linux Enterprise Server init and Understanding Runlevels

InformIT

init and Understanding Runlevels

It is difficult to discuss the init program without first having an understanding of what it controls. The init process is invoked by the kernel itself and becomes the parent of all other processes on a machine. At startup, the /etc/inittab file is interpreted by init and all identified routines are processed. The default runlevel for the system is maintained within inittab.

You can think of a Linux operating system runlevel as the "application state" of the machine. For each distinct state, select processes are functional. Table 3.1 displays the known list of runlevels and their impact on user access.

TABLE 3.1: RUNLEVELS

Runlevel Script Directory Definition
0 rc0.d System is stopped
S rc1.d Single user mode accessed from the boot prompt
1 rc1.d Single user mode
2 rc2.d Multiuser mode but no network available
3 rc3.d Multiuser mode with full network access
4 rc4.d N/A, an unused runlevel
5 rc5.d Multiuser network enabled including the X Windows System
6 rc6.d Forces a machine to reboot

You initiate transitions between states by running the init routine followed by the runlevel. Each transition, in turn, changes which processes are running. The application startups or shutdowns triggered by a change in the runlevel are managed through a series of script files. The directory /etc/init.d is the base directory for a collection of directories, each of which, represents a distinct runlevel. Within each level's directory resides a collection of appropriate scripts for the applications required for the specific runlevel.

When the system enters a particular state, it initiates all the appropriate routines for that state by executing all the script files that begin with the letter S (Start) in the corresponding directory.

Similarly, when the system is leaving a source level for another, the scripts residing in the source directory beginning with the letter K (Kill) are processed. This ensures that all applications that are supposed to run only in a particular level are shut down properly before the system moves onto the next runlevel.

The one exception is one of efficiency. If a start script for a specific application exists in the target level, the stop (Kill) script in the source level is ignored.

As an example, you can examine the change of state from runlevel 3 and runlevel 5 on the xdm application. Xdm is the X Windows System display manager. Referring to Table 3.1, X is available only at runlevel 5. Listing 3.3 show the files associated with xdm in the /etc/init.d/rc5.d directory.

LISTING 3.3: xdm FILES ASSOCIATED WITH RUNLEVEL 5

Castor:/etc/init.d # ls -l rc5.d | grep -e xdm
lrwxrwxrwx  1 root root  6 Jan 5 04:53 K06xdm -> ../xdm
lrwxrwxrwx  1 root root  6 Jan 5 04:53 S16xdm -> ../xdm
Castor:/etc/init.d #

From Listing 3.3, it is possible to see that xdm is both started and stopped as the system enters or leaves runlevel 5. What is also apparent is that both the startup and shutdown scripts are simply links to the same script residing in /etc/init.d. This linking minimizes duplication of the scripts, ensuring a consistent application startup and shutdown independent of target runlevel.

The init process can therefore be defined as a tool used to control which applications are active on a system. You can identify which applications are active within a runlevel by looking at content of the subdirectory for the level in question.

Cool Solutions Runlevels in SUSE Linux

Posted: 3 May 2005

Linux operating systems utilize runlevels to determine the services that should be running and to allow specific work to be done on the system. For example, runlevel one is designated single-user mode without networking and is used for critical system maintenance and troubleshooting. Runlevel three is multi-user text mode. Runlevel five is multi-user graphical mode.

Switching between runlevels is accomplished using the init command. Entering:

# init 5

will change to runlevel five. Changing to runlevel six will reboot the machine and runlevel zero will shut down the machine.

Entering runlevel at the command prompt will output the previous and current runlevels. For example:

#runlevel
N 5

indicates that the machine is in runlevel five. The 'N' indicates that the machine was booted into level five, or no previous runlevel was entered.

As mentioned previously, the different runlevels are configured to run a specific set of services. Each runlevel is configured to start its specified services when starting and to shut down its services when switching to a different runlevel.

As a general rule, turn off all services that are not needed at a given runlevel. Managing the services started in each runlevel is simple and can be done graphically in YaST or at the command line with the chkconfig command.

Managing Runlevel Services With YaST

YaST offers a robust and easy to use runlevel service configuration tool. Access the tool at YaST > System > Runlevel Editor. Within the tool, turn services on or off by selecting the service and then selecting the Enable/Disable buttons.

Selecting expert mode allows the administrator to configure the state of a service in each runlevel.

For example, use the YaST runlevel editor to configure the OpenSLP daemon, slpd, to start in runlevels three and five only. Do the following:

  1. Select YaST > System > Runlevel Editor.
  2. Select the Expert Mode radio button.
  3. In the services list, select slpd.
  4. Use the check boxes to select runlevels three and five. Deselect all other runlevels.
  5. Save changes and exit.

Managing Runlevel Services With chkconfig

Most Linux distributions include the chkconfig command for managing runlevel services. The syntax for chkconfig is specified in the chkconfig man page.

For example, use chkconfig to configure the OpenSLP daemon, slpd, to start in runlevels three and five only. Do the following:

1.Check if slpd is on in the current runlevel

# chkconfig slpd
slpd on

2.Check slpd's configuration for every runlevel.

# chkconfig -l slpd
slpd 0:off 1:off 2:off 3:off 4:off 5:off 6:off

3.Turn slpd on in runlevels three and five.

#chkconfig slpd 35

Understanding Runlevels

Unlike most non-UNIX operating systems which only have 2 modes of functionality (on and off), UNIX operating systems, including Linux, have different runlevels such as "maintenance" runlevel or "multi-user" runlevel, etc.

Runlevels are numbered from 0 to 6 and will vary from one Linux distribution to another. The description for each runlevel functionality is sometimes documented in /etc/inittab.

Runlevel Purpose
0 Shuts down the machine safely. The operating system will also attempt to poweroff the system if possible
1 Single user mode. Only one terminal is available for the (single) user root. All other users are logged out
2[a] Multi-user mode, but does not start NFS. Network services like email or web services are also stopped
3[a] Full multi-user mode. Selected network services are all on.
4[a] Not defined and generally unused
5[a] Like runlevel 3 but runs a Display Manager as well
6 restarts the machine safely
[a] These runlevels may vary in functionality between Linux flavours. But these descriptions correspond to the current LSB specification.

2.2.1. INIT Controls Runlevels

Both init and telinit are used to switch from one runlevel to another. Remember that init is the first program launched after the kernel has accessed the root device.

At boot time init is instructed which runlevel to reach in /etc/inittab with the line:

id:5:initdefault:

When the system is started it is possible to change runlevels by invoking init (or telinit which is a symbolic link pointing at init).

For example we switch to runlevel 4 with either of the next commands:

init 4
telinit 4

The PID for init is always 1. It is possible to find out which runlevel the system is currently in with the command runlevel

runlevel
N 5

The first number is the previous runlevel (or N if not applicable) and the second number is the current runlevel.

Recommended Links



Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotesSomerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose BierceBernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOSProgramming Languages History : PL/1 : Simula 67 : C : History of GCC developmentScripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-MonthHow to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D


Copyright © 1996-2018 by Softpanorama Society. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) in the author free time and without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.

This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...

You can use PayPal to make a contribution, supporting development of this site and speed up access. In case softpanorama.org is down you can use the at softpanorama.info

Disclaimer:

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: January 03, 2020