Handbook Talk:AMD64/Working/Initscripts
Before creating a discussion or leaving a comment, please read about using talk pages. To create a new discussion, click here. Comments on an existing discussion should be signed using
~~~~
:
A comment [[User:Larry|Larry]] 13:52, 13 May 2024 (UTC) : A reply [[User:Sally|Sally]] 11:36, 5 November 2024 (UTC) :: Your reply ~~~~
Fix sentences
"Then, the boot loader instructs the CPU to run execute kernel" should become either "Then, the boot loader instructs the CPU to run the kernel" or "Then, the boot loader instructs the CPU to execute the kernel".
Fturco (talk) 13:39, 17 April 2017 (UTC)
- Fixed. Thank you for catching this typo! --Maffblaster (talk) 17:40, 17 April 2017 (UTC)
Suggested changes
Following are some changes i suggest for the page. -- Flexibeast (talk) 08:14, 14 October 2024 (UTC)
General comment: The page isn't consistent its use of 'initscript' vs 'init script'; the former is more common earlier in the page, the latter more common later in the page . So a decision should be made on which to use.
"Runlevels" section
"Booting the kernel" section
Then, the boot loader instructs the CPU to execute the kernel.
The init process makes sure that all filesystems ...
Finally, once all scripts have been executed, init activates the virtual consoles accessible via Ctrl+Alt+ F1, Ctrl+Alt + F2, etc.), attaching to each one a special process called agetty. This process ensures users are able to log on via login.
"Initscripts" section
The scripts in /etc/init.d/ aren't executed randomly. init doesn't run all scripts in /etc/init.d/, only the scripts it is told to execute, via /etc/runlevels/.
Once all scripts referenced in /etc/runlevels/boot/ have been executed, init will run the scripts linked in /etc/runlevels/default/.
This is why commands used during the installation of Gentoo Linux use the
default
runlevel (e.g. rc-update add sshd default
)."How init works" section
The /etc/inittab file is used by init to determine the actions it needs to take.
As described above, init's first action is to mount all file systems.
The line that defines level 3, again uses the openrc script to start the services (now with argument
default
). Also note again that the argument to openrc is the same as the subdirectory from /etc/runlevels/."Available runlevels" section
do exactly what their names imply: initializing the system
The boot runlevel starts all system-necessary services used by all the other runlevels. The remaining three runlevels differ in what services they start: default is used for day-to-day operations, nonetwork is used in case no network connectivity is required, and single is used when the system needs to be fixed.
"Working with initscripts" section
General comment: this section talks of 'depending' services; i feel 'dependent' would be more the more appropriate word.
The scripts that the openrc process starts are called init scripts.
To get the status of a service (started, stopped, ...), use the status argument:
but are not necessary for the correct functioning of the service.
"Updating runlevels" section
"rc-update" section
Gentoo's init system uses a dependency tree
In earlier instructions, init scripts have already been added to the default runlevel. What default means has been explained earlier in this document.
In addition to the runlevel, the rc-update script requires a second argument specifying the appropriate action:
add
, del
, or show
.will show all the available init scripts and the runlevels in which they will execute:
"Configuring services" section
"Why additional configuration is needed" section
It is therefore not desirable to have users edit init scripts directly, as it would make them more error-prone.
However, it's important to be able configure services: for instance, users might want to run the service with additional options.
"Writing initscripts" section
"Is it necessary?" section
entoo's init scripts are not compatible with the init scripts used by other distributions, unless the other distribution is using OpenRC.
"Dependencies" section
There are three dependency-related settings which can influence the start-up or sequencing of init scripts:
These last two are not dependencies per se - they don't make the init script fail if the specified dependency isn't scheduled to start (or fails to start).
The
use
setting informs the init system that the script uses functionality offered by the selected scriptSome examples are
use logger
and use dns
: if the services are available, they will be used, but if the system does not have a logger or DNS server, the services will still work.use
only considers services which were added to a runlevel; want
will try to start any available service even if not added to any runlevel.The
need
setting indicates a hard dependency: a script that need
s another script will not start before the latter script is started successfully.Also, if the
need
ed script is restarted, the script needing it will be restarted as well.The
before
setting ensures the script is launched before a specified script, if the latter is part of the runlevel.So an init script xdm that defines
before alsasound
will start before the alsasound script, but only if alsasound is scheduled to start in the same runlevel. If alsasound is not scheduled to start in that runlevel, then the before
has no effect, and xdm will be started when the init system deems it most appropriate.Similarly,
after
informs the init system that the given script should be launched after a specified script if the latter is part of the same runlevel.It should be clear from the above that
need
is the only "true" dependency setting, as it affects whether the script will be started or not. All the others merely tell the init system the order in which scripts can be (or should be) started.Suggest adding "Virtual dependencies" as a section heading prior to the following:
Many of Gentoo's init scripts depend on things that are themselves not init scripts: virtual dependencies.
For instance, consider the dependency information in the postfix script:
As can be seen, the postfix service:
In the list of points, suggest wrapping "net", "logger", "dns", and "mta" in <code> tags.
"Controlling the order" section
through the dependency settings
use
and need
, but also through the order settings before
and after
.As we have described these earlier already, let's take a look at the portmap service as an example of such init script.
It's possible to use the
*
glob to refer to all services in the same runlevel, although this isn't advisable.If the service must write to local disks, it should
need localmount
. If it places anything in /var/run/, such as a PID file, then it should start after bootmisc
:"Standard functions" section
In addition to the
depend()
functionality, it's also necessary to define the start()
function. This function contains all the commands necessary to initialize the service. It's advisable to use the ebegin
and eend
functions to inform the user about what's happening:Both
--exec
and --pidfile
should be used in start()
and stop()
functions. If the service doesn't create a PID file, then use --make-pidfile
if possible, though it is recommended to test this to be sure. Otherwise, don't use PID files.Note also that the above example check the contents of the RC_CMD variable. OpenRC doesn't support script-specific restart functionality; instead, the script needs to check the contents of the RC_CMD variable to see if a function (e.g.
start()
or stop()
) is being called as part of a restart or not.(for example, from
foo.py
to foo
)it is necessary to add
--name
as an option to start-stop-daemon.which changes names to
foo
start-stop-daemon has an excellent man page
Gentoo's init script syntax is based on the POSIX shell ('sh'), so people are free
Keep other constructs, like Bash-specific ones, out of init scripts to ensure that the scripts remain functional regardless of any changes Gentoo might make to its init system.
Perhaps it might be useful to here link to the Shell/Scripting page i've been working on?
"Adding custom options" section
If the initscript needs to support an option other than the ones we've already encountered, add the option to one of the following variables, and create a function with the same name as the option.
a virtual dependency (such as
net
)"Changing runlevel behavior" section
"Who might benefit" section
For instance, a second "default" runlevel can be created, with other init scripts assigned to it. At boot time, the user can select what "default" runlevel to use.
(Not using default here, which is above used to refer to the default runlevel.)
"Using softlevel" section
the appropriate services, functionality that is called hotplugging.
- Thanks! Added in Special:Diff/1304811/1316757. I (or someone) can definitely work on adding a reference to Shell/Scripting at some point.
- --csfore (talk) 17:47, 19 October 2024 (UTC)