Init function in linux

What exactly does init do?

I am creating a linux distro and now I need an init program. I can code in c really well and I know quite a bit about linux (not much but I’ve been using arch linux for development for 4 years), so I thought I should try writing my own basic init script in C. I was just wondering, what tasks does init do to set the system up for a simple shell? (When I ask «what does init do?», I do know what init is and what it’s for. I just don’t know what tasks it does.) I don’t need code and I possibly don’t even need basic commands but I do need the order that they are run in.

You can use whatever interpreter you like for SysV-style init scripts, including Perl, awk, bash, (t)csh, native binaries, . Bash is normally used because it’s virtually guaranteed to be available on the system where such scripts are deployed at the relevant point in the boot process, not because there is some coupling between SysVinit and bash. SysVinit defines the contract and each script is free to implement that contract in any way its developer sees fit.

5 Answers 5

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 System 5 rc date to AT&T UNIX System 5, which was almost as far after the first UNIX as we are now (say) after the first version of Linux-Mandrake.

1st Edition UNIX only had init . It did not have rc . The 1st Edition assembly language init (whose code has been restored and made available by Warren Toomey et al.) directly spawned and respawned 12 getty processes, mounted 3 hardwired filesystems from a built-in table, and directly ran a program from the home directory of a user named mel . The getty table was also directly in the program image.

It was another decade after UNIX System 5 that the so-called «traditional» Linux init system came along. In 1992, Miquel van Smoorenburg (re-)wrote a Linux init + rc , and their associated tools, which people now refer to as «System 5 init «, even though it isn’t actually the software from UNIX System 5 (and isn’t just init ).

System 5 init / rc isn’t the best place to start, and even if one adds on knowledge of systemd that doesn’t cover half of what there is to know. There’s been a lot of work in the area of init system design (for Linux and the BSDs) that has happened in the past two decades alone. All sorts of engineering decisions have been discussed, made, designed, implemented, and practised. The commercial Unices did a lot, too.

Читайте также:  Arch linux wifi connection

Existing systems to study and and learn from

Here is an incomplete list of some of the major init systems other than those two, and one or two of their (several) salient points:

  • Joachim Nilsson’s finit went the route of using a more human-readable configuration file.
  • Felix von Leitner’s minit went for a filesystem-is-the-database configuration system, small memory footprints, and start/stop dependencies amongst things that init starts.
  • Gerrit Pape’s runit went for what I have previously described as the just spawn four shell scripts approach.
  • InitNG aimed to have dependencies, named targets, multiple configuration files, and a more flexible configuration syntax with a whole load more settings for child processes.
  • upstart went for a complete redesign, modelling the system not as services and interdependencies at all, but as events and jobs triggered by them.
  • The design of nosh includes pushing all of the service management out (including even the getty spawning and zombie reaping) into a separate service manager, and just handling operating-system-specific «API» devices/symlinks/directories and system events.
  • sinit is a very simple init. It executes /bin/rc.init whose job it is to start programs, mount filesystem, etc. For this you can use something like minirc.

Moreover, about 10 years ago, there was discussion amongst daemontools users and others of using svscan as process #1, which led to projects like Paul Jarc’s svscan as process 1 study, Gerrit Pape’s ideas, and Laurent Bercot’s svscan as process 1.

Which brings us to what process #1 programs do.

What process #1 programs do

Notions of what process #1 is «supposed» to do are by their natures subjective. A meaningful objective design criterion is what process #1 at minimum must do. The kernel imposes several requirements on it. And there are always some operating-system-specific things of various kinds that it has to do. When it comes to what process #1 has traditionally done, then we are not at that minimum and never really have been.

There are several things that various operating system kernels and other programs demand of process #1 that one simply cannot escape.

People will tell you that fork() ing things and acting as the parent of orphaned processes is the prime function of process #1. Ironically, this is untrue. Dealing with orphaned processes is (with recent Linux kernels, as explained at https://unix.stackexchange.com/a/177361/5132) a part the system that one can largely factor out of process #1 into other processes, such as a dedicated service manager. All of these are service managers, that run outwith process #1:

  • the IBM AIX srcmstr program, the System Resource Controller
  • Gerrit Pape’s runsvdir from runit
  • Daniel J. Bernstein’s svscan from daemontools, Adam Sampson’s svscan from freedt, Bruce Guenter’s svscan from daemontools-encore, and Laurent Bercot’s s6-svscan from s6
  • Wayne Marshall’s perpd from perp
  • the Service Management Facility in Solaris 10
  • the service-manager from nosh

Similarly, as explained at https://superuser.com/a/888936/38062, the whole /dev/initctl idea doesn’t need to be anywhere near process #1. Ironically, it is the highly centralized systemd that demonstrates that it can be moved out of process #1.

Читайте также:  Linux менеджер базы данных

Conversely, the mandatory things for init , that people usually forget in their off-the-top-of-the-head designs, are things such as handling SIGINT , SIGPWR , SIGWINCH , and so forth sent from the kernel and enacting the various system state change requests sent from programs that «know» that certain signals to process #1 mean certain things. (For example: As explained at https://unix.stackexchange.com/a/196471/5132, BSD toolsets «know» that SIGUSR1 has a specific meaning.)

There are also once-off initialization and finalization tasks that one cannot escape, or will suffer greatly from not doing, such as mounting «API» filesystems or flushing the filesystem cache.

The basics of dealing with «API» filesystems are little different to the operation of init rom 1st Edition UNIX: One has a list of information hardwired into the program, and one simply mount() s all of the entries in the list. You’ll find this mechanism in systems as diverse as BSD (sic!) init , through the nosh system-manager , to systemd.

«set the system up for a simple shell»

As you have observed, init=/bin/sh doesn’t get «API» fileystems mounted, crashes in an ungainly fashion with no cache flush when one types exit (https://unix.stackexchange.com/a/195978/5132), and in general leaves it to the (super)user to manually do the actions that make the system minimally usable.

To see what one actually has no choice but to do in process #1 programs, and thus set you on a good course for your stated design goal, your best option is to look at the overlaps in the operation of Gerrit Pape’s runit, Felix von Leitner’s minit, and the system-manager program from the nosh package. The former two show two attempts to be minimalist, yet still handle the stuff that it is impossible to avoid.

The latter is useful, I suggest, for its extensive manual entry for the system-manager program, which details exactly what «API» filesystems are mounted, what initialization tasks are run, and what signals are handled; in a system that by design has the system manager just spawn three other things (the service manager, an accompanying logger, and the program to run the state changes) and only do the unavoidable in process #1.

Источник

How to use init-functions? [closed]

Want to improve this question? Update the question so it focuses on one problem only by editing this post.

Every Operating System has Librarys. Most of them gives you the opportunity to do more ore to write less code. inti-functions is one of these Librarys but. What is init-functions and how to use it?

init-functions is an artifact of SysV init, which is generally speaking an antiquated chunk of code that should never be used for new development. Modern best practice is to use a proper process supervision system (systemd, upstart, runit, launchd, etc) — not traditional «init scripts».

See the sample run scripts at smarden.org/runit/runscripts.html — you’ll note that they’re pretty much universally under five lines total, and thus don’t need any kind of library support at all. Other process supervision systems’ configuration may be less terse, but that they make init-functions outdated and irrelevant is universal.

Читайте также:  Как ставить виндовс линукс

1 Answer 1

In Linux you are able to use init-functions to manage deamons and protocol in a colored & uniform way. This is way easier to handle than recolor every answer.

It is stored in /lib/lsb/ under the name init-functions .

#!/bin/bash # Script by Amir Boudani ©Amir Boudani source /lib/lsb/init-functions # Importing init-functions - log messages # Use for importing other scripts ore else: "source" / "." # Use at the beginning of the path "/" to say that the path has to start from the root directory log_success_msg "Starting test.sh" || true echo log_action_msg "Info message" || true # Info message log_success_msg "Checking Files" || true # Success message log_warning_msg "Free storage is under 10%" || true # Warning message log_failure_msg "Starting unknown script files" || false # Failure message echo log_end_msg 0 || true # End message - success - resetting the line above -> log_daemon_msg log_end_msg 1 || true # End message - failure - resetting the line above -> log_daemon_msg log_end_msg 255 || true # End message - warning - resetting the line above -> log_daemon_msg echo log_progress_msg "copying file 2123" # One of the line resetting comands - progress echo echo log_daemon_msg "Integrate files" || true sleep 2 log_end_msg 0 || true log_daemon_msg "Checkt if the directory 4234 exist" || true sleep 2 log_end_msg 1 || true log_daemon_msg "Storage space checking " || true sleep 2 log_end_msg 255 || true echo echo log_daemon_msg "Checking Filestorage" || true sleep 1 log_progress_msg "Checking File 1" || true sleep 1 log_progress_msg "Checking File 2" || true sleep 1 log_progress_msg "Checking File 3" || true sleep 1 log_progress_msg "Checking File 4" || true sleep 1 log_end_msg 0 || true echo #---------------------------------------------------------------# Method 1 - not working for commands that are self responding $checker # A variable that doesn't exist. To trigger an error code log_daemon_msg "Check if the last command was an Error" || true if [ "$?" -eq "0" ] # "$?" is the errorcode number of the last command. | 0 = There was no Errors | 1 = Error code 1 then log_end_msg 0 || true else log_end_msg 1 || true echo " There went something wrong. see log" fi #---------------------------------------------------------------# A way to check if a directory exist #if [ -d "/opt/scripts" ] # Check if directory exist - example at this line: if directory /opt/scripts exist # -d = check if the following directory exitst # -a = check if the following file exsist #if [ ! -d "/opt/scripts" ] # ! is a negativ operator - example at this line: if directory /opt/scripts NOT exist # You can actually use the ! operator anywhere #---------------------------------------------------------------# Method 2 - working for self responding commands. but the log_daemon_msg ist not working so we take log_succes/warning/failure_msg echo echo "type in: false / true / (nothing)" read var1 case $var1 in # Check if variable var1 is true true) log_success_msg "Check if var1 is true" || true ;; false) log_warning_msg "Check if var1 is true" || true echo -e " \e[33mvar1 is false.\e[0m" ;; *) log_failure_msg "Check if var1 is true" || true echo -e " \e[31mthere was no input in the read statment.\e[0m" ;; esac 

Источник

Оцените статью
Adblock
detector