What are the meanings of /usr/sbin, /usr/local/sbin and /usr/local/bin?
So the question is: Why there are so many directories and what are the meanings of /usr/sbin , /usr/local/sbin and /usr/local/bin ?
Many programs are distributed through archives and we have to build them from source code. Usually they have makefile so it’s quite easy. This process involves creating files in usr/local/lib, usr/local/bin. usr/local/whatever without creating specific folders for a given program.
I think it’s not right because if we need to remove the program we have to manually delete every of its files if the program’s creator didn’t take care of it.
Sergey, please use the Markdown syntax for writing posts on Super User. Having HTML in them makes them really hard to read and edit in plain text.
I hate directory filesystems. why doesn’t somebody invent a filesystem where files are just tagged instead ? On top of it, directories don’t make any sense because inodes allow files to be fragmented. A directory should be an allocated part of the hard drive memory space, not some path, mostly like a partition.
Btw. the normal way to deal with the «uninstallability» issues of locally built programs is to actually build local packages for them. This process is, however, very dependent on the Linux distribution. In case applications support that mode of deployment, modern supplements to the established packaging systems like Flatpack or Docker come to mind.
5 Answers 5
1. Directory structure
/bin/ Essential command binaries that need to be available in single user mode; for all users, e.g., cat, ls, cp /sbin/ Essential system binaries, e.g., init, ip, mount. /usr/bin/ Non-essential command binaries (not needed in single user mode); for all users /usr/sbin/ Non-essential system binaries, e.g. daemons for various network-services. /usr/local/ Tertiary hierarchy for local data, specific to this host. Typically has further subdirectories, e.g., bin/, lib/, share/
2. Installation
I use a package manager wherever possible (e.g. yum or apt-get). This is possible for a very large number of applications, in a few cases you may have to add a repository. My second choice would be lower level packages such as RPMs and compiling from source would be my last resort (but some people prefer this)
Some package managers can install from RPMs (e.g. yum install oddity.rpm )
If you are compiling from source, its probably not a huge step to create your own package so that the system installer knows what you’ve done.
Then your problem reduces to e.g. yum remove packagename
The alternative is to keep good documentation about all sysadmin activities undertaken (I keep a journal in a text file anyway)
I still don’t get the difference between usr/sbin, usr/local/bin and usr/local/sbin. usr/local is said to be specific to this host, aren’t usr/sbin, usr/bin also specific to the host? the second question was about those programs which are not in repos — make uninstall doesn’t work always — so I asked how to delete those ones?
@Sergey This is historic. /usr/(s)bin tended to be mounted from a network filesystem. That is why everything that is needed to boot the machine had to be in /(s)bin . For the most part /usr/local is now used for programs that you install outside of the package manager (which you shouldn’t do).
for manually installed programs that you no longer need just do a regular delete ( rm ). /usr/local is for machine specific data as for network booting systems /usr in often a network share. @Let_Me_Be installing programs from outside the package manager is perfectly fine and can often been required.
@Sergey: If you have two computers, installed from the same medium and later manually add some software to just one of them, traditionally this would go in /usr/local as it is local to that machine and not part of the «standard» set of programs provided by the vendor. As others have said, this historical practice isn’t nowadays much followed by package builders — I suppose software in the standard repositories are effectively treated more as vendor-supplied optional software rather than as user-installed local customisation.
Stuff in all the */sbin directories tend to be only useful for system administrators. You can keep them out of your PATH if you’re a normal user.
The different directories don’t make much sense if you have a single unix machine on a single disk, but make more sense if you have a big system and different partitions. Remember that a lot of these habits were made in the 80’s and 90’s when systems were a bit different.
/sbin tends to be very small. These are utilities that you need when you’re really hosed. You’d put this on a minimal root partition with /root and /lib. Things in /sbin used to be all statically linked, since if your /usr partition is hosed, any dynamically linked apps are useless. fsck is here and statically linked. If you have a dependency on /usr, obviously you can’t fsck /usr/. Of course, if root partition is hosed, you’re very screwed. This is why this is such a small partition — lower the odds of a bad disk block by using very few blocks here.
/usr/sbin binaries are general sysadmin tools where you can at least get to single user mode and mount all your volumes. They are allowed to be dynamically linked.
The separate partitions for /sbin (well, /sbin on / partition) and /usr also make more sense when you remember that backup was very expensive in both time and for tape. If they were on separate partitions, you could schedule them differently.
/usr/local can be a network filesystem. So locally written sysadmin tools that can be shared across many machines sometimes go into /usr/local/sbin. Obviously no network fixing utils can go there.
Again, a lot of things made more sense on big machines in a networked environment on managed machines with multiple volumes, less so with one Linux machine on a single root partition.
Еще одно мнение о разнице между bin, sbin, usr/bin, usr/sbin
Недавно я обнаружил вот такую статью: Разница между bin, sbin, usr/bin, usr/sbin. Хотелось бы поделиться своим взглядом на стандарт.
/bin
Содержит команды, которые могут использоваться как системным администратором, так и пользователями, но которые необходимы, когда не смонтированы никакие другие файловые системы (например, в однопользовательском режиме). Он также может содержать команды, которые косвенно используются скриптами.
Там ожидается присутствие таких команд:
cat, chgrp, chmod, chown, cp, date, dd, df, dmesg, echo, false, hostname, kill, ln, login, ls, mkdir, mknod, more, mount, mv, ps, pwd, rm, rmdir, sed, sh, stty, su, sync, true, umount, uname.
Можно сделать симлинки на /usr, но хотя во времена systemd /usr на отдельном устройстве не встречается, его еще можно встретить на встраиваемой системе, светофоре, кофемолке и PDP-11 обслуживающем важный прибор в одной из лабораторий Академии Наук.
/sbin
Утилиты, используемые для системного администрирования (и другие команды только для root), /sbin содержит двоичные файлы, необходимые для загрузки, восстановления, восстановления и/или восстановления системы в дополнение к двоичным файлам в /bin. Программы, выполняемые после того, как /usr монтируется (когда проблем нет), обычно помещаются в /usr/sbin. Локально установленные программы системного администрирования должны быть помещены в /usr/local/sbin.
fastboot, fasthalt, fdisk, fsck, getty, halt, ifconfig, init, mkfs, mkswap, reboot, route, swapon, swapoff, update.
Один из способов защиты системы от шаловливых рук юзеров — это запрет запуска этих утилит кому-попало, установкой атрибута x.
К тому же, замена /bin и /sbin на копии из архива (одинакового для всех однотипных систем) является быстрым способом починки систем без пакетного менеджера.
/usr/bin
Тут всё просто. Однотипные команды, одинаковые для всех серверов/кофемолок компании. И сам /usr может разворачиваться одинаковым для разных ОС (для /bin и /sbin такое как правило не работает), это архитектурно независимые программы. Может содержать линки на интерпретаторы perl или python, которые лежат в /opt или еще где-то в сети.
/usr/sbin
Тоже самое, что /usr/bin, но для использования только админами.
/usr/local/bin и /usr/local/sbin
Одна из важнейших локаций. В отличие от остального, /usr не может быть одинаковой для всей организации. Тут находятся ОС-зависимые, hardware-зависимые и просто программы, которые не на всех устройствах нужны. При синхронизации /usr на машинах, /usr/local требуется исключать.
/home/$USER/bin
Тут случай аналогичный с /usr/local, только лежат программы специфичные для конкретного пользователя. Можно переносить (или синхронизировать) на другую машину при переезде пользователя. То, что нельзя переносить складывается в /home/$USER/.local/bin. Можно использовать local без точки. /home/$USER/sbin по понятным соображениям отсутствует.
Буду рад исправлениям и дополнениям.
Разница между bin, sbin, usr/bin, usr/sbin
Я заметил, что в busybox ссылки разложены по этим четырём директориям.
Есть ли какое-то простое правило, чтобы определить, в какой директории какая из ссылок должна лежать…
К примеру, kill лежит в /bin, а killall — в /usr/bin… Я не вижу никакой логики в таком разделении.
Вы, наверное, знаете, что Кен Томпсон и Дэннис Ритчи создали Unix на PDP-7 в 1969-ом. Так вот, примерно в 1971 они проапгрейдились до PDP-11 с парой дисков RK05 (по 1,5 мегабайта каждый).
Когда операционная система разрослась и перестала помещаться на первом диске (на котором была расположена корневая ФС), они перенесли часть на второй, где располагались домашние директории (поэтому точка монтирования называлась /usr — от слова user). Они продублировали там все необходимые директории ОС (/bin, /sbin, /lib, /tmp . ) и складывали файлы на новый диск, потому что на старом кончилось место. Потом у них появился третий диск, они примонтировали его в директории /home и перенесли туда домашние директории пользователей, чтобы ОС могла занять всё оставшееся место на двух дисках, а это были целых три мегабайта (огого!).
Разумеется, им пришлось ввести правило, что «когда операционная система загружается, она должна быть в состоянии примонтировать второй диск в директорию /usr, поэтому не надо класть программы типа mount на второй диск в /usr, а то получим проблему курицы и яйца». Вот так просто. И это относилось к Unix V6 35 лет назад.
- При загрузке используется initrd или initramfs, который берёт на себя проблемы типа «этот файл нам нужен раньше чем тот». Таким образом, у нас уже есть временная файловая система, которая используется для загрузки всего остального.
- Разделяемые библиотеки (которые были добавлены в Unix ребятами из Berkley) не позволяют вам независимо менять содержимое /lib и /usr/lib. Эти две части должны соответствовать друг другу, иначе они не будут работать. Этого не происходило в 1974-ом, поскольку тогда у них была некоторая независимость из-за статической линковки.
- Дешёвые жёсткие диски преодолели барьер в 100 мегабайт где-то в 1990-ом и примерно в то же время появились программы для изменения размера разделов (partition magic 3.0 вышла в 1997-ом).
Разумеется, за 30 лет из-за такого разделения появлялись и исчезали всякие интересные специфичные для отдельных дистрибутивов правила. Например, «/tmp очищается при перезагрузке, а /usr/tmp — нет». (И в Ubuntu /usr/tmp нет в принципе, а в Gentoo /usr/tmp — это символическая ссылка на /var/tmp, на который теперь распространяется то правило, и он не очищается при перезагрузке. Да, это всё было ещё до tmpfs. А ещё бывает, что корневая ФС доступна только на чтение, и тогда в /usr тоже не надо ничего писать, а надо писать в /var. Или в / в основном нельзя писать, не считая того, что в /etc, которую иногда пытались перенести в /var. )
Бюрократы вроде Linux Foundation (которые поглотили Free Standards Group во время расширения годы назад) с радостью документируют и усложняют эти правила, даже не пытаясь понять, почему они появились. Они не догадываются, что Кен и Дэннис просто перенесли часть ОС в их домашнюю директорию, из-за того, что диск RK05 на PDP-11 был слишком мал.
Я практически уверен, что в busybox просто помещает файлы так же, как это исторически сложилось. Нет никакой реальной причины делать так до сих пор. Лично я просто делаю /bin, /sbin и /lib ссылками на аналогичные директории в /usr. Ведь люди, которые работают со встраиваемым софтом, стараются разбираться и упрощать…