Talk:init

This is the talk page for discussing improvements to the Init article.
This is not a forum for general discussion of the article's subject.

Put new text under old text. Click here to start a new topic.
New to Wikipedia? Welcome! Learn to edit; get help.

Article policies

Find sources: Google (books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL

This article was nominated for deletion on 1 March 2006. The result of the discussion was withdrawn (with a trend towards speedy keep).

Removed sentence from intro

I removed this:

Opinions on the relative merits of different schemes can be strongly held, leading both to occasional "flame wars", and also to the development of several alternatives.

seemed like fluff. Hotdogger 01:23, 22 February 2007 (UTC)[reply]

I agree that it didn't belong in the introduction like that, and was unreferenced to boot. A "History" section would be a better place to discuss the actual flame wars, if any, that have occurred. John Vandenberg 01:47, 22 February 2007 (UTC)[reply]

Inaccuracy

That 'about' section reads like it is talking about linux, but doesn't it also apply to the BSDs as well? Mentioning Slackware in its own right seems a bit misleading. --Maru Dubshinki

Well, I was referring to the init systems used on Linux distributions, and I felt it worth mentioning that some, such as slackware and gentoo, use their own init systems. -- Lakerdonald

Fair enough. I've taken the liberty of moving the man init in see also, to external links, and linking to a copy of the man page. --maru 15:51, 18 May 2005 (UTC)[reply]

Sounds good. Looks nice :D --lakerdonald

Linux-centric?

Hey, this'll be my very first Wiki edit. Go me. :) Anyway, this page seems very Linux-centric, even though the init program is present (but behaves differently) on every Unix system. For example, while runlevel 5 may be the default on many Linux distributions, if you switched a Sun/Solaris machine to runlevel 5, it would physically turn itself off. That might come as a bit of a nasty surprise if you're not expecting it. I've added a note to that effect. 207.96.8.128 18:44, 15 February 2006 (UTC)[reply]

Hey, nice job. I further explained that with AIX, and Solaris, the default run levels are different. Now I wonder, should the default runlevels be put into a table for easier readability. This table would also help make the whole article seem less Linux-centric. --Unixguy 19:15, 13 July 2006 (UTC)[reply]

BIOS password

"If the system administrator feels this is insecure, they can always setup a BIOS password." Surely this should be "bootloader password"? --Anon

I think both. BIOSs can be set to require a password before loading the bootloader, and the bootloader can be passworded (I forget whether it blocks loading one of the kernels and partitions, or whether just changing the settings). --maru (talk) contribs 00:57, 26 February 2006 (UTC)[reply]

Well in the context of the Article, the BIOS password is not going to prevent someone from typing custom options into grub, lilo or yaboot. To stop the runlevel 1 loophole you need a bootloader password.

Examples needed

This article is taking shape nicely, but I think it could use a couple of examples.

Example inittab files

   Typical SUSE inittab:
(paste here)

   Typical Solaris inittab:
is:3:initdefault:
sS:s:wait:/sbin/rcS                     >/dev/msglog 2<>/dev/msglog </dev/console
s0:0:wait:/sbin/rc0                     >/dev/msglog 2<>/dev/msglog </dev/console
s1:1:respawn:/sbin/rc1                  >/dev/msglog 2<>/dev/msglog </dev/console
s2:23:wait:/sbin/rc2                    >/dev/msglog 2<>/dev/msglog </dev/console
s3:3:wait:/sbin/rc3                     >/dev/msglog 2<>/dev/msglog </dev/console
s5:5:wait:/sbin/rc5                     >/dev/msglog 2<>/dev/msglog </dev/console
s6:6:wait:/sbin/rc6                     >/dev/msglog 2<>/dev/msglog </dev/console

   Typical AIX inittab:
init:2:initdefault:
l2:2:wait:/etc/rc.d/rc 2
l3:3:wait:/etc/rc.d/rc 3
l4:4:wait:/etc/rc.d/rc 4
l5:5:wait:/etc/rc.d/rc 5
l6:6:wait:/etc/rc.d/rc 6
l7:7:wait:/etc/rc.d/rc 7
l8:8:wait:/etc/rc.d/rc 8
l9:9:wait:/etc/rc.d/rc 9

--Unixguy 00:48, 27 November 2006 (UTC)[reply]

On second thought, adding examples would probably be too technical, and not of much value to an online encyclopedia. --Unixguy 16:03, 3 July 2007 (UTC)[reply]

discussion about merging init and runlevel

I don't think they should be merged; They are so related, but they are not the same. Callmejosh (talk) 07:46, 6 September 2008 (UTC)[reply]

sysvinit?

sysvinit redirects to this article. What does it mean? --Abdull (talk) 16:34, 7 March 2010 (UTC)[reply]

Sysvinit = an Init implementation as originally used in UNIX System V and now followed by most Linux distributions. There's an entire section devoted to it in this article. :) 174.6.87.98 (talk) 04:53, 2 May 2010 (UTC)[reply]

Article would benefit from a list of operating systems that support SysVinit. Believe it or not, for every face-in-his-hand hipster staring at a mobile app, there is a server somewhere that doesn't need to reboot 3 times a day. For servers, stability is more important than bling. 129.219.155.89 (talk) 21:30, 21 August 2015 (UTC)[reply]

SysVinit is only used by non-major distros/flavors/variants now. Major Linux distros have switched to Systemd. Major BSD flavors have switched to rc.d-based (BSD-style) init. Even most "B-list" distros have no-SysVinit init (e.g. Gentoo's OpenRC). --Voidvector (talk) 20:01, 10 February 2018 (UTC)[reply]

(The BSDs never used USG-style init in the first place. so they didn't switch from SysVinit.) Guy Harris (talk) 20:45, 10 February 2018 (UTC)[reply]

Thank you for the clarification. I only know about their adoption of rc.d in the early 00s cause the documentations still mention it. Don't know what they used before then. --Voidvector (talk) 22:08, 10 February 2018 (UTC)[reply]

As the page says:

BSD init was, prior to 4.3BSD, the same as Research UNIX's init;^[1]^[2] in 4.3BSD, it added support for running a windowing system such as X on graphical terminals under the control of /etc/ttys.^[3]^[4] To remove the requirement to edit /etc/rc, BSD variants have long supported a site-specific /etc/rc.local file that is run in a sub-shell near the end of the boot sequence.

so the init program, until 4.3BSD, was the V7 init, and, in 4.3BSD, they extended it to generalize /etc/ttys a bit.

rc.d is the init script mechanism; that can be changed without changing the init program. Guy Harris (talk) 22:58, 10 February 2018 (UTC)[reply]

References

^ init(8) – 4.2BSD System Manager's Manual
^ ttys(5) – 4.2BSD File Formats Manual
^ init(8) – 4.3BSD System Manager's Manual
^ ttys(5) – 4.3BSD File Formats Manual

All processes?

"init is the program on Unix and Unix-like systems that spawns all other processes."
Does init really spawn all processes, so for example a webbrowser that a user requested to start from a GUI is also spawned through init's services? --Abdull (talk) 17:59, 7 March 2010 (UTC)[reply]

You're right. Init doesn't spawn all processes. It spawns its child processes which in return spawn their child processes etc. According to pstree on my system though a webbrowser is really a child of init. It would be correct to say that init is a common ancestor of all processes. 174.6.87.98 (talk) 05:09, 2 May 2010 (UTC)[reply]

It is a child of init because it was re-parented, not because init created your web browser as a child. Justinc (talk) 20:34, 18 August 2012 (UTC)[reply]

External links modified

Hello fellow Wikipedians,

I have just modified 2 external links on Init. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

Y An editor has reviewed this edit and fixed any errors that were found.

If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 01:36, 14 November 2017 (UTC)[reply]

I updated the first one to go to a page at Oracle directly listing the run levels; the second one works.

What program does process 1 on KahelOS run?

The article lists KahelOS as having a replacement for traditional init; it used to say

DEMONS, a modification of the init start process by KahelOS, where daemons are started only when the DE (desktop environment) started

and now says

Daemons, by a modification of the init start process by KahelOS, daemons are started only when the DE (desktop environment) started

The first of those, at least, gave a real name, "DEMONS", to the start process; the second of those changes the spelling and capitalization of the name, and just links to a page about the concept of a "daemon" in computing, which does not make it clearer. The change also added a reference, but all it says is

We have introduced an innovative change to the way daemons are loaded on startup. The traditional approach is to load all the daemons one by one or concurrently at startup before the GDM GUI appears. This approach is much slower because the system is sharing more resources on other daemons instead of just loading the GUI.

Now, KahelOS just loads the GDM GUI making the GUI instantly appear, then loads the rest of the daemons when a user has logged-in.

which doesn't say what program runs as process 1 or, if it's an existing program rather than a new program, how the configuration was changed. Apparently KahelOS is based on Arch Linux; the systemd page claims that Arch Linux uses systemd by default as of October 2012. Systemd is supposed to launch daemons on demand, so its approach isn't to load "all the daemons"; did they just configure it to launch GDM and "loads the rest of the daemons when a user has logged-in" by virtue of the demand for those daemons coming from programs run when the user logs in (possibly requiring other aspects of the system to be changed so that no daemons other than GDM are demanded until a user logs in), or did they replace systemd with some other program? Guy Harris (talk) 00:27, 14 June 2018 (UTC)[reply]

"Replacements" for init? I don't think so.

Those aren't "replacements" for init, those are just additional implementations of an init daemon that don't fall into either the "BSD-style" or "SystemV-style" classifications. They're still init daemons themselves though. They're not "replacements" for init, they are init. The thing they're replacing is SystemV-init, not init itself. Since this article is about init in general, and not SysV-init, the way this is currently phrased is a non-sequitur. Systemd's init process, for example, is an init in its own right, not a "replacement for init".Nlburgin (talk) 20:15, 10 April 2019 (UTC)[reply]

System III init man page doesn't support the claim that S3 introduced a new init style?

A "Failed reference" tag was added to the init(8) man page at TUHS reference for the "AT&T's UNIX System III introduced a new style of system startup configuration" claim.

The man page is, unfortunately, *roff plus -man macros, i.e. source code, rather than formatted, making it harder to read, but it does describe init as having multiple run-levels (called "states" in the S3 man page).

What more is needed to verify the claim? Guy Harris (talk) 17:18, 2 October 2020 (UTC)[reply]

[1] init(8) – 4.2BSD System Manager's Manual

[2] ttys(5) – 4.2BSD File Formats Manual

[3] init(8) – 4.3BSD System Manager's Manual

[4] ttys(5) – 4.3BSD File Formats Manual

[1]

[2]

[3]

[4]