System Startup

July 2, 2016   

Startup

This graph shows how the processes of starting up the system works.

Linux Boot Sequence

This Graph is from thegeekstuff.com

This is a great resource to explore more Linux boot process

Shutdown, Halt, and Reboot

Commands:

  • shutdown: you could write wall message to users, schedule reboot or shutdown, cancel scheduled reboot or shutdown.
  • reboot: shutdown, and reboot are the same actually reboot call shutdown -r.
  • init and telinit:

    • init 6 and telinit 6: will reboot
    • init 0 and telinit 0: will shutdown.
  • systemctl: for systemd to control power management and services. It is the recommended way.

systemctl will replaces all power management commands except for shutdown. shutdown will call systemctl and has advantage of supporting a time argument.

Init process

  • SysVinit
  • Upstart
  • systemd

SysVinit

It uses bash scripts to manage services. It is old and not designed for modern hardware and personal computer. It runs through serial procedures.

Runlevel

  • 0: Shutdown the system.
  • 1: Single User Mode, for administrative tasks. Sometimes, s and S are used for this runlevel.
  • 2: Multi-user mode without networking and display manager.
  • 3: Multi-user mode with networking and without display manager
  • 4: Not used/user-definable For special purposes.
  • 5: Start the system normally with networking and display manager.
  • 6: Reboot.

Check current runlevel:

$ runlevel

first letter of the output means previous runlevel, N means unknown

Change runlevel:

$ sudo telinit 5

Checking which scripts to run in each runlevel

ls -l /etc/rc[0-6].d/

Notes:

  • /etc/rc[0-6].d/ are just link to scripts that are located in /etc/init.d/*
  • Start With S means start, with K means Kill
  • Numbered to run in order.
  • chkconfig, used in RHEL, makes handle of links in an easy way.

    • chkconfig --list service_name -> to see the service run it which runlevels
    • chkconfig service_name on -> Turn on the service in the next boot. it will use the default runlevels defined in the script. If you want to override them pass this arg --level 345 3, 4, and 5 are the runlevels
    • chkconfig service_name off -> Turn off the service in the next boot.
  • update-rc.d, is the default tool in Ubuntu. chkconfig are not availabe in Ubuntu repository.

  • sysv-rc-conf is an alternative to chkconfig that have same syntax. You could install it in Ubuntu. Also it supports the --list option, whereas update-rc.d does not support this.

  • There is an alternative way, manual way, to check a service run in which runlevels. ls /etc/rc* -> it will show all the files in all runlevels and by looking at them you could find what you want.

  • These will not change the current state of the service. it will happen at the boot time.

  • The tools determine which order of S and K by adding # chkconfig 2345 10 90 in the top lines of the script.

    • 2345 means default run in 2, 3, 4, and 5 runlevels
    • 10 means S10
    • 90 means K90
  • To check service status and do start or stop the status in the current system. These commands do so:

    • service: have a unique option –status-all to show the status of the services.
    • invoke-rc.d: it is more native command and suggested to be used by packages’ maintainer scripts

Upstart

Example of upstart.conf

# logs to /var/log/upstart/my_project.log

description "my_project"
start on startup
stop on shutdown

respawn
setuid user_name
setgid group_name
chdir project_path

# start from virtualenv path
exec /virtualenv_path/my_project/bin/gunicorn my_project.wsgi:application --workers 4 -b 127.0.0.1:8080

systemd

Nowadays, almost all new distributions are using systemd as default init process. It is backward compatible with SysVinit and the concept of runlevels via runlevel targets. It is easier, replace shell scripts, and faster. It enable cgroups to be used in each service.

cgroups is a Linux kernel feature that limits, accounts for, and isolates the resource usage (CPU, memory, disk I/O, network, etc.) of a collection of processes. From wikipedia

systemctl

It controls the systemd system and service manager.

As described early it can be used for power managements(shutdown, reboot, etc).

Syntax:

systemctl [option] command [name]
  • systemctl -> to show the status of everything systemd control -
  • systemctl list-units -t service --all -> to show all available services
  • systemctl list-units -t service -> to show active services
  • sudo systemctl start nginx -> to start nginx service. You could use start, status, stop, restart, and reload
  • sudo systemctl start nginx.service -> unit could be a socket so when you specify .service you mean the service.
  • sudo systemctl enable nginx.service is equivalent to chkconfig service_name on start the service at boot time.
  • sudo systemctl disable nginx.service is equivalent to chkconfig service_name off don’t start the service at boot time.

Configurations

Enable user mode

  • loginctl show-user username if not enabled for that user and you are not logged in with that user, you should see this message Failed to get user: No user 1000 known or logged.
  • open session for a user: loginctl enable-linger username
  • loginctl show-user username now if you are not logged in with that user you should see State=lingering

Load Path

  • system wide:

    • System configuration path /etc/systemd/user.conf
    • Units provided by user in system-wide, placed by the system administrator /etc/systemd/system/
    • Units provided by installed packages in system-wide: /lib/systemd/system/{app-name}.service
  • user mode:

    • User configuration path ~/.config/systemd/user.conf
    • Units provided by user in user mode $HOME/.config/systemd/user/
    • Units provided by installed packages in user mode $HOME/.local/share/systemd/user/

Example

[Unit]
Description=Job that runs the {app-name} daemon

# Automatic Dependencies: Note that while systemd offers a flexible dependency system between units it is recommended to use this functionality only sparingly and instead rely on techniques such as bus-based or socket-based activation which make dependencies implicit, resulting in a both simpler and more flexible system.
# After=nginx.service memcached.service
# Requires=nginx.service memcached.service

# AssertPathExists={/srv/www}

[Service]
WorkingDirectory={/path/to/apps}
ExecStart={/path/to/virtualenvs/app-name/bin/python manage.py runserver}
# ExecStop=...
Group={group_name}
User={user_name}

[Install]
WantedBy=multi-user.target
# WantedBy=default.target # for user mode

security configuration explained:

User mode:

  • if this error appear: Failed to connect to bus: No such file or directory run this on the same user the error appear:
  export XDG_RUNTIME_DIR=/run/user/`id -u` # https://answers.launchpad.net/ubuntu/+source/systemd/+question/287454
  echo "XDG_RUNTIME_DIR=/run/user/$(id -u)" >> ~/.pam_environment # http://askubuntu.com/a/538421
  # if needed reboot the system
  • Start app-name in user mode: systmctl --user start app-name.service

  • Check status for app-name in user mode: systemctl --user status app-name.service

  • Check user mode status systemctl --user status

  • To start it now systemctl --user start price-watcher.service

  • To enable running the service after reboot systemctl --user enable price-watcher.service

  • To check enabled targets for user mode systemctl --user -t target

  • To check dependencies for a target systemctl --user list-dependencies default.target

  • To check failed units systemctl --failed --all

I have tried to use user mode in services, but dbus problems appear to me a lot and tried to solve them but I could not, so I switched to system mode. I am hoping to come back to this and use user mode. Resources:

References:

  • upstart example hub.com/lincolnloop/django-best-practices/blob/master/examples/upstart.conf)


comments powered by Disqus