How to change default runlevel in ubuntu 16.04? How to find default runlevel?

How to find default Runlevel?

The conventional way to check the runlevel in linux distos using runlevel command.

$ runlevel
N 5

The output shows/explains about two things 

1. N -> Indicates the previous runlevel used after reboot.

2. 5 -> Runlevel number 

How to check runlevel in ubuntu 16.04?

Ubuntu 16.04 uses systemd as a init daemon program. so lets have a brief understanding about systemd.

What is Systemd?

systemd is a replacement to the older traditional "System V init" system . systemd stands for system daemon. systemd was designed to allow for better handling of dependencies and have the ability to handle more work in parallel at system startup. systemd supports snapshotting of your system and the restoring of your systems state, keeps track of processes stored in what is known as a "cgroup" as opposed to the conventional "PID" method. systemd is now shipping by default with many popular Linux distributions such as Fedora, Mandriva, Mageia, Arch Linux, CentOS 7, RHEL 7.0 (Red Hat Enterprise Linux) and Oracle Linux 7.0. systemd refers to runlevels as targets.

In the following examples, we will show you how to display and work with different runlevels (targets). The system used to demonstrate the following commands is a RHEL 7.0 Standard Desktop configuration.

Controlling Runlevels

To display the current runlevel of your system, you will need to issue the following command: systemctl -get-default

[root@rhel07a ~]# systemctl get-default
graphical.target

The reply back from the system is "graphical.target". Basically the runlevel "graphical.target" is the equivalent to the traditional runlevel 5, Full user access with Graphical Display and networking.

You can display the new runlevels/targets by issuing the following command:

ls -al /lib/systemd/system/runlevel*

[root@rhel07a /]# ls -al /lib/systemd/system/runlevel*
lrwxrwxrwx. 1 root root 15 Apr 25 10:31 /lib/systemd/system/runlevel0.target -> poweroff.target
lrwxrwxrwx. 1 root root 13 Apr 25 10:31 /lib/systemd/system/runlevel1.target -> rescue.target
lrwxrwxrwx. 1 root root 17 Apr 25 10:31 /lib/systemd/system/runlevel2.target -> multi-user.target
lrwxrwxrwx. 1 root root 17 Apr 25 10:31 /lib/systemd/system/runlevel3.target -> multi-user.target
lrwxrwxrwx. 1 root root 17 Apr 25 10:31 /lib/systemd/system/runlevel4.target -> multi-user.target
lrwxrwxrwx. 1 root root 16 Apr 25 10:31 /lib/systemd/system/runlevel5.target -> graphical.target
lrwxrwxrwx. 1 root root 13 Apr 25 10:31 /lib/systemd/system/runlevel6.target -> reboot.target

From the above we can see that we still have seven different runlevels ranging from system poweroff to system reboot. 

Runlevel	Systemd Description
0	poweroff.target
1	rescue.target
2	multi-user.target
3	multi-user.target
4	multi-user.target
5	graphical.target
6	reboot.target

Traditionally the default runlevel was contained within the "/etc/inittab" file and could be displayed with the following command:
cat /etc/inittab | grep initdefault. This would typically report back with an entry similar to: id:5:initdefault:.

Now if you try to display the "/etc/inittab" file on a system using systemd, you will see a message similar to the following:

[root@rhel07a /]# cat /etc/inittab
# inittab is no longer used when using systemd.
#
# ADDING CONFIGURATION HERE WILL HAVE NO EFFECT ON YOUR SYSTEM.
#
# Ctrl-Alt-Delete is handled by /etc/systemd/system/ctrl-alt-del.target
#
# systemd uses 'targets' instead of runlevels. By default, there are two main targets:
#
# multi-user.target: analogous to runlevel 3
# graphical.target: analogous to runlevel 5
#
# To set a default target, run:
#
# ln -sf /lib/systemd/system/<target name>.target /etc/systemd/system/default.target

Setting a new Default Runlevel

In the following example we are going to change the runlevel from "graphical.target" to "multi-user.target". (Runlevel 5 to Runlevel 3).

To do this we simply issue the following commands:

rm /etc/systemd/system/default.target
ln -s /lib/systemd/system/runlevel3.target /etc/systemd/system/default.target

