zlacker

/sbin is for statically linked executables, while /bin is for dynamically linked executables. It has nothing to do with daemons vs non-daemons, nor with things having to run as root.

>>pmoria+(OP)
Go take a look (using ldd) in your /sbin and tell me exactly how many of them are statically linked. On my system, only 170 out of the 838 items in /sbin are statically linked.

>>pmoria+(OP)
Then why is /sbin missing from PATH in Debian? Does that mean that only root can run statically linked binaries?

>>pmoria+(OP)
I can recall any Linux distro or Unix variant setup in the way you describe. In addition, the Filesystem Hierarchy Standard disagrees with you.

https://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html

You may be thinking of the /bin and /usr/bin difference, though.

>>pmoria+(OP)
https://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html

> Utilities used for system administration (and other root-only commands) are stored in /sbin, /usr/sbin, and /usr/local/sbin. /sbin contains binaries essential for booting, restoring, recovering, and/or repairing the system in addition to the binaries in /bin.

>>rascul+86
I believe they're referring to the old SunOS (at least) convention that /sbin was for utilities that could be run during the boot process before /usr was mounted. These tended to need to be statically linked, as the .so libraries were all under /usr. SunOS was how I learned the Unix filesystem layout, but of course that means a lot of my ideas of what "should" be where are outdated at this point.

>>techno+ie
> I believe they're referring to the old SunOS (at least) convention that /sbin was for utilities that could be run during the boot process before /usr was mounted

My memory is hazy but I recall the distinction being / vs /usr not /bin vs /sbin.

>>rascul+4g
The article we're commenting on has that as the justification for /usr/bin and /bin in the second paragraph.

>>codedo+p2
The tools that root needs are more often served by being statically linked than dynamically for the situations where the volume with the shared libraries fails to mount.

Having mnt be statically linked makes it much easier to recover that system.

The ideal of "/sbin for system tooling" isn't so much one of static vs dynamic but rather users accidentally finding system tools that don't work and sending email to the admin saying "mnt gives me a permission denied error" when they have no business running it.

>>techno+ie
Rather, the convention was that /sbin was for static binaries so that the system could still be fixed online if the dynamic linker got hosed. It's not about /usr not being mounted, but /lib/ld-linux.so not functioning correctly. For that reason, glibc still ships (or used to ship) an sln binary (static ln), and Debian still offers sash (stand-alone shell): so you could at least try to restore the dynamic library link farm by hand.

But I have only ever seen historic references to that argument, from back when dynamic linking was scary and unreliable. I certainly have never encountered that situation in almost 25 years of using Linux.

>>pmoria+(OP)

    $ file /sbin/* | grep "dynamically linked" | wc -l
    325

    $ file /sbin/* | grep -i "static" | wc -l
    0

On Ubuntu focal, but Red Hat is similar.

>>pmoria+(OP)
sbin as "static binary" is an ahistoric retcon, like claiming usr means 'universal system resources'. (It means 'user' and was the original /home.)

>>monoca+oF
Pretty sure on both of those /sbin is just a symlink to /usr/sbin. If the static thing was ever true I suppose once you've moved everything in to /usr you wouldn't bother anymore.