chaos' answer is what some documentation says. But it's not what systemd actually does. (It's not what van Smoorenburg rc did, either. The van Smoorenburg rc most definitely did not ignore LSB headers, which insserv used to calculate static orderings, for starters.) The Freedesktop documentation, such as that "Incompatibilities" page, is in fact wrong, ...
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 ...
There are currently 3 main init systems used by linux. A few years ago, there was just one, SysVinit. But SysVinit was seriously lacking in capabilities such as service dependency graphing, so it's been deprecated in most distros by now. Currently most distros are switching to systemd. Though there is also upstart.
But here's the answer to your question for ...
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 ...
My systemd service kept timing out because of how long it would take to boot up also, so this fixed it for me:
Edit your systemd file:
For modern versions of systemd: Run systemctl edit --full node.service (replace "node" with your service name).
This will create a system file at /etc/systemd/system/node.service.d/ that will override the system file at /...
I don't know about raspbian, but since it is derived from Debian, I assume
nohup will be available too. Instead of running a process as,
$ proc &
try to use:
$ nohup proc &
The nohup will prevent the process from being terminated when the terminal disconnects. HTH.
Your question was a little lacking in details, so I'm assuming that you mean that you typed the command to start your server on the console of your Pi, and it executed in the foreground.
If this is the case, you have five options, ordered by complexity to implement:
Use @f-tussel's answer. Since you're new to GNU/Linux, the & symbol tells the shell ...
init.d, also known as SysV script, is meant to start and stop services during system initialization and shutdown. (/etc/init.d/ scripts are also run on systemd enabled systems for compatibility).
The script is executed during the boot and shutdown (by default).
The script should be an init.d script, not just a script . It should support start and stop and ...
Let's forget init.d or rcx.d and keep things very simple. Imagine you were programming a program whose sole responsibility is to run or kill other scripts one by one.
However your next problem is to make sure they run in order. How would you perform that?
And lets imagine this program looked inside a scripts folder for running the scripts. To order the ...
If you'd like to reuse your code sample, it could look something like:
case "$1" in
kill `cat /var/run/hit.pid`
if [ -e /var/run/hit.pid ]; then
echo hit.sh is running, pid=`cat /var/...
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 ...
I believe CentOS 7 and above uses systemd. If that is the case for your system, try the following:
Place the script commands you wish to run in /usr/bin/myscript.
Remember to make the script executable with chmod +x.
Create the following file:
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 ...
Systemd is backward compatible with SysV init scripts. According to LSB 3.1, the init script must have informational Comment Conventions, defining when the script has to start/stop and what is required for the script to start/stop. This is an example:
### BEGIN INIT INFO
# Provides: my-service
# Required-Start: $local_fs $network $remote_fs
# Required-Stop: ...
It seems you are running a system with systemd yet you are using sysV commands. Did you create a sysV init script or a systemd unit file?
State active (exited) means that systemd has successfully run the commands but that it does not know there is a daemon to monitor.
If there is you must define it in the unit file by configuring the Type and ExecStart ...
The purpose of these files is to provide an easy means for other processes to communicate with them (e.g. send signals). This only makes sense for long running services, that’s why you find much less such files than processes running.
Usually those files are created by the service they represent, you will find a parameter like --pid-file or so in the ...
init is the conventional name of the program that runs in process #1. It has taken many forms over the years, and the tasks that init programs have performed have significantly varied. Confusingly, it is also the name of a command that administrators use to communicate with process #1. They are best regarded as two separate things, and were certainly ...
Firstly, a clarification is in order:
init.d is the directory that stores services control scripts, which control the starting and stopping of services such as httpd or cron
rc.local is a service that allows running of arbitrary scripts as part of the system startup process
In terms of whether its better to use rc.local or cron to run your script, I ...
OK, I did a lot of extensive research and I found out what was wrong. Let's start one by one:
When we use initramfs boot scheme the first process which the kernel invokes is the /init script. The kernel will never try to execute /sbin/init directly.
/init is assigned process identifier 1. This is very important!
The problem now is that /sbin/init can only ...
Good question. The only reference I've found to those files is in man insserv:
The make(1) like dependency files produced by insserv for booting,
starting, and stopping with the help of startpar(8).
And in fact, running just plain insserv touches ...
Lots of questions...
The basic answer to your question is yes each script is run in its own shell, or rather each process that gets exec'd contains a copy of the base environment + these variables that get included by this sourcing + any additional environment variables that are included when the service starts up.
Moving these includes, like vars.sh, to ...
There's some files in /etc/init.d/ directory:
$ ls -al /etc/init.d/ | grep -i depend
-rw-r--r-- 1 root root 2739 Feb 17 05:20 .depend.boot
-rw-r--r-- 1 root root 2221 Feb 17 05:20 .depend.start
-rw-r--r-- 1 root root 1855 Feb 17 05:20 .depend.stop
Whenever you run update-rc.d the files will change. .depend.boot file is for S level, .depend.start ...
Running systemctl show SERVICE_NAME.service -p TimeoutStopUSec I could at least see the timeout set by systemd to my service.
I changed the script to a regular unit file one in order for it work properly.
systemd is not backwards compatible with System 5 init, only System 5 rc.
Linux System 5-style system management comprises two parts, init which runs as process #1 and rc which is in charge of running start and stop scripts. These are actually from two distinct packages in Debian. init is from the sysvinit package; and rc is usually from the sysv-rc ...
There are several different init systems for Linux. The main ones are SysVinit (the traditional one), Upstart (Ubuntu's replacement), and SystemD (pushed by Fedora and Gnome). The directories /etc/init.d and /etc/rc?.d are used by SysVinit. The book may be mentioning them with regards to Ubuntu because the information is a bit dated (Ubuntu used to use ...
Different distributions use different mechanisms to manage services. The software to manage services is called init, after the traditional name for the very first process (with process ID 1) which is in charge of starting the others.
Debian uses the traditional SysVinit variant of init. Under this system, there is a collection of scripts in the directory /...
Nothing. Different Linux distributions, and the LSB, had different standards, so both are present on CentOS to make it easier to run software from different versions. One is just a symbolic link to the other.
http://www.centos.org/docs/5/html/5.1/Installation_Guide/s2-boot-init-shutdown-init.html gives details on the boot process, but ultimately all the ...
The chkconfig utility can do this. Unlike RHEL or SLES, it does not come installed by default in Debian, but it is a good end-user tool for sysvinit configuration. To list all sysvinit services: