Есть грань, за которой уже нельзя делать вид, что ничего важнее срачика gnome vs kde в жизни нет. Всё равно делать это убедительно уже не получается. Предлагаю администрации обозначить свою позицию и попросить поддерживающих сторону $X на выход. Неважно какую - хуже всё равно не будет. Потому что сидеть и спокойно общаться с людоедами и сторонниками людоедов - это не для нормальных людей. А в итоге тут и останутся только любители такого общения. А, maxcom?

Попрошу димеза с пинкбайтом умерить административный восторг, пусть макском тему снесёт. Буду считать это ответом.

Две машинки с Almalinux 8. На одной стал ловить Too many open files и обнаружил что там

# cat /proc/sys/fs/file-max
100000

Тогда как на другой рядом - 26004780. Откуда эти 26004780 взялись, это явно не человеком придуманное число, в sysctl.conf его нет. И почему эта магия не произошла на первой?

Понадобилось тут захостить на одном сервере под сотню виртуалок. Предсказуемо оказалось, что при расположении имиджей на одном диске старт виртуалок ставит всё колом, поэтому есть идея разместить имиджи на рамдиске. Но виртуалок много, а памяти не очень, поэтому напрашивается фс с дедупликацией - имиджи во многом одинаковые. Я подумал, что наконец-то у меня появился повод использовать btrfs, но оказалось слишком поздно - бтрфс из RH8 уже выкинули. Зато запилили какой-то Virtual Data Optimizer. Попробовал его - вроде работает и даже дедуплицирует.

# vdostats /dev/mapper/vdo1
Device               1K-blocks      Used Available Use% Space saving%
/dev/mapper/vdo1     335544320  11420548 324123772   3%           96%

Вопросы:

• Насколько это вообще здоровая идея?
• Работал ли кто с этим VDO, какие там подводные камни? Как оно по скорости и аппетиту к процессору?
• Во что этот vdo лучше форматировать? vfat?
• Почему тег red hat 9 есть, а red hat 8 нету?

Есть Centos 7 с кучей всего ненужного. Есть ли способ быстро зарезать его до состояния Minimal Install?

Поймут ли американцы правильно термин anal probe и если нет - то есть ли эквивалент? Хочу обсудить с начальством поведение встроенного копроративного софта, но ощущаю недостаток словарного запаса.

У меня к ноутбуку есть две одинаковые зарядки, в одной из которых сгорел контур на 110 вольт. Собираюсь ехать туда, где 110, как бы мне понять какую из них брать?

Советам от гентушников намотать трансформатор буду особенно рад.

Отвалился лидер CentOS

Никого не трогаем, обсуждаем новость о письме лидера CentOS, точности его перевода и уместности в нём термина «замутить», как вдруг приходит альфа и начинает наводить порядок расстрелами. Никогда такого не было и вот опять…

Требуется Системный администратор

leave, друже, расскажи, каких пор в Job уточнение служебных обязанностей - оффтопик, а обсуждение уровня оплаты и чести работать в лефкобанке - нет? Я там единственный, кто задал вопрос непосредственно по вакансии.

Вирутализация: когда не рекомендуюется использовать контейнеры, а рекомендуют VM

Альфа, бодро удаляющая с -7 оффтопик и то, что ей кажется оффтопиком, внезапно вспоминает как менять умолчания когда речь идёт о социально близких: сверхуместные откровения хоббита про травлю™ она удаляет с (0). Мне почему-то казалось, что звание модератора должно накладывать дополнительную ответственность за адекватность публикуемого, но, похоже, что тут тот случай когда все животные равны, но некоторые равнее других. Так-то очень знакомое явление и радует, что ЛОР идёт в ногу со временем. Непонятно только недовольство того же хоббита использованием на форуме лагерной терминологии. Какое комьюнити строим - такая и терминология, разве не так?

О где же ты, инженер тех поддержки в сеть доставки контента?

В этом треде я единственный вместо того, чтобы кричать «мало» (что запрещено правилами) предложил кандидатуру на вакансию. И именно моё сообщение было удалено. leave, поясни ход своих мыслей.

Есть несколько докер-контейнеров, а тут понадобился подман. Можно их одновременно запускать?

У меня в /etc/cron.weekly есть скрипт очистки старых билдов

find /storage/builds -type d -links 2 -mtime +365 | xargs rm -rf

