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 ...
It turns out that my problem is a known issue between the latest Intel microcode on (some?) Skylake CPUs and recent Linux kernels, which is mainly triggered by sssd. See Ubuntu bug #1759920 “intel-microcode 3.20180312.0 causes lockup at login screen(w/ linux-image-4.13.0-37-generic)”, and also a number of other bugs which turn out to be about ...
A runlevel is a state of the system, indicating whether it is in the process of booting or rebooting or shutting down, or in single-user mode, or running normally. The traditional init program handles these actions by switching to the corresponding runlevel. Under Linux, the runlevels are by convention:
S while booting,
0 while shutting down,
6 while ...
System 5 init will tell you only a small part of the story.
There's a sort of myopia that affects the Linux world. People think that they use a thing called "System 5 init", and that is both what is traditional and the best place to start. Neither is in fact the case.
Tradition isn't in fact what such people say it to be, for starters. System 5 init and ...
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 ...
On any distro using systemd you can automatically load the module via modules-load.d:
create the config file:
open it and edit like this (add the module name):
next time you reboot the module should be automatically loaded
Check if systemd service loaded the module:
systemctl status systemd-...
Here a list of what each file should/shouldn't contain, in my opinion:
[Read every time]
This file is always sourced, so it should set environment variables which need to be updated frequently. PATH (or its associated counterpart path) is a good example because you probably don't want to restart your whole session to make it update. By setting it ...
That entirely depends on what services you want to have on your device.
You can make Linux boot directly into a shell. It isn't very useful in production — who'd just want to have a shell sitting there — but it's useful as an intervention mechanism when you have an interactive bootloader: pass init=/bin/sh to the kernel command line. All Linux ...
/etc/init.d is maintained on ubuntu for backward compatibility with sysvinit stuff. If you actually look at /etc/init.d/rc.local you'll see (also from a 12.04 LTS Server):
### BEGIN INIT INFORMATION
# Provides: rc.local
# Required-Start: $remote_fs $syslog $all
# Default-Start: 2 3 4 5
First of all, the problem is that you are stuck at the boot sequencing.
The boot sequencing method is decided during installation or upgrades. If there are no loops in the dependencies declared by the LSB headers of all installed init.d scripts and no obsolete scripts, the system is converted to dependency based boot sequence.
We have to check for
Loop in ...
Put your script in /etc/network/if-up.d and make it executable. It will be automatically run each time a network interface comes up.
To make it do work only the first time it is run on every boot, have it check for existence of a flag file which you create after the first time. Example:
case "$IFACE" in
Here's the excerpt from http://www.debian-administration.org/articles/28 which seems to answer your question.
Note: In the example script below just add a call to the "start)" section to actually launch your program.
You can test the script's functionality without rebooting the system: call it with the full path and giving it a parameter of "start" or "stop"...
You can use systemd timers to execute script a minute after boot.
First, create service file (/etc/systemd/system/myscript.service):
Then create timer (/etc/systemd/system/myscript.timer):
Description=Runs myscript one minute after boot
# Time to wait ...
When the boot loader calls the kernel it passes it a parameter called root. So once the kernel finished initializing it will continue by mounting the given root partition to / and then calling /sbin/init (unless this has been overriden by other parameters).
Then the init process starts the rest of the system by loading all services that are defined to be ...
I found a wonderful explanation here. However, let me try to put in a shorter format of what I understood in the answer.
While the system boots, it needs an early userspace. It can be
achieved using either initramfs or initrd.
initrd is loaded into ramdisk which is an actual FILE SYSTEM.
initramfs is not a file system.
For initrd ...
VirtualBox comes with a series of command line tools all prefixed with VBox. The command you are looking for is
VBoxHeadless --startvm "my vm name"
You can see a short description of its options via VBoxHeadless --help.
If you don't know the name of the virtual machine you can find out via:
VBoxManage list vms
To to run upon startup on Mac OS X you can ...
su is not a user it's program to run subsequent commands/programs under an alternate identity of another user than the one executing the command. It is very similar to sudo in that regard.
Unless another user is specified both commands will default to running the command under the alternate identity of the root user, the superuser/administrator.
The main ...
rc denotes "run-control",
The multiuser runlevel would be defined as the level at which networking is available and thus connections to the server could be made using those services in lieu of hard-wired console connections.
Mind you, servers are generally managed by a service processor (under various names) which do support network connections and in turn ...
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.
And now, the systemd answer.
You're using Ubuntu version 15. You have systemd. /etc/rc.local is at best a backwards compatibility mechanism in systemd. And as shown by the mess in the AskUbuntu question hyperlinked below, using it can go horribly wrong. So make a proper systemd service unit.
You are creating a local, non-system non-package, service ...
Bash reads a number of different files on startup, even depending on how it's started (see the manual for the description). Then there's stuff like /etc/profile.d/ that aren't directly read by the shell, but can be referenced from the other startup files in many distributions.
You'll have to go through all of those but luckily, you can just grep for the ...
All the files you tried to change are read after you log in. Furthermore, ~/.xinitrc and ~/.xsession are the full set of commands that run in a session; ~/.xinitrc is read if you run xinit or startx from a text mode prompt, and ~/.xsession is read if you run a “custom session” (the name may vary) from a graphical login prompt.
You need to configure your ...
If you start in these, the system will shut down/reboot as soon as it enters the runlevel. A runlevel is essentially just a way of specifying actions you want to take when you enter/leave a certain state, in that respect, once those runlevels are entered they execute programs that prepare the computer to shut down or reboot, respectively.
Look in /etc/rc2.d/. There are probably links to /etc/init.d/xdm and /etc/init.d/kdm which you haven't removed yet.
You can also edit the file /etc/X11/default-display-manager, which includes the full path to the default display manager Debian is using. If you replace the content of that file with /bin/true, you are probably disabling the start of any login-...
The Debian way of setting up iptables on boot is by using the iptables-persistent package.
Simply install the iptables-persistent package, set up the iptables rules like you want them, and then run netfilter-persistent save. (Note that the command starts with netfilter and not iptables.)
See the man page for netfilter-persistent for more details.
Look at init which is the traditional process starter, and runs scripts under /etc/init.d, /etc/rc1.d, etc. and /etc/rc.local, which is probably the location you want.
Some distributions use upstart instead - if so, look at the docs for that.
In either case the exact paths may vary by distro, but this should be enough to get you started.