Это карусельный и грубо неточный метод. Вы знаете расположение файла библиотеки, поэтому вам не нужно использовать эвристику для его соответствия, вы можете искать точный путь.
Есть очень простой способ перечислить процессы, у которых открыт файл:
fuser /lib/x86_64-linux-gnu/libc.so.6
Однако в этом списке есть процессы, у которых открыта текущая версия файла, т.е. процессы, которые используют новую копию библиотеки. Если вы хотите перечислить процессы, у которых есть удаленная копия, вы можете использовать lsof
, но искать точный путь. Ограничьте lsof
файловой системой, содержащей удаленный файл, для выполнения (и, возможно, чтобы избежать блокировки, например, на временно недоступных сетевых файловых системах).
lsof -o / | awk '$4 == "DEL" && $8 == "/lib/x86_64-linux-gnu/libc-2.13.so" {print $2}'
Если обновленный пакет содержит несколько библиотек и вы хотите обнаружить любую из них, перечислите все файлы библиотек из пакета. Вот способ сделать это программно (для пакета Debian настройте в соответствии с вашим дистрибутивом, например, rpm -ql glibc
на Red Hat).
lsof -o / | awk '
BEGIN {
while (("dpkg -L libc6:amd64 | grep \\\\.so\\$" | getline) > 0)
libs[$0] = 1
}
$4 == "DEL" && $8 in libs {print $2}'
Какая разница между SLED и RHEL WorkStation?
Как я понимаю, они в основном связаны с конфигурацией (например, в SuSE есть YaST, в то время как в RHEL есть инструменты system-config-*
).
Какие преимущества перед дистрибутивами, поддерживаемыми сообществом?
Хотя для персонального рабочего стола, работающего в основном с открытым исходным кодом, они не являются актуальными, для бизнес-приложений/корпораций/исследований/науки, где время простоя может стоить больших денег, это имеет значение.
Важным отличием SLED/RHEL -vs- публичных дистрибутивов является то, что SLED/RHEL имеют платную поддержку, которая доступна. Я считаю, что для многих компаний этот факт ОЧЕНЬ важен.