Билды там лежат лежат разные, с разной структурой каталогов, поэтому я ищу последний каталог в дереве чтобы не удалить лишнего. -links 2 это магия, выдающая как раз последние каталоги в дереве.

Внезапно я обнаружил, что кто-то меняет mtime этим самым последним каталогам и тем самым не даёт их удалять. Причем этот кто-то судя по всему и есть этот самый скрипт.

Cтруктура примерно следующая

storage
 └─builds
    └─someproject      
       └─100500             Sep 24  2019
          └─client          Sep 29  2020
          │  └─client.rpm   Sep 24  2019
          └─server          Sep 29  2020
             └─server.rpm   Sep 24  2019

Билд случился больше года назад, а потом кто-то изменил время модификации каталогам client и server. Причём время изменено только у каталогов попадающих в выдачу find и сделано это в течении недели после того как им исполнился год. Поэтому главный подозреваемый - сам запускающийся раз в неделю скрипт очистки, который почему-то вместо удаления обновил время модификации. C -ctime ситуация та же. Случай не единичный, таких довольно много.

Как и почему такое может произойти? У меня только версия бага в файловой системе.

https://www.linux.org.ru/forum/talks/16339852

maxcom, тут у кое-кого крыша протекла окончательно, принимайте меры.

После ребута пропал созданный несколько месяцев назад raid6 /dev/md120. Ни в mdadm.conf, ни в /proc/mdstat его следов нет.
Я вроде бы нашёл диски из которых он был собран

# blkid | grep 120
/dev/sdu: UUID="c292c4cf-0d39-260e-b3ef-487d4e81f8c4" UUID_SUB="d6029e5d-9c07-ee30-189b-8eb8ee96b0d3" LABEL="host01:120" TYPE="linux_raid_member"
/dev/sdaa: UUID="c292c4cf-0d39-260e-b3ef-487d4e81f8c4" UUID_SUB="edee5655-d51f-052b-892f-9b9563321d22" LABEL="host01:120" TYPE="linux_raid_member"
/dev/sdk: UUID="c292c4cf-0d39-260e-b3ef-487d4e81f8c4" UUID_SUB="083bb034-9b5b-f099-7628-2281fc93c385" LABEL="host01:120" TYPE="linux_raid_member"
/dev/sdw: UUID="c292c4cf-0d39-260e-b3ef-487d4e81f8c4" UUID_SUB="458004ec-5dd8-2b81-e2a7-db8628a6843e" LABEL="host01:120" TYPE="linux_raid_member"
/dev/sdr: UUID="c292c4cf-0d39-260e-b3ef-487d4e81f8c4" UUID_SUB="ea79abe3-ab9a-b85d-c35a-0484187e3013" LABEL="host01:120" TYPE="linux_raid_member"

Сервер ребутался для обновления ядра, массива нет ни с новым ядром, но со старым.

Вопросы:

1. Какие шансы собрать его обратно с mdadm --create? Важен ли порядок перечисления дисков?
2. Почему он мог пропасть и что надо предпринять чтобы проблема не повторилась?

Centos 7.

Ну что, почалося? BrВИМ!

Категорически не согласен с трактовкой сообщения

Б-же, какой прекрасный олигофрен. Просто жемчужина в коллекции модерации.

как оскорбления. По-моему, здесь совершенно очевидно восхищение.

Сервера в колорадо, всегда было несколько MB/s, а теперь

Downloading Packages:
(1/8): grub2-tools-minimal-2.02-90.el8.x86_64.rpm                         189 kB/s | 204 kB     00:01
(2/8): grubby-8.40-41.el8.x86_64.rpm                                      317 kB/s |  49 kB     00:00
(3/8): initscripts-10.00.9-1.el8.x86_64.rpm                               444 kB/s | 338 kB     00:00
(4/8): grub2-common-2.02-90.el8.noarch.rpm                                 95 kB/s | 884 kB     00:09
(5/8): os-prober-1.74-6.el8.x86_64.rpm                                    111 kB/s |  51 kB     00:00
(6/8): which-2.21-12.el8.x86_64.rpm                                       160 kB/s |  49 kB     00:00
(7/8): grub2-tools-2.02-90.el8.x86_64.rpm                                 179 kB/s | 2.0 MB     00:11
(8/8): linux-firmware-20200619-10 24% [========                         ]  63 kB/s |  26 MB     21:34 ETA