Alternatively you could issue the link command with the "-f" parameter indicating that the destination file is to be removed:

ln -sf /lib/systemd/system/runlevel3.target /etc/systemd/system/default.target

Here we are first deleting the existing "default.target" and then replacing with our link command. Our new "target.default" will be that of "runlevel3.target".

[root@rhel07a /]# rm /etc/systemd/system/default.target
rm: remove symbolic link ‘/etc/systemd/system/default.target’? y
[root@rhel07a /]# ln -s  /lib/systemd/system/runlevel3.target  /etc/systemd/system/default.target
[root@rhel07a /]# systemctl get-default 
runlevel3.target

Now if we were to reboot the system, it would start in "runlevel 3 - multi-user.target".
To revert back to the original runlevel "runlevel 5 - graphical.target" we would simply issue the following commands:

[root@rhel07a ~]# systemctl get-default 
runlevel3.target
[root@rhel07a ~]# rm /etc/systemd/system/default.target
rm: remove symbolic link ‘/etc/systemd/system/default.target’? y
[root@rhel07a ~]# ln -s  /lib/systemd/system/runlevel5.target  /etc/systemd/system/default.target
[root@rhel07a ~]# systemctl get-default 
runlevel5.target

For the system to switch to the new runlevel, you would need to reboot your system or issue the "init" command followed by the relevant runlevel.

Another Approach:

Ubuntu 16.04 uses systemd instead of init and hence the concept of runlevels is replaced by the term targets. So there is indeed a mapping between init-based runlevels and systemd-based targets:

   Mapping between runlevels and systemd targets
   ┌─────────┬───────────────────┐
   │Runlevel │ Target            │
   ├─────────┼───────────────────┤
   │0        │ poweroff.target   │
   ├─────────┼───────────────────┤
   │1        │ rescue.target     │
   ├─────────┼───────────────────┤
   │2, 3, 4  │ multi-user.target │
   ├─────────┼───────────────────┤
   │5        │ graphical.target  │
   ├─────────┼───────────────────┤
   │6        │ reboot.target     │
   └─────────┴───────────────────┘

Now, to just change the "runlevels" in 16.04, you can use for eg:

sudo systemctl isolate multi-user.target

To make this the default "runlevel", you can use:

sudo systemctl enable multi-user.target
sudo systemctl set-default multi-user.target

The command sudo systemctl set-default multi-user.target does the same operation mentioned in the starting. Which will create the symbolic link . The only difference is "the first method user is creating link default.target manually", whereas in second method "systemd is creating link default.target".

How to run a script at reboot with systemd service?

Run a Script at Reboot Using Systemd service

NOTE: Works on latest linux distos like ubuntu 16.04, which uses systemd as a init service. You can check it by using below command

ls -l /sbin/init

output looks like below
lrwxrwxrwx 1 root root 20 Jan 19 03:34 /sbin/init -> /lib/systemd/systemd

Run the service unit as a normal service - have a look at the [Install] section. So everything has to be thought reverse, dependencies too. Because the shutdown order is the reverse startup order. That's why the script has to be placed in ExecStop=.

The following solution is working for me:

[Unit]
Description=...

[Service]
Type=oneshot
RemainAfterExit=true
ExecStop=<your script/program>

[Install]
WantedBy=multi-user.target

RemainAfterExit=true is needed when you don't have an ExecStart action. 

After creating the file, make sure to systemctl daemon-reload and systemctl enable yourservice.

Note: At ubuntu 16.04 you must have a ExecStart=/bin/true --> which means under [service] add the ExecStart=/bin/true, before ExecStop.

Case study:

You can verify the service working or not based on the message given in the Description under [Unit] section.

If Description=My Magic Script, then after issuing reboot we can see message from the log like "Stopping My Magic Script..." and another print like "Stopped My Magic Script". At startup log shows like "Starting My Magic Script..." and which will execute /bin/true binary and exits.

Important thing to observe is binary gets exited whereas service wont die..why because there is property in service which makes it not to die and the property is "RemainAfterExit=true".

We can see the service status whether it actually died or not by running the below command

systemctl status <service_name>




To get full understanding of each stanza please follow the below systemd manual.

References:

https://www.freedesktop.org/software/systemd/man/systemd.service.html#

 

The Upstart Event System: What It Is And How To Use It?

Introduction

Initialization is a crucial procedure that lies at the heart of any Unix-based operating system to control the operation of every script and service. This is essential in a server environment, where issues can occur at the critical points of startup and shutdown, and where ensuring optimal performance is a priority.

In essence, initialization follows this kind of process:

1. The server boots
2. The init process runs (usually as PID 1)
3. A predefined set of startup tasks activate in sequence

Initialization is responsible for ensuring the cloud server can boot up and shut down cleanly.

Some distributions with a Unix foundation utilize the standard init process for initialization. In this article, we'll take a look at Upstart – a practical and powerful replacement that can supercharge your server's operations.

What's wrong with the classic init?

Traditional initialization follows a linear process: individual tasks load in a predefined sequence as the system boots. This isn't that helpful, especially in rapidly changing situations. To understand why, imagine that, for example, you modified the server's environment by adding an additional storage device.

The initialization process isn't able to take into account sudden changes in environment, meaning that your cloud server would have to be re-initialized before it could recognize the additional storage. On-the-fly detection is what's needed, although it's not a capability of classic initialization procedure.

Booting in a linear sequence also takes time, which is especially disadvantageous in a cloud-based environment where fast deployment is essential.

You may also be concerned about the status of your tasks after the system has loaded. Unfortunately, init is concerned with the sequence only when you're booting up or powering down.

Synchronous boot sequences are no longer desirable. A rigid system could support the systems of yesterday, but today is dynamic.

That's where Upstart comes in – a solution to these problems with advanced capabilities.

Based on real-time events instead of a preset list of tasks in sequence, this replacement init daemon handles the starting and stopping of tasks and monitors these processes while the system is running – "full coverage" is the best way to describe it.

This newly asynchronous processing eliminates the need for a rigid boot sequence. Real-time processing may be messy to conceptualize, but Upstart can support the most complex of systems and keep everything in check by using a structure of jobs.

An Overview of Upstart

Designed with flexibility from the beginning, the Upstart event system utilizes a variety of concepts that differ from conventional initialization systems. The solution is installed by default on Red Hat Enterprise Linux (RHEL) 6, as well as Google's Chrome OS, and Ubuntu, although recent debate has caused confusion over whether this will continue.

Jobs

In the world of Upstart, jobs are working processes, split into task jobs (with a purpose) and service jobs (which can run in the background). There are also abstract jobs – processes that run forever, until stopped by a user with administrative privileges.

Events

Events, however, are the signals or "calls" used to trigger a certain action with a job or another event. The common forms of events refer to the monitoring of a process: starting, started, stopping and stopped.

Emitting Events

The process of broadcasting an event is called "emitting." This is usually caused by a process or job state, although an administrator can also emit an event manually by issuing the initctl emit <event>command. You will notice that the init control command becomes incredibly useful when navigating the plethora of operations associated with Upstart.

Writing Your First Job Configuration

Upstart is known to perform well on Ubuntu, so spin up an Ubuntu 14.04 Droplet before getting started.

Now that you're ready, it's important to understand that a job configuration file must abide by three basic principles to be valid.

• It must not be empty (a file with no content)
• It must not contain any syntax errors
• It must contain at least one command block, known as a stanza

Let's keep it basic for now. In a moment we will create a file called testjob.conf in the /etc/initdirectory. In this case, "init" is just used as the shortened version of "initialization."

Notice the .conf file association – indicating that you'll be writing a job configuration file.

For the purposes of this tutorial, the command-line text editor nano is recommended. Some of these commands may may require administrative privileges with sudo, so check out this article to create an appropriate user.

To create a new configuration file for our test job, run:

sudo nano /etc/init/testjob.conf

Let's now outline the objective. We want this job to write a message and the current timestamp to a log file.

There are two basic stanzas that can help you define the purpose of a job script and who created it: description and author. Write these as your first lines in the file.

description "A test job file for experimenting with Upstart"
author "Your Name"

Now, we want this job to take place after the system services and processes have already loaded (to prevent any conflict), so your next line will incorporate the following event:

start on runlevel [2345]

