I am curious if anyone is running /bin/bash (or other shell) as PID1 on their systems.

That is usually kept for emergency situations.

I have an old eee pc running SliTaz that uses busybox as PID1 -- does that count?

In a similar vein:
https://bbs.archlinux.org/viewtopic....78903#p1378903

Just something I've been messing with. Managed to get a system up and running into X using /bin/dash as PID1.

/bin/bash as init/PID1 is usually reserved as a recovery/emergency mode, because after you get bash going, you then need to manually mount drives in read/write mode, enable swap, load device drivers, and such all manually. It gives you complete control of the system, but you have to know what all to do.

To be honest, if you know how to script things, you technically could load everything from a shell script and then have it parse out as needed, other scripts to handle things.

Stuff like this is slowly becoming a lost art.

I used to make a live cd based on Linux From Scratch back about 8 years now that just used busybox. Never thought to try to use /bin/bash as PID 1. I am sure it slims down a system even more than I previously thought.

Or you can use a bash script to initialize the system and execute to bash shell at the end.

I'm just testing a simple shell script at the moment. It basically loads the important stuff, then starts a tty login. Whether or not I use it on my main system, give me a chance to improve my shell scripting, and learn more of the basics of Linux.

Busybox works great as a DIY init.

Hey brebs!

See the link in my post (#3), it may look familiar

I-F you are running the system in an extremely-minimalized "single-user mode," for last-ditch recovery purposes, then it conceivably m-i-g-h-t make sense to run "bash" as process #1. (i.e. "because the system is not running in multi-user mode, and it never will.")

But, otherwise: "bash is simply not capable of fulfilling the unique technical requirements that Linux/Unix has for its "process #1." The 'init' executable, on the other hand, is specifically engineered to fill that role. (As is "systemd.")

One of the most-basic requirements of "process #1" is that it is "the Grim Reaper of last resort." If any process finds itself an orphan, it gets killed and automagically parented to "process #1," whose sole responsibility is to reap its moldering remains. "bash" knows nothing of this. The "init" process is also special in the sense that, if it dies, the entire system will kernel-panic. ("Tried to kill 'init!'") "bash," once again, knows nothing of this, and cannot fulfill the technical requirements of this role.

What would be the difference in using busybox vs a shell with coreutils? Also, is the scripts what were linked, I see busybox mentioned, but not specifically called.

Busybox becomes the ultra-special *PID 1* by being called by the kernel - the historical default is /sbin/init:

The point about busybox is that it is able to fulfill the simple but crucial role of PID 1.

The point about using busybox rather than coreutils etc. is that busybox is an all-in-one executable, no need to spawn other processes, and is therefore *faster*. Also smaller & simpler (similar to why Debian converted to using DASH in preference to BASH). Also much easier to debug, because you've got a hope of understanding its code (basically the opposite of the leviathan that systemd has grown into).

KISS is a good thing. Busybox as init works beautifully, and I have no craving to change

I didn't even think of linking /sbin/init > /bin/busybox. I had tried init=/bin/busybox, and would get a kernel panic, so I was using init=/bin/dash instead.

Busybox is a rare app that behaves *differently*, based on the filename that it was called as

This is why the symlinks are important.