The init process is always assigned PID 1. The /proc filesystem provides a way to obtain the path to an executable given a PID.
In other words:
nathan@nathan-desktop:~$ sudo stat /proc/1/exe
File: '/proc/1/exe' -> '/sbin/upstart'
As you can see, the init process on my Ubuntu 14.10 box is Upstart. Ubuntu 15.04 uses systemd, so running that command ...
Most answers here are five years old so it's time for some updates.
Ubuntu used to use upstart by default but they abandoned it last year in favor of systemd - see:
Grab your pitchforks: Ubuntu to switch to systemd on Monday (The Register)
Because of that there is a nice article Systemd for Upstart Users on Ubuntu wiki - very detailed ...
You can poke around the system to find indicators. One way is to check for the existence of three directories:
/usr/lib/systemd tells you you're on a systemd based system.
/usr/share/upstart is a pretty good indicator that you're on an Upstart-based system.
/etc/init.d tells you the box has SysV init in its history
The thing is, these are heuristics that ...
To create a job to be started automatically when Ubuntu starts, use the example given here. As written example, suppose to create the following file /etc/init/testservice.conf with sudo:
# testservice - test service job file
description "my service description"
author "Me <email@example.com>"
# Stanzas control when and how a process is ...
This is actually quite a difficult problem. One of the major difficulties is that the places where one most often wants to do this are the places where it's quite likely that one will be in the middle of installing or changing stuff. Another is that there's a subtle but very important difference between the system management toolset that is installed, the ...
You can disable services by running the following command:
sudo update-rc.d -f <service name> disable
Man page excerpt:
When run with the disable [ S|2|3|4|5 ] options, update-rc.d
modifies existing runlevel links for the script /etc/init.d/name by
renaming start links to stop links with a sequence number
equal to the ...
On RPM-based systems, you can query the RPM database to see what package provides /sbin/init. For example:
fedora:~$ rpm -qf /sbin/init
centos:~$ rpm -qf /sbin/init
opensuse:~$ rpm -qf /sbin/init
If you just want the package name, and not version, you could add the ...
Ok, Alex, the point is that all the userspace processes in Linux are started with init process, whose pid is 1. For instance, run pstree to see the tree of your processes, whose root is init.. There are several versions of init process implementation nowadays, most notable are
sysVinit (classical init, still used by some distributions, including older ...
For removing services you must use the -f parameter:
sudo update-rc.d -f <service> remove
For configuring startup on boot, try:
sudo update-rc.d <service> enable
See if the following symlink is created:
or something similar.
The difference is that upstart is an init replacement whereas supervisord is a Process Control System. This explanation is given on the supervisord site:
It shares some of the same goals of programs like launchd,
daemontools, and runit. Unlike some of these programs, it is not meant
to be run as a substitute for init as “process id 1”. Instead it is
For a very detailed look at systemd, starting with the first design drafts (and a detailed critique of existing init systems, including upstart, and how systemd proposes to fix them), go to its home page. Over time, there have been several articles on startup published in LWN. Just be advised that any mention of systemd (or pulseaudio) there triggers ...
They use insserv by default, which still requires the sysvinit package as of Debian 6.0 (Squeeze). It was originally developed and used in OpenSUSE. Links to discussions and reasons for the change to insserv can be found on the Debian Wiki.
There has been much debate over the future of init systems in Debian. The main reason that Debian has not moved on to ...
@warl0ck has it right; wanted to add that this information is documented quite well in the Upstart documentation: http://upstart.ubuntu.com/cookbook/#disabling-a-job-from-automatically-starting
With Upstart 1.3, you can make use of override files and the manual stanza to achieve the same result in a simpler manner :
# echo "manual" ...
I think you are looking for /etc/init/atd.conf:
➜ ~ cat /etc/init/atd.conf
# atd - deferred execution scheduler
# at is a standard UNIX program that runs user-specified programs at
# scheduled deferred times
description "deferred execution scheduler"
start on runlevel 
stop on runlevel [!...
Upstart will consider the job stopped if the main process (what is run if the script or exec stanzas are specified) exits. Upstart will then run the post-start process.
So what is happening is the first script is running and exiting, Upstart is considering the job stopped, then the second script is running and exiting. If you run the stop command on an ...
/lib/systemd/systemd-sysv-install is a hook whose job is to do the non-native enable/disable actions that systemd-sysv-generator and other service management systems will recognize. Ubuntu's /lib/systemd/systemd-sysv-install simply calls Ubuntu's /usr/sbin/update-rc.d. That in turn calls /sbin/insserv. That in turn sees that there's a van Smoorenbug rc ...
As the page you refer to says,
Upstart allows you to set environment variables which will be accessible to the jobs whose job configuration files they are defined in.
The indicates that the variables are set in the environment used by the system daemons at startup. The user environment is configured separately once you log in.
If you want to check ...
At some point over the past couple of months, the upstart script in the tutorial was changed to remove the loop to wait for docker to start. I removed the loop from my upstart scripts and my containers now restart correctly after a reboot.
My /etc/init/service-name.conf script now looks like this:
description "service description" ...
From the Upstart cookbook, Changing the Default Shell. There are 3 options, the first 2 involve changing your default shell from /bin/sh to something else. But the 3rd option looks like it would solve your particular issue.
Use a "here document" (assuming your chosen shell supports them)
within the Job Configuration Files you wish to run with a ...
On debian, you will have sysv scripts, Upstart jobs, and systemd services all installed at once. With Upstart and systemd, the jobs/services will be used if available, and the sysv scripts will be run if no Upstart or systemd jobs/services are available.
This command returning success means Upstart was booted:
test -x /sbin/initctl && /sbin/initctl ...
Upstart was abandoned by its developers when Ubuntu switched to systemd, and was removed from Debian before the release of Debian 9.
The supported init systems in Debian 9 are systemd, sysvinit and (to a far lesser extent) Runit, file-rc and openrc. If you want to use systemd (which is the default), make sure the systemd and systemd-sysv packages are ...
There is also a nice piece of software to assist in this. Its called rcconf.
Just download it using:
sudo apt-get install rcconf
and use it with the command
You get a nice (commandline) interface to disable/enable services.
You'd need to prevent gdm service from starting at boot. The problem is that Ubuntu uses the weird upstart thing... So there are no simple commands to disable booting of some service. You are left with either removing the gdm init script or editing it so that it doesn't run gdm. See this thread for how this can be done.
According to the Upstart cookbook, a built-in feature to run a service as a different user is planned but not implemented yet.
If you have start-stop-daemon, use it.
exec start-stop-daemon --start -u jack --exec /home/jack/myscript.sh
Otherwise, use su (as you did) or sudo. Note that start-stop-daemon always switches to the indicated user (barring errors),...
I'm assuming you are running recent version of ubuntu or a distribution based on upstart. You can check /var/log/daemon.log for errors.
The standard su takes the syntax su [options] [username]. Checkout man 1 su. You might want to try :
su -c "myCommand" anotheruser >> "myLogfile.log"
Also, a couple of things would happen (mostly not desirable)