Handbook Talk:AMD64/Working/Initscripts

From Gentoo Wiki
Jump to:navigation Jump to:search
Note
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

Talk status
This discussion is done.

"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

Talk status
This discussion is done as of 2024-10-19.

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

Proposed changes - Please make edits here until a final revision is agreed upon.

Then, the boot loader instructs the CPU to execute the kernel.
Proposed changes - Please make edits here until a final revision is agreed upon.

The init process makes sure that all filesystems ...
Proposed changes - Please make edits here until a final revision is agreed upon.

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

Proposed changes - Please make edits here until a final revision is agreed upon.

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/.
Proposed changes - Please make edits here until a final revision is agreed upon.

Once all scripts referenced in /etc/runlevels/boot/ have been executed, init will run the scripts linked in /etc/runlevels/default/.
Proposed changes - Please make edits here until a final revision is agreed upon.

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

Proposed changes - Please make edits here until a final revision is agreed upon.

The /etc/inittab file is used by init to determine the actions it needs to take.
Proposed changes - Please make edits here until a final revision is agreed upon.

As described above, init's first action is to mount all file systems.
Proposed changes - Please make edits here until a final revision is agreed upon.

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

Proposed changes - Please make edits here until a final revision is agreed upon.

do exactly what their names imply: initializing the system
Proposed changes - Please make edits here until a final revision is agreed upon.

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.

Proposed changes - Please make edits here until a final revision is agreed upon.

The scripts that the openrc process starts are called init scripts.
Proposed changes - Please make edits here until a final revision is agreed upon.

To get the status of a service (started, stopped, ...), use the status argument:
Proposed changes - Please make edits here until a final revision is agreed upon.

but are not necessary for the correct functioning of the service.

"Updating runlevels" section

"rc-update" section

Proposed changes - Please make edits here until a final revision is agreed upon.

Gentoo's init system uses a dependency tree
Proposed changes - Please make edits here until a final revision is agreed upon.

In earlier instructions, init scripts have already been added to the default runlevel. What default means has been explained earlier in this document.
Proposed changes - Please make edits here until a final revision is agreed upon.

In addition to the runlevel, the rc-update script requires a second argument specifying the appropriate action: add, del, or show.
Proposed changes - Please make edits here until a final revision is agreed upon.

will show all the available init scripts and the runlevels in which they will execute:

"Configuring services" section

"Why additional configuration is needed" section

Proposed changes - Please make edits here until a final revision is agreed upon.

It is therefore not desirable to have users edit init scripts directly, as it would make them more error-prone.
Proposed changes - Please make edits here until a final revision is agreed upon.

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

Proposed changes - Please make edits here until a final revision is agreed upon.

entoo's init scripts are not compatible with the init scripts used by other distributions, unless the other distribution is using OpenRC.

"Dependencies" section

Proposed changes - Please make edits here until a final revision is agreed upon.

There are three dependency-related settings which can influence the start-up or sequencing of init scripts:
Proposed changes - Please make edits here until a final revision is agreed upon.

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).
Proposed changes - Please make edits here until a final revision is agreed upon.

The use setting informs the init system that the script uses functionality offered by the selected script
Proposed changes - Please make edits here until a final revision is agreed upon.

Some 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.
Proposed changes - Please make edits here until a final revision is agreed upon.

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.
Proposed changes - Please make edits here until a final revision is agreed upon.

The need setting indicates a hard dependency: a script that needs another script will not start before the latter script is started successfully.
Proposed changes - Please make edits here until a final revision is agreed upon.

Also, if the needed script is restarted, the script needing it will be restarted as well.
Proposed changes - Please make edits here until a final revision is agreed upon.

The before setting ensures the script is launched before a specified script, if the latter is part of the runlevel.
Proposed changes - Please make edits here until a final revision is agreed upon.

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.
Proposed changes - Please make edits here until a final revision is agreed upon.

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.
Proposed changes - Please make edits here until a final revision is agreed upon.

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:

Proposed changes - Please make edits here until a final revision is agreed upon.

Many of Gentoo's init scripts depend on things that are themselves not init scripts: virtual dependencies.
Proposed changes - Please make edits here until a final revision is agreed upon.

For instance, consider the dependency information in the postfix script:
Proposed changes - Please make edits here until a final revision is agreed upon.

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

Proposed changes - Please make edits here until a final revision is agreed upon.

through the dependency settings use and need, but also through the order settings before and after.
Proposed changes - Please make edits here until a final revision is agreed upon.

As we have described these earlier already, let's take a look at the portmap service as an example of such init script.
Proposed changes - Please make edits here until a final revision is agreed upon.

It's possible to use the * glob to refer to all services in the same runlevel, although this isn't advisable.
Proposed changes - Please make edits here until a final revision is agreed upon.

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

Proposed changes - Please make edits here until a final revision is agreed upon.

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:
Proposed changes - Please make edits here until a final revision is agreed upon.

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.
Proposed changes - Please make edits here until a final revision is agreed upon.

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.
Proposed changes - Please make edits here until a final revision is agreed upon.

(for example, from foo.py to foo)
Proposed changes - Please make edits here until a final revision is agreed upon.

it is necessary to add --name as an option to start-stop-daemon.
Proposed changes - Please make edits here until a final revision is agreed upon.

which changes names to foo
Proposed changes - Please make edits here until a final revision is agreed upon.

start-stop-daemon has an excellent man page
Proposed changes - Please make edits here until a final revision is agreed upon.

Gentoo's init script syntax is based on the POSIX shell ('sh'), so people are free
Proposed changes - Please make edits here until a final revision is agreed upon.

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

Proposed changes - Please make edits here until a final revision is agreed upon.

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.
Proposed changes - Please make edits here until a final revision is agreed upon.

a virtual dependency (such as net)

"Changing runlevel behavior" section

"Who might benefit" section

Proposed changes - Please make edits here until a final revision is agreed upon.

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

Proposed changes - Please make edits here until a final revision is agreed upon.

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)