alpha, это часть кампании по популяризации Centos Stream, исключительно ради удобства пользователей?

Можно ли собрать kernel-debug c gcov? В спеке ядра есть кусок, назначение которого я не вполне понимаю

# turn off debug kernel and kabichk for gcov builds
%if %{with_gcov}
%define with_debug 0
%define with_kabichk 0
%define with_kabidupchk 0
%define with_kabidwchk 0
%define with_kabidw_base 0
%define with_kernel_abi_whitelists 0
%endif

Почему при сборке gcov дебаг отключают? Ме бы в идеале стандартное ядро - без gcov, а дебажное - с ним.

Есть старый серверок с файлопомойкой. Сейчас там стоят два диска по 4TB, хочу их поменять на 8 или 10. Есть ли вероятность, что контроллер из ~2012 года с ними работать откажется?

lshw

SATA controller: Intel Corporation 6 Series/C200 Series Chipset Family 6 port Desktop SATA AH

dmidecode

Base Board Information
	Manufacturer: ASUSTeK COMPUTER INC.
	Product Name: P8H61-MX R2.0
	Version: Rev X.0x

Довольно давно уже бьюсь с такой проблемой. Есть 8 серверов, на каждом хостится по 40 виртуалок. Везде Centos 7. Иногда эти виртуалки стартуют одновременно и начинают в себя устанавливать пакеты - драйвера фс и собранное под них ядро. При этом иногда одна-две виртуалки внезапно не осиливают установку, которая валится с якобы ошибками зависимостей, примерно так

Error: Package: kmod-lustre-2.12.4.2_205.el7.x86_64 (/kmod-lustre-2.12.4.2_205_3.10.0_957.1.3.x4.4.40.x86_64)
           Requires: ksym(ib_query_port) = 0xc9ab4f08
Error: Package: kmod-lustre-2.12.4.2_205.el7.x86_64 (/kmod-lustre-2.12.4.2_205_3.10.0_957.1.3.x4.4.40.x86_64)
           Requires: ksym(rdma_bind_addr) = 0x19ea6b1f
Error: Package: kmod-lustre-2.12.4.2_205.el7.x86_64 (/kmod-lustre-2.12.4.2_205_3.10.0_957.1.3.x4.4.40.x86_64)
           Requires: ksym(ib_register_event_handler) = 0x749f0a70

Выглядит как попытка поставить модули под чужое ядро, но ядро гарантированно правильное. Другие точно такие же виртуалки ставятся успешно и если потом зайти на проблемную и сделать yum install руками - всё ставится без проблем.

Вероятность падения - около 0.5%. Может и меньше. Воспроизвести проблему при одиночном запуске не получается - то ли мало пытался, то ли проблема свойственна массовым одновременным запускам. Виртуалки (kvm) живут на отдельных ssd, репозитории все локальные, памяти на хостах полно.

У меня две версии, обе дурацкие - то ли это баг yum/rpm и я его ловлю просто по закону больших чисел, то ли где-то есть узкое место, которое проявляется таким странным образом. Но как например высокий i/o на хосте или сетевые проблемы, или затыки на стороне локального зеркала с репозиториями могут ломать именно разрешение зависимостей?

Ставим два пакета, один из которых не существует. Сперва руками:

fre0104:~ # zypper in bc foo
Loading repository data...
Reading installed packages...
'foo' not found in package names. Trying capabilities.
No provider of 'foo' found.
Resolving package dependencies...

The following NEW package is going to be installed:
  bc

1 new package to install.
Overall download size: 126.6 KiB. Already cached: 0 B. After the operation, additional 273.5 KiB will be used.
Continue? [y/n/...? shows all options] (y):

Зиппер ругнулся на отсутствующий пакет и поставил имеющийся, ок.

Теперь то же самое в пакетной установке, ожидаем такое же поведение.

fre0104:~ # zypper in -y bc foo
Loading repository data...
Reading installed packages...
'foo' not found in package names. Trying capabilities.
No provider of 'foo' found.

Хертам, ничего не поставилось.

Итого два вопроса. Первый риторический - кх пакетный менеджер ставит пакеты по-разному в ручном и пакетном режимах? Второй практический - как мне поставить пакет? Ничего похожего на –skip-broken из dnf я тут не вижу.