You may be wondering what a runlevel is. Essentially, it's a single value that represents the current system configuration. The [2345] refers to all the configuration states with general Linux access and networking, which is ideal for a basic test example.

We will then add the execution code. This line starts with exec to indicate that the following commands should be run through the Bash shell:

exec echo Test Job ran at  `date` >> /var/log/testjob.log

Notice this echo command uses backticks to run date as a command and then write the entire message to a log file. If you wrote the word date without backticks, the word itself would be printed instead of the command's output.

Save and close this file.

You can verify that this works by manually starting the job, but let's check the configuration file syntax first:

init-checkconf /etc/init/testjob.conf

If any issues are detected, this command will indicate the specific line number and the problem. However, with the test job you should see output like this:

File /etc/init/testjob.conf: syntax ok

This command can be used for controlling Upstart jobs and other background services, such as a web server.

The basic command syntax is:

sudo service <servicename> <control>

This syntax works with these basic controls:

• restart: this will stop, then start a service
• start: this will start a service, if it's not running
• stop: this will stop a service, if it's running
• status: this will display the status of a service

We want to manually start our test job, so the command should look like this:

sudo service testjob start

Now, check the testjob.log file by running the following command:

cat /var/log/testjob.log

This command will read out the file into the shell; you should see a single line similar to the one below:

Test Job ran at Fri Aug 1 08:43:05 BST 2014

This shows that your test job is set up and ready to go.

Reboot your Droplet, then log in and read the log file again:

cat /var/log/testjob.log

You should see a second line in the log displaying a later timestamp to confirm it ran as an Upstart job.

Test Job ran at Fri Aug 1 08:44:23 BST 2014

This merely scratches the surface of what you can do with Upstart. We'll cover a detailed example later, but for now, let's move on to an explanation of job states and events.

Job States and Events

System jobs reside in the /etc/init/ directory, and user jobs reside in the user's own init directory, ~/.init/.

User jobs run in the user's own session, so they're also known as session jobs. These don't run system-wide and aren't in the PID 1 designation. For the purposes of our test job, we used /etc/init so it could load as the system booted.

Regardless of its type, a job is always defined in a configuration file (.conf) where its filename should represent the service or task involved.

Each of these jobs has a goal – to start or stop. Between these two goals are a set of task states, which define the current actions of the job in regards to the goal. The important states are as follows:

• waiting: the initial state of processing
• starting: where a job is about to start
• pre-start: where the pre-start section is loaded
• spawned: where a script section is about to run
• post-start: where post-start operations take place
• running: where the job is fully operational
• pre-stop: where pre-stop operations take place
• stopping: where the job is being stopped
• killed: where the job is stopped
• post-stop: where post-stop operations take place - to clean up

After the post-start state, the job is defined as running. It stays running until a pre-stop is triggered, where the job gets ready to stop, then the job is killed and the post-stop cleanup procedures take place, if defined.

You can view how a job transitions between states by setting the priority of the Upstart system log (located in the /var/log/upstart/ directory) to debug with this command:

sudo initctl log-priority debug

Remember that states are not events, and events are not states. The four events (starting, started, stopping and stopped) are emitted by Upstart but the task states define the transition between the stages of a job's lifetime.

We're now ready to move on to a more focused example that incorporates elements from your very first configuration by writing a service job. This will demonstrate how you can transition from running basic test configurations to production-ready scripts.

In-Depth Example: A Service Job

Covered briefly in the introduction, a service job involves scripting configuration files that allow processes to run in the background. We'll be setting up a basic Node.js server from scratch.

If you're not familiar with Node, in essence it's a "cross-platform environment for server-side and networking applications" (Wikipedia).

Node.js is a very lightweight package, although it isn't installed by default on Ubuntu 14.04. To get started, go ahead and install it on your cloud server.

sudo apt-get install nodejs

Now, let's get started with the service job. Create a new job configuration file in /etc/init called nodetest.conf. Naming the file with reference to its purpose is essential, so you'll be able to recognize that this service job is for a Node.js test.

sudo nano /etc/init/nodetest.conf

We'll cover the Node application itself later in the example, as it's important to understand the Upstart configuration beforehand.

First things first. Start by entering the job description and author lines to define the configuration.

description "Service for a test node.js server"
author      "Your Name"

We want this Node-powered server application to start when the server is up and running and to stop when it shuts down gracefully. Because of this, make sure to specify both conditions:

start on filesystem or runlevel [2345]
stop on shutdown

Remember the runlevel criteria from earlier? Combined with the filesystem event, this will ensure that the job loads when the server is up and running normally.

Those are the basics, but now it gets more complicated; we're going to use the stanzas we mentioned earlier.

Since this is a server application, we're going to incorporate a logging element in the job configuration. Because we want to log when the Node application starts and stops, we'll be using three different stanzas to separate our service actions - script, pre-start script and pre-stop script.

If you think these sound familiar, you're absolutely right. Pre-start and pre-stop are job states, but they also work in stanzas. What this means is that different commands can be run based on the state the job is in.

However, the first stanza to write is the job script itself. This will get a process ID for the Node background server and then run the application script. Note the indentation of commands inside a stanza – this is essential for syntactically correct formatting.

script

    export HOME="/srv"
    echo $$ > /var/run/nodetest.pid
    exec /usr/bin/nodejs /srv/nodetest.js

end script

Node requires a home directory variable to be set, hence why /srv is exported in the first line of the stanza. Next, $$ is used to get an available process ID and create a PID file for our job. After that's ready, the Node.js application is loaded, which we'll write later.

It's now time to focus on pre-start and pre-stop, which will be used for our simple application logging. The date, along with a starting or stopping message will be appended to a log file for our job:

pre-start script
    echo "[`date`] Node Test Starting" >> /var/log/nodetest.log
end script

Notice that the pre-stop stanza contains another line: removing the PID file as part of the procedure for shutting down the server (what pre-stop does).

pre-stop script
    rm /var/run/nodetest.pid
    echo "[`date`] Node Test Stopping" >> /var/log/nodetest.log
end script

That's the entire Upstart job configuration sorted; here's the whole thing again for reference:

description "Test node.js server"
author      "Your Name"

start on filesystem or runlevel [2345]
stop on shutdown

script

    export HOME="/srv"
    echo $$ > /var/run/nodetest.pid
    exec /usr/bin/nodejs /srv/nodetest.js

end script

pre-start script
    echo "[`date`] Node Test Starting" >> /var/log/nodetest.log
end script

pre-stop script
    rm /var/run/nodetest.pid
    echo "[`date`] Node Test Stopping" >> /var/log/nodetest.log
end script

Save and close the file.

As noted in the exec line, a Node.js script is run from the server, so create a nodetest.js file in your desired location (/srv/ is used for this example):

sudo nano /srv/nodetest.js

As this is an Upstart tutorial, we won't spend too long reviewing the Node.js code, although here's a rundown of what this script will accomplish:

• Require and load Node's HTTP module
• Create an HTTP web server
• Provide a status 200 (OK) response in the Header
• Write "Hello World" as output
• Listen on port 8888

Here's the code you need to get the Node application running, which can be copied directly to save time:

var http = require("http");

http.createServer(function(request, response) {
    response.writeHead(200, {"Content-Type": "text/plain"});
    response.write("Hello World");
    response.end();
}).listen(8888);

After saving the Node.js file, the last thing to check is if the Upstart job syntax is valid. As usual, run the configuration check command and you should receive a confirmation as output:

init-checkconf /etc/init/nodetest.conf 

File nodetest.conf: syntax ok

You've got your job configuration, checked its syntax, and have your Node.js code saved - everything's ready to go, so reboot your Droplet and then visit http://IP:**8888**, or the associated domain.

If you're met with "Hello World" in the top-left corner of the window, the Upstart service job has worked!

For confirmation of the state-based logging, read the predefined log file and you should see a timestamped Starting line. Shutting the server down or manually stopping the Service Job would write a Stopping line to the log, which you can also check if you wish.

cat /var/log/nodetest.log

[Sun Aug 17 08:08:34 EDT 2014] Node Test Starting
[Sun Aug 17 08:13:03 EDT 2014] Node Test Stopping

You can run starndard start, stop, restart, etc. commands for this service, and any other similar Upstart jobs, with syntax like the following:

sudo service nodetest restart

Conclusion

This tutorial only scratches the surface of the Upstart Event System.