sis

Схемы взаимодействия подсистем Linux и профилирования ПО и просто полезное

sis

Вот и мне приехал «подарок» откуда не ждал

Товарищ rustedowl у себя в ЖЖ недавно писал про неотключаемую функцию modern standby. А тут приехал ко мне рабочий ноутбук Dell Latitude. Накатил на него Fedora и обнаружил, что там нехило высаживается батарея в режиме suspend. Поначалу грешил на Fedora, но как оказалось, Рафик там неуиноват.

После изысканий выяснилось, что сел на ту же мину что и другие. И да, эта фича у меня не отключается вообще на уровне EFI. То есть прописывать grub опцию mem_sleep_default=deep бесполезно. Всё равно команда cat /sys/power/mem_sleep показывает только поддержку s2idle.

Процитирую из жежешечки Совы: «Если вы хотите взять ваш ноутбук, положить его в рюкзак и куда-то пойти, то вы его сначала выключите. А если не выключите, и он сдохнет от перегрева прям у вас в сумке, то это негарантийный случай».

Вот так и живу теперь, короче. Заодно подгорело ещё и у меня до кучи.

This is crosspost from https://techquisitor.dreamwidth.org/332617.html
umnokot

Голодный экспорт в царской России.

Какое-то время назад, у меня в комментах был человек, утверждавший, что проблемы снабжения хлебом в СССР были временными трудностями, да ещё и на фоне Гражданской войны и нескольких лет после. Почему это не так, не буду пересказывать. Отправлю читать, например, книгу Осокиной «За фасадом сталинского изобилия». Как по тексту книги, так и в конце приводится обширнейшая библиография источников и описей. Рецензию легко найти по тегу «книги».

Но тут другой момент. Часто люди ссылаются на официальную историографию СССР о том, что мол-де в царской России всё было ещё хуже, а большевики исправили ситуацию к лучшему. Причём ссылаются на это как на аксиому.

Действительно, долгое время такая точка зрения действительно бытовала, но в связи с вводом очень большого количества статистического материала в научный оборот, это утверждение уже очень давно рассыпалось в прах. К сожалению, людей это не останавливает и эта история повторяется снова и снова.

Но я к чему? На канале «Постнаука», внезапно, вышло видео как раз посвященное проблеме экспорта хлеба в царской России. Разбирается кратко достаточно, но даётся множество опорных точек, по которым можно собирать информацию.

Кому интересно, смотрите.

This is crosspost from https://techquisitor.dreamwidth.org/332407.html
sis

Fedora 34: первая неделя использования

«О чём думаешь, Евгений?» вопрошает меня Фейсбук. А о том, что давно у меня не было рубрики «карма тестировщика».

Дано: Fedora 34 Workstation. Ванильная. Со всеми патчами и апдейтами из штатных репозиториев. Никаких RPM Fusion и иже с ними.

  • Уже несколько раз крашился Gnome, причём непонятно из-за чего. Но отчёты в ABRT сгенерились. Надо бы восстановить пароль от багзиллы Fedora и отправить логи туда.

  • Постоянно пропадает звук на полсекунды или меньше в Firefox, при подключении внешней звуковой карты. Судя по всему, проблема в PipeWire. Решения пока не нашёл. Если проигрывать со штатной звуковой карты в ноутбуке — всё ОК.

  • При обратном включении иконок на работе столе Gnome, иконки постоянно меняют своё местоположение при включении или выключении дока. Причём заметил, что съезжают всегда одинаково. В качестве обходного решения расположил иконки как мне надо при включенном доке и использовать Gnome Shell только с доком. Стыд, да и только.

  • Очень редко, но теряются настройки внешних мониторов. Какую-то последовательность пока не уловил. Но случается правда редко и фикс занимает несколько секунд. Переживу. Туда же — меняются местами primary и secondary мониторы.

  • Нихера не запоминаются настройки размера окон в Gnome Terminal.

  • До сих пор надо в Gnome Terminal надо отключать Menu acceleration, чтобы заработала клавиша F10. Да, я использую Midnight Commander. Порицайте меня.

  • Всё так же надо использовать Gnome Tweaks, чтобы добавить кнопки сворачивания, разворачивания и максимизации-минимизации окон.

  • По хрен знает какой причине у меня не работали сначала Gnome Extensions. Решение: обнулить профиль пользователя и сбросить профили Firefox/Chrome, затем заново переустановить аддоны для браузеров.

  • Если воткнуть док до загрузки ноутбука, то система будет загружаться раза в три медленнее, чем без него.

Может мне и правда в QA идти было надо?

This is crosspost from https://techquisitor.dreamwidth.org/332035.html
sis

Сертификат R3 для Let's Encrypt

Думаю ни для кого не новость, что сертификаты от R3 которым подписаны цепочки от тех же Let's Encrypt протухли ещё 30 сентября. Но те, кто выписывают сертификаты с помощью certbot, обнаружили, что сертификат обновляется, но по-прежнему подсовывается старая цепочка доверия.

Чтобы заставить certbot выдавать сертификаты используя цепочку ISRG X1, надо скормить оному команду certbot renew --preferred-chain "ISRG Root X1". Затем просто перезапустить сервер. В дальнейшем будет сгенерирован конфиг для сертификата, где по умолчанию будет прописано необходимая предпочтительная цепочка доверия.


This is crosspost from https://techquisitor.dreamwidth.org/331789.html
sis

HP LaserJet 1018 OS 11 BigSur

Как-то после обновления с Catalina на BigSur у меня отвалилось два устройства. Точнее как отвалились. Мой внешний ЦАП работал, но очень эпизодически глючил. А вот принтер HP LaserJet 1018 вовсе перестал работать.

К счастью, с ЦАП проблема довольно быстро решилась выпуском обновления драйверов для BigSur, то с принтером оказалась полная засада. Чего только не перепробовал. И переустановка драйверов заново с полной зачисткой всех хвостов, установка драйверов с помощью Pacifist.В итоге уже почти смирился с тем, что придётся менять надёжный как булыжник принтер на что-то иное, как внезапно натыкаюсь на статью, а там вижу интересное:

The information coming from a HP support agent conveys that following steps may help those facing the issue on their HP printers after after Big Sur update:
Make sure the cable is directly connected between the Mac and the printer.
The use of a USB hub is not recommended. Also, make sure the cable is connected to a USB 2.0 port on your Mac.

А у меня как раз валялся обычный переходник с USB на USB-C. Воткнул... заработало. О - очевидность. Особенно на фоне того, что раньше через хаб всё прекрасно работало. Я и как-то не подумал, что могло что-то тут измениться.

В общем, покупка принтера отменилась. Живём дальше.

This is crosspost from https://techquisitor.dreamwidth.org/331624.html
sis

И про клиент Cisco AnyConnect в очередной раз

VPN клиент от Cisco, конечно, та ещё притча по языцех. Компания, специализирующаяся на сетевых решениях всё ещё не умеет в клиенты для сетевых, собственно, решений. Даже в Linux с помощью Network Manager это реализовано намного более прямо.

В этот раз обнаружил очередное прекрасное. При установке клиента приезжает до кучи Cisco AnyConnect Socket Filter. Всё бы ничего, он и раньше был, но под OS 11 BigSur с ним всплыла проблема. Socket Filter появляется в Network Preferences. И именно под BigSur он наглухо фильтрует доступ к куче всего, по одному ему известному способу. У меня стало медленно работать вообще всё, что связано с сетью. Браузеры, утилиты вроде ping, вообще всё. В итоге просто грохнул в сетях всё связанное с Socker Filter и позапрещал доступ к Kernel Extension который пытается врубиться при доступе к сети. Внезапно всё заработало так же шустро как раньше. В итоге вопрос — ну нахера так, а?


This is crosspost from https://techquisitor.dreamwidth.org/331399.html
sis

Импортозамещение, например

Привезли тут сервер Aquarius, набитый дисками. По идее, должны поставлять нам такие в качестве хранилок. Велели посмотреть, как он будет дружить с нашим прикладом и операционной системой. Стандартная задача, в общем-то.

Первое, что бросилось в глаза, что IPMI явно стырен у более-менее свежих серверов Huawei, даже окошки консольного ровно те же самые и тормоза точно те же самые. Но дальше меня ждало ещё большее удивление, когда я обнаружил это:

importosamaschenie.jpg

Да-да, в реальности это сервер ASRock со стыренным IPMI Huawei и перелицованный как Aquarius. Вот только сертификатики поменять забыли. Такое вот импортозамещение. Запомните, ASRock иностранная компания и в реестре импортозамещённой продукции быть не должна. А Aquarius это «отечественная разработка». Смотрите, не перепутайте.

This is crosspost from https://techquisitor.dreamwidth.org/331013.html
sis

А теперь давайте поговорим за RabbitMQ

.. и его проблемы.

Снова решил пописать про работу. На сей раз, проблема возника с RabbitMQ.

Имеется кролик с неработающими очередями. При этом всё поднято, но если заглянуть в логи, то можно увидеть в первую очередь нечто такое:

2021-06-09 10:02:38.030 [error] <0.19004.32> Error on AMQP connection <0.19004.32> (192.168.0.1:42538 -> 192.168.0.3:5672, vhost: 'none', user: 'updater', state: opening), channel 0:
{handshake_error,opening,
{amqp_error,internal_error,
"access to vhost '/' refused for user 'XXX': vhost '/' is down",
'connection.open'}}
2021-06-09 10:02:38.030 [info] <0.19004.32> closing AMQP connection <0.19004.32> (192.168.0.1:42538 -> 192.168.0.3:5672, vhost: 'none', user: 'updat
er')
2021-06-09 10:02:38.031 [info] <0.19001.32> accepting AMQP connection <0.19001.32> (192.168.0.2:14580 -> 192.168.0.3:5672)
2021-06-09 10:02:38.032 [info] <0.19020.32> accepting AMQP connection <0.19020.32> (192.168.0.1:42540 -> 192.168.0.3:5672)
2021-06-09 10:02:38.033 [error] <0.19001.32> Error on AMQP connection <0.19001.32> (192.168.0.2:14580 -> 192.168.0.3:5672, vhost: 'none', user: 'smsc', state: opening), channel 0:
{handshake_error,opening,
{amqp_error,internal_error,
"access to vhost '/' refused for user 'YYY': vhost '/' is down",
'connection.open'}}
2021-06-09 10:02:38.034 [info] <0.19001.32> closing AMQP connection <0.19001.32> (192.168.0.2:14580 -> 192.168.0.3:5672, vhost: 'none', user: 'smsc')
2021-06-09 10:02:38.035 [error] <0.19020.32> Error on AMQP connection <0.19020.32> (192.168.0.1:42540 -> 192.168.0.3:5672, vhost: 'none', user: 'updater', state: opening), channel 0:
{handshake_error,opening,
{amqp_error,internal_error,
"access to vhost '/' refused for user 'XXX': vhost '/' is down",
'connection.open'}}



Если же зайти в админку кролика, то мы видим сообщение вида:

Virtual host / experienced an error on node rabbit@somehost and may be inaccessible

После раскуривания некоторого количества логов, выяснилось, что проблема в Mnesia. По какой-то причине корраптятся сообщения в msg_stores. Если повнимательнее поискать, то можно заметить такое:


CRASH REPORT Process
<0.430.0> with 0 neighbours crashed with reason: no match of right hand value {error,{not_a_dets_file,”/var/lib/rabbitmq/mnesia/rabbit@hostname_1/msg_stores/vhosts/628WB79CIFDYO9LJI6DKMI09L/recovery.d ets”}} in rabbit_recovery_terms:open_table/1 line 197



Дальше останавливаем корлика, затем идём по указанному пути и грохаем целиком /var/lib/rabbitmq/mnesia/rabbit@hostname_1/msg_stores/vhosts/628WB79CIFDYO9LJI6DKMI09L/. После этого запускаем демона заново. Всё должно запуститься без проблем.

Некоторые люди зачем-то удаляют mnesia целиком, но если у вас, как и у меня, тонны очередей, эксчейнджей и пользователей, то потом это порой будет проблематично восстаналивать даже при наличии любой системы управления конфигурациями.

This is crosspost from https://techquisitor.dreamwidth.org/330773.htm
sis

Давно я что-то про работу не писал...

...а теперь представился случай. Расскажу-ка я про занятный случай связанный Varnish.

Итак, есть энное количество кешей, ранее работавших на Varnish 3. Работало всё хорошо, но третья ветка давно очень устарела и более не поддерживается. Так что мы смигрировали на ветку 6.0.x, которая является LTS релизом. Пришлось правда переписать кастомные модули для него, но это отдельная история.

Всё б ничего, но после апгрейда мы заметили в мониторинге такую вещь, что Varnish стал постоянно перезапускаться. Расследование показало, что умирал порождаемый варнишем процесс.
Хочу заметить, что у нас для кастомных сервисов используется runit. Простой как палка, но своё дело делает (systemd-хейтеры и любители поотлаживать bash — вам сюда!). Так вот в процессе дебага мы отловили такую хрень, что SIGTERM посылает сам runit. Что за ерунда? С третьим варнишем таких проблем не было, исправно работал годами.

Тем не менее, в strace видно следующую картину:

1622625209.201334 --- SIGTERM {si_signo=SIGTERM, si_code=SI_USER, si_pid=4431, si_uid=0} ---
1622625209.202221 --- SIGCONT {si_signo=SIGCONT, si_code=SI_USER, si_pid=4431, si_uid=0} ---
1622625209.203109 rt_sigreturn({mask=[]}) = 0 <0.065258>
1622625209.333354 write(2, "Error: Manager got SIGTERM\n", 27) = 27 <0.000865>
1622625209.590396 getpid()              = 22267 <0.001420>
1622625209.592812 sendto(7, "<131>Jun  2 09:13:29 varnishd[22"..., 57, MSG_NOSIGNAL, NULL, 0) = 57 <0.000927>
1622625209.718907 write(2, "Debug: Stopping Child\n", 22) = 22 <0.157719>
1622625209.877579 getpid()              = 22267 <0.000890>
1622625209.879363 sendto(7, "<135>Jun  2 09:13:29 varnishd[22"..., 52, MSG_NOSIGNAL, NULL, 0) = 52 <0.000916>


После некоторого времени дебага, обнаружили странную вещь. У нас на машинах крутится два инстанса варниша с разными vcl и настройками. Один runit-сервис так и называется varnish, а второй несколько иначе. И вот второй, что интересно, работает как надо.
Нас взяло любопытство и мы взяли и запихвли во второй инстанс настройки от первого. Что интересно, всё заработало.
Дальше мы в порядке бреда просто переименовали runit varnish в что-то другое и... всё заработало.

Проблема решена, но вообще интересно, что её породило. Пока в гипотезе у нас значится, что сам varnish вызывает что-то с точно таким же именем и ранит принимает это за лишний форк или ещё что-то и естественно его прибивает. Дальше вы уже знаете.

Так и живём.

This is crosspost from https://techquisitor.dreamwidth.org/330561.html