- Timestamp:
- Jan 24, 2014, 8:52:12 AM (11 years ago)
- Branches:
- clfs-3.0.0-systemd, clfs-3.0.0-sysvinit, master, systemd, sysvinit
- Children:
- 61ad6c0c
- Parents:
- 3a85bbd
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
BOOK/bootscripts/common/usage.xml
r3a85bbd r774f0a37 16 16 17 17 <warning> 18 <para>Please disregard this page until it can be written.</para>18 <para>Please disregard this page until it is complete and verified.</para> 19 19 </warning> 20 <!--21 <para>Linux uses a special booting facility named SysVinit that is22 based on a concept of <emphasis>run-levels</emphasis>. It can be quite23 different from one system to another, so it cannot be assumed that24 because things worked in one particular Linux distribution, they should work25 the same in CLFS too. CLFS has its own way of doing things, but it26 respects generally accepted standards.</para>27 20 28 <para>SysVinit (which will be referred to as <quote>init</quote> from 29 now on) works using a run-levels scheme. There are seven (numbered 0 to 6) 30 run-levels (actually, there are more run-levels, but they are for 31 special cases and are generally not used. See <filename>init(8)</filename> 32 for more details), and each one of those corresponds to the actions the 33 computer is supposed to perform when it starts up. The default 34 run-level is 3. Here are the descriptions of the different run-levels 35 as they are implemented:</para> 21 <sect2> 22 <title>Introduction to Systemd</title> 36 23 37 <literallayout>0: halt the computer 38 1: single-user mode 39 2: multi-user mode without networking 40 3: multi-user mode with networking 41 4: reserved for customization, otherwise does the same as 3 42 5: same as 4, it is usually used for GUI login (like X's <command>xdm</command> or KDE's <command>kdm</command>) 43 6: reboot the computer</literallayout> 24 25 <para>Systemd is a system management daemon designed exclusively for the 26 Linux kernel API. In the Linux startup process, it is the first process to 27 execute in user land; therefore, it is also the parent process of all child 28 processes in user land.</para> 44 29 45 <para>The command used to change run-levels is <command>init46 <replaceable>[runlevel]</replaceable></command>, where47 <replaceable>[runlevel]</replaceable> is the target run-level. For example,48 to reboot the computer, a user could issue the <command>init 6</command>49 command, which is an alias for the <command>reboot</command> command.50 Likewise, <command>init 0</command> is an alias for the51 <command>halt</command> command.</para>30 <para>Systemd's initialization instructions for each daemon are recorded in 31 a declarative configuration file rather than a shell script. For 32 inter-process communication, systemd makes Unix domain sockets and D-Bus 33 available to the running daemons. Because systemd tracks processes using 34 Linux cgroups instead of process identifiers (PIDs), daemons cannot "escape" 35 systemd; not even by double-forking. Systemd is also capable of aggressive 36 parallelization.</para> 52 37 53 <para>There are a number of directories under <filename 54 class="directory">/etc/rc.d</filename> that look like <filename 55 class="directory">rc?.d</filename> (where ? is the number of the 56 run-level) and <filename class="directory">rcsysinit.d</filename>, all 57 containing a number of symbolic links. Some begin with a 58 <emphasis>K</emphasis>, the others begin with an 59 <emphasis>S</emphasis>, and all of them have two numbers following the 60 initial letter. The K means to stop (kill) a service and the S means 61 to start a service. The numbers determine the order in which the 62 scripts are run, from 00 to 99—the lower the number the earlier it 63 gets executed. When <command>init</command> switches to another run-level, 64 the appropriate services are either started or stopped, depending on the 65 runlevel chosen.</para> 38 <para>Among systemd's auxiliary features are a cron-like job scheduler 39 called systemd Calendar Timers, and an event logging subsystem called 40 journal. The system administrator may choose whether to log system events 41 with systemd or syslog. Systemd's logfile is a binary file. The state of 42 systemd itself can be preserved in a snapshot for future recall.</para> 66 43 67 <para>The real scripts are in <filename 68 class="directory">/etc/rc.d/init.d</filename>. They do the actual work, 69 and the symlinks all point to them. Killing links and starting links point 70 to the same script in <filename class="directory">/etc/rc.d/init.d</filename>. 71 This is because the scripts can be called with different parameters like 72 <option>start</option>, <option>stop</option>, <option>restart</option>, 73 <option>reload</option>, and <option>status</option>. When a K link is 74 encountered, the appropriate script is run with the <option>stop</option> 75 argument. When an S link is encountered, the appropriate script is run 76 with the <option>start</option> argument.</para> 44 <para>Systemd provides a replacement for sysvinit, pm-utils, inetd, acpid, 45 syslog, watchdog, cron and atd, and obsoletes ConsoleKit.</para> 77 46 78 <para>There is one exception to this explanation. Links that start 79 with an <emphasis>S</emphasis> in the <filename 80 class="directory">rc0.d</filename> and <filename 81 class="directory">rc6.d</filename> directories will not cause anything 82 to be started. They will be called with the parameter 83 <option>stop</option> to stop something. The logic behind this 84 is that when a user is going to reboot or halt the system, nothing 85 needs to be started. The system only needs to be stopped.</para> 47 </sect2> 86 48 87 < para>These are descriptions of what the arguments make the scripts88 do:</para>49 <sect2> 50 <title>Systemctl</title> 89 51 90 <variablelist> 91 <varlistentry> 92 <term><option>start</option></term> 93 <listitem> 94 <para>The service is started.</para> 95 </listitem> 96 </varlistentry> 52 <para><command>systemctl</command> is the main command used to introspect 53 and control Systemd.</para> 97 54 98 <varlistentry> 99 <term><option>stop</option></term> 100 <listitem> 101 <para>The service is stopped.</para> 102 </listitem> 103 </varlistentry> 55 <variablelist> 104 56 105 <varlistentry>106 <term><option>restart</option></term>107 <listitem>108 <para>The service is stopped and then started again.</para>109 </listitem>110 </varlistentry>57 <varlistentry> 58 <term>List running units:</term> 59 <listitem> 60 <para><command>systemctl</command> or <command>systemctl list-units</command></para> 61 </listitem> 62 </varlistentry> 111 63 112 <varlistentry> 113 <term><option>reload</option></term> 114 <listitem> 115 <para>The configuration of the service is updated. This is used 116 after the configuration file of a service was modified, when the 117 service does not need to be restarted.</para> 118 </listitem> 119 </varlistentry> 64 <varlistentry> 65 <term>List failed units:</term> 66 <listitem> 67 <para><command>systemctl --failed</command></para> 68 </listitem> 69 </varlistentry> 120 70 121 <varlistentry> 122 <term><option>status</option></term> 123 <listitem> 124 <para>Tells if the service is running and with which PIDs.</para> 125 </listitem> 126 </varlistentry> 127 </variablelist> 71 <varlistentry> 72 <term>List avilable unit files:</term> 73 <listitem> 74 <para><command>systemctl list-unit-files</command></para> 75 </listitem> 76 </varlistentry> 128 77 129 <para>Feel free to modify the way the boot process works (after all, 130 it is your own CLFS system). The files given here are an example of how 131 it can be done.</para> 132 --> 78 <varlistentry> 79 <term>Activate a unit immediately:</term> 80 <listitem> 81 <para><command>systemctl start</command> <replaceable>unit</replaceable></para> 82 </listitem> 83 </varlistentry> 84 85 <varlistentry> 86 <term>Stop a unit immediately:</term> 87 <listitem> 88 <para><command>systemctl stop </command><replaceable>unit</replaceable></para> 89 </listitem> 90 </varlistentry> 91 92 <varlistentry> 93 <term>Restart a unit:</term> 94 <listitem> 95 <para><command>systemctl restart </command><replaceable>unit</replaceable></para> 96 </listitem> 97 </varlistentry> 98 99 <varlistentry> 100 <term>Reload unit configuration:</term> 101 <listitem> 102 <para><command>systemctl reload </command><replaceable>unit</replaceable></para> 103 </listitem> 104 </varlistentry> 105 106 <varlistentry> 107 <term>Show status of a unit:</term> 108 <listitem> 109 <para><command>systemctl status </command><replaceable>unit</replaceable></para> 110 </listitem> 111 </varlistentry> 112 113 <varlistentry> 114 <term>Check if a unit is enabled or disabled:</term> 115 <listitem> 116 <para><command>systemctl is-enabled </command><replaceable>unit</replaceable></para> 117 </listitem> 118 </varlistentry> 119 120 <varlistentry> 121 <term>Enable a unit to start during boot:</term> 122 <listitem> 123 <para><command>systemctl enable </command><replaceable>unit</replaceable></para> 124 </listitem> 125 </varlistentry> 126 127 <varlistentry> 128 <term>Disable a unit to not start during boot:</term> 129 <listitem> 130 <para><command>systemctl disable </command><replaceable>unit</replaceable></para> 131 </listitem> 132 </varlistentry> 133 134 <varlistentry> 135 <term>Reload systemd and scan for new or changed units:</term> 136 <listitem> 137 <para><command>systemctl daemon-reload</command></para> 138 </listitem> 139 </varlistentry> 140 141 </variablelist> 142 143 <para>For more information regarding systemd, please refer to the systemd 144 and related man-pages and 145 <ulink url="https://fedoraproject.org/wiki/Systemd">Systemd at 146 FedoraProject</ulink> for documentation, examples, features, and other 147 information.</para> 148 149 </sect2> 133 150 134 151 </sect1>
Note:
See TracChangeset
for help on using the changeset viewer.