Системг обнаружил, что физическое устройство, на которое был по его мнению смонтирован путь, исчезло, и размонтирует его. Я монтирую - он сразу опять размонтирует (пишет в лог). Как это прекратить? Путь разумеется монтируется на уже новое устройство которое есть. В fstab ничего не менялось т.к. UUID у него тот же - он скопирован через dd.
Нужно чтобы демон думал что к нему подключаются из инета, хотя на самом деле к нему подключается другая локальная прога. В этой проге я включаю на сокет опцию O_BINDANY, делаю bind() на внешний поддельный айпи-адрес и затем connect() к адресу демона.
Из tcpdump-ов выяснилось, что TCP SYN идёт правильно через локалхост от моей проги к демону, а вот SYN+ACK ответ отправляется в настоящий интернет через сетевуху, до моей проги не доходит. Как ему объяснить что он тоже должен через локалхост идти? Напрашивается ipfw fwd, но ему же надо айпи+порт куда заворачивать указывать, а он там поддельный и к тому же каждый раз разный.
Вообще я думал что при наличии локального сокета с нужным ip+port+ip+port пакеты должны попадать сразу в него вне зависимости от того, какому интерфейсу это всё принадлежит, но оказывается нет.
Я не удивлюсь, если там в библиотеке фундаментальный дефект на этот счёт, но возможно это просто непонятные маны.
Исходные данные:
1) есть функция int SSL_shutdown(SSL *ssl);
Краткое содержание мана: функция отправляет «close notify alert» и иногда ещё и принимает ответ на него (тоже «close notify alert») от той стороны. Возвращает: -1 если произошла ошибка либо нужно ждать читаемости/записываемости сокета, 0 если «close notify alert» отправлен успешно, но ответный ещё не получен, и 1, если и отправлен и получен.
Касательно возврата 0 там есть три пояснения:
а) если мы планируем закрывать сокет то можно этим и ограничиться и ответ не ждать
б) есть рекомендация вызвать SSL_shutdown() повторно чтобы принять ответ
в) есть рекомендация вызвать SSL_read() повторно чтобы принять ответ - да, в том же мане 4 абзацами ниже предыдущего утверждения, которому оно немного противоречит (подозреваю речь идет про SSL_ERROR_ZERO_RETURN, см. ниже, но это догадка)
2) есть ошибка SSL_ERROR_ZERO_RETURN, в мане к SSL_get_error описанная так: та сторона закрыла соединение для записи, отправив «close notify alert», читать данные больше нельзя (и уточнение что речь не идёт о сокете, а только об ssl-сессии).
Описание очень похоже на описание нуля, возвращённого из recv() для обычных BSD-сокетов, однако в инете я нашёл ряд репортов про получение этой ошибки от SSL_write(), так что кажется её может делать и он. Тут непонятно: ман говорит что нельзя больше читать, а оказывается что и запись тоже блокируется? В SSL/TLS вообще есть такое явление как наполовину закрытый поток, когда одна сторона завершила отправку и уведомила об этом, а потом только принимает ответ?
В мане какие-то мутные намёки на то, как будто оно есть, но не уточнено как с ним обращаться. Например, как известно, TLS иногда шлёт какие-то служебные данные, которые в итоге прозрачно обрабатываются во время вызова SSL_read/SSL_write. Пока соединение полностью открыто, с ними всё просто: узнаём что на уровне сокетов что-то пришло, вызывает SSL_read(), тот уже либо выяснит что это полезные данные и выдаст нам их, либо примет и обработает служебные и скажет что пользовательских пока нет. Если же та сторона сделала shutdown и нам SSL_read возвращает только SSL_ERROR_ZERO_RETURN, то кем читать пришедшие байты? SSL_write не годится, если мы пока что не хотим ничего записывать, а оставлять их в сокете тоже нельзя - они будут постоянно триггерить select() или его аналоги. Убирать сокет из select-а тоже нельзя - тогда мы не узнаем если он вдруг закроется уже на уровне tcp.
Или, может быть, всё проще, и SSL_ERROR_ZERO_RETURN следует считать как «соединение умерло, закрываем всё что осталось», а в мане просто враньё? Смущает фраза из мана SSL_shutdown: «the peer is still allowed to send data after receiving the close_notify event», и рядом ещё ода рекомендация использовать именно SSL_read вместо повторного SSL_shutdown.
Судя по веб-архиву, 22-24 июля 2024 они его сделали. Зашёл посмотреть, первое что подумал - что они просрочили домен и его захватили киберсквоттеры, как с bzip2 случилось. Но походу это не так и сайт настоящий. Точнее, теперь у них 9 (может не все нашёл) сайтов - по отдельному домену 2 уровня на каждый «раздел». Напомнило сайты известного наверно автора rus-os.narod.ru, но у того оно всё 3-го уровня на бесплатном хостинге было в тут вот так.
Или может всё-таки у них что-то случилось, например проект приобрели какие-то эффективные бизнесмены?
Обижаться на то, что я не оценил оформление твоей новости/продукта из неё и сносить за это коммент с причиной «флуд» (но оставлять такой же формально «флуд», на который я отвечал), а затем, по примеру худших представителей лора, искать рандомный мой коммент в поиске чтоб поставить к нему клоуна в ответ - со стороны модератора крайне некрасиво.
Допустим, есть переменная, полностью обычная (просто char a; - для определённости пусть будет однобайтовая). Ещё до начала совместного к ней доступа она инициализируется либо нулём, либо не нулём. Если ноль - то дальше она не меняется. Если не ноль - то дальше в неё могут записываться другие ненулевые значения в произвольные моменты времени. Другой тред читает эту переменную, не утруждая себя межтредовой синхронизацией, но единственное что ему нужно - выяснить ноль в ней или нет. Как мне кажется, никаких проблем это создать не должно ни при каких обстоятельствах. Однако может быть я что-то упустил? И второй вопрос, отдельный: где формально написано что так можно?
Собственно, как многие наверно знают, данная организация совершенно бессовестно пытается продавать скачивание pdf-ок за какие-то неадекватные суммы. При это иногда удаётся найти их же в открытом доступе, иногда нет.
Может быть есть какой-то сайт где принято ими обмениваться? А то странно - как какие-нить ненужные фильмы или крякнутые игры, так они везде на торрентах всегда есть, несмотря на то, что кто-то реально потратил большие бюджеты на их создание, а тут просто посмотреть официальный формат какого-нить файла пытаются брать деньги не пойми за что, и никто это не обходит?
И второй вопрос: по российскому законодательству будет осуждаться выкладывание этих pdf-ок на сайте для безвозмездного скачивания кем угодно?
Старая тема но в ней оказалось много неверной информации так что создаю новую.
В иксах через setxkbmap настроен переключатель en-ru с индикацией через scrolllock. В норме включёный индикатор скроллока означает русскую раскладку. Проблема: если включить русскую раскладку, затем передёрнуть клавиатуру в разъёме - то скролллок выключается (раскладка, естественно, остаётся русской). Если после этого ещё раз нажать хоткей - то раскладка переключается с русской на английскую, а скролллок включается. И он так и остаётся в противоположном нормальному состоянии до тех пор, пока либо его не пофиксить повторным передёргиванием клавы уже на англ раскладке, либо переключить раскладку через гуи-переключатель, который ставит правильный скроллок.
От софта это не зависит. Если запустить startx xterm - поведение такое же.
Это баг в xorg или можно настроить?
Она даже подтверждена уже была, а потом снесли. В комментариях там какая-то чушь, но причём тут сам софт то, удалили бы комменты.
Я даже не ожидал такого, и когда после нажатия «restart firefox» оно вместо закрывания окна краша начало что-то куда-то отправлять пришлось выдернуть патчкорд из разъёма, успело около мегабайта отослать. Шлёт как оказалось курлом, т.е. прибивание гуи-процесса отправку не останавливает, надо ещё курл отдельно прибить. А ещё игнорирует настройки прокси, что впрочем неудивительно. Если галочку снять то в следующий раз она опять оказывается установлена.
В директории крашрепортера есть файл crashreporter.ini
Crash Reporter]
EmailMe=0
IncludeURL=1
SubmitReport=0
{
"submit_report": true,
"include_url": false
}
Например тут: www.linux.org.ru/forum/linux-org-ru/6228389/history
Если включить подсветку различий, то в последних двух правках якобы ничего не менялось кроме заголовка. В предпоследней версии при включении подсветки различий добавляется 21-й пункт, по идее должный быть подсвеченный красным, но не подсвеченный, при этом следующие за ним превращаются из 21-24 в 22-25 (но это видимо из-за нативного поведения списочных html-тегов).
Аналогично, в последней версии новый добавленный 21-й пункт не подсвечен зелёным.
Раскладки настроены так:
setxkbmap us,ru -option "" -option "grp:lctrl_lshift_toggle,grp_led:scroll"
При нажатии ctrl+shift переключается язык и переключается индикатор скролллока. Но если переключать язык не хоткеем а например через гуи - скролллок не переключается. То есть получается например выбранный русский язык, но скролллок выключен. Если после этого переключать опять через ctrl-shift - переключается и то и то, и получается выбран уже англ, но скроллок загорается. Можно ли как-то сделать чтобы скроллок не переключался на просто другое состояние, а переключался на правильное (us - выключен, ru - включён)?
По-моему когда-то давно оно так и работало, но возможно я что-то путаю.
Иногда эта рассинхронизация начинается и тогда, когда я переключаю только хоткеем (собственно, гуи переключалку я использую только для того чтобы вернуть синхронное состояние, а обычно она только индикатор).
Думаю не составит особого труда найти эту логику в исходниках xorg-а и всё выяснить, но вдруг ответ имеется и без них? Поэтому создал тему.
Обновление: выяснилось, что в сессиях, запущеных из консоли через startx, этой проблемы нет - всё нормально синхронизируется. Проблема только в сессии, запущеной из дисплейного менеджера (который гуи форму логина рисует) slim.
Собственно вопрос остаётся - почему так и как это исправить.
Ещё удивительнее: после опытов в других сессиях и в основной стало нормально работать. Интересно когда опять сломается. Ребутать не хочу.
В связи с темой PHP 8.4 — большое обновление языка, напомнившей мне про пхп, решил его кое-где применить и в ходе планирования наткнулся на такую штуку.
Примеры:
<?php
$a = array('a' => 1);
// $X = array(&$a['a']); $X = 1;
$b = $a;
$a['a'] = 2;
var_dump($b);
<?php
$a = array('a' => 1);
$X = array(&$a['a']);// $X = 1;
$b = $a;
$a['a'] = 2;
var_dump($b);
<?php
$a = array('a' => 1);
$X = array(&$a['a']); $X = 1;
$b = $a;
$a['a'] = 2;
var_dump($b);
<?php
$a = array('a' => 1);
$X = array(&$a['a']);
$b = $a;
$a['a'] = 2;
$X = 1;
var_dump($b);
<?php
$a = array('a' => 1);
$X = array(&$a['a']);
$b = $a;
$X = 1;
$a['a'] = 2;
var_dump($b);
Но, тем не менее, я всё же немножко удивился, что они эту штуку не попытались как-то хотя бы спрятать с глаз, всё-таки некрасиво получается.
Впрочем, это, как и остальные его мелкие некрасивости, никак не влияет на тот факт, что пхп всё равно лучший вариант для «накодить несложное по-быстрому».
Добавил sata-диск, ребутнулся, итог:
1) после запуска гуи (lightdm+x11 с автологином) перестаёт работать клавиатура и мышь (alt+prtscr+b работает, ctrl-alt-f1, numlock итд не работают)
2) qemu-system-x86_86 (он в автозапуске) пишет про отсутствующий модуль kvm
Оказалось, что откуда-то запустилось ядро 3.16 вместо 4.19 и от этого всё пошло наперекосяк. В видимом после запуска /boot/ есть только 4.19, и в /boot/grub/grub.cfg тоже прописано 4.19. В биосе в качестве загрузочного на первом месте стоит правильный диск который был и раньше. Добавленный диск виден как sdb. В dmesg правильный диск - «sd 0:0:0:0», неправильный - «sd 1:0:0:0». Но походу grub цепляет с него и конфиг и ядро, хотя дальнейшая загрузка делается с правильного диска. Как так вышло и как исправить?
Этот второй диск - старый системный для текущей ОС, возможно там какие-нить идентификаторы совпадают, но до мая этого года тот диск был подключён вторым и всё работало (но была другая материнка хоть и той же модели - возможно отличается ревизия биоса или какие-то опции в нём). Старые системные разделы просто висели неиспользуемыми (у них тип mdraid, это половина миррора) и ничему не мешали. Никаких обновлений ядер/grub/initramfs за прошедшее время (с отключения диска) не было.
Подозреваю что всё починится если их просто снести и оставить только один нужный, но хочется разобраться в ситуации.
Обновление:
Заметил, что груб с не тем конфигом сам тоже не тот - над меню показывается версия пакета, там deb8. Осталось узнать кто же запускает не тот grub. Или эта строчка в конфиге прописана?
1) grub-install /dev/sda - не помогает (я думал возможно прошитый на sda груб почему-то считает что его домашний раздел на sdb)
2) затирание загрузочного кода в mbr sdb - не помогает (думал может быть биос грузит с sdb несмотря на явное указание грузить с sda)
3) убирание флага активности с sdb1 - не помогает
4) затирание описания раздела sdb1 (то есть этого раздела теперь вообще нет) - помогло, стал грузиться правиьный груб с правильным конфигом итд
Но тему решённой не помечаю, т.к. вопрос никуда не девается: каким образом и кто запускает груб не с того диска. Мастер-бутсектор на старом диске (кроме таблицы разделов) затёрт, то есть грузится точно MBR правильного диска, который в свою очередь вряд ли может по своей инициативе лезть на другой (или может?).
Внутри там двуядерный athlon, но второе ядро не используется, т.к. я не умею его запускать.
Запускается через DOS, но весь сетевой стек, начиная с драйвера сетевух (их там 4 штуки, назывались вроде dlink 520, по факту VIA Rhine II), менеджер памяти, движок кооперативной многозадачности, псевдографический оконный интерфейс и базовые утилиты типа шелла, телнета, сниффера и http-браузера — самописные в виде монолитного бинарника на турбо-паскале + ассемблере, местами 32-битном.
От доса используется загрузчик, и драйвер файловой системы и системный рамдиск куда распаковываются конфиги и скрипты на старте.
Перемещено hobbit из workplaces
Оно опять сломалось.
Сам патч https://firk.cantconnect.ru/yt-dlp/yt-dlp-fix-dzen-20241104.patch
Пропатченая версия yt-dlp если кому лень: https://firk.cantconnect.ru/yt-dlp/yt-dlp-2024.10.22-patched
Как патчить вручную:
Кладём yt-dlp в текущую директорию
7z x yt-dlp # unzip ругается на шебанг, поэтому 7z
patch -p0 < yt-dlp-fix-dzen-20241104.patch
zip -r yt-dlp.patched.zip __main__.py yt_dlp
echo '#!/usr/bin/env python3' > yt-dlp.patched
cat yt-dlp.patched.zip >> yt-dlp.patched
chmod +x yt-dlp.patched
Если кто-то отправит им его в этот баг https://github.com/yt-dlp/yt-dlp/issues/11385 я не против
В ходе патчинга обнаружил неудобство: dzen спамит ссылками на якобы разные форматы, из-за чего список раздувается в несколько раз. Убрал форматы «AudioMute» оттуда (для mpd они вообще полностью дублируют обычные т.к. аудиострим там отдельный и так, для m3u8 - не дублируют, если кому надо можете раскомментить нужную строку в патче там комментарий указан об этом). И ещё он каждый m3u8 формат репортит 4 раза не знаю зачем - как это убрать я не знаю, по факту надо добавить в игнор урлы с GET-параметром redundant в мастер-файле m3u8 (его парсинг за пределами парсинга дзена, я его не трогал).
$ kolourpaint
kf.solid.backends.udisks2: Failed enumerating UDisks2 objects: "org.freedesktop.DBus.Error.ServiceUnknown"
"The name org.freedesktop.UDisks2 was not provided by any .service files"
kf.solid.backends.udisks2: Failed enumerating UDisks2 objects: "org.freedesktop.DBus.Error.ServiceUnknown"
"The name org.freedesktop.UDisks2 was not provided by any .service files"
kf.solid.backends.udisks2: Failed enumerating UDisks2 objects: "org.freedesktop.DBus.Error.ServiceUnknown"
"The name org.freedesktop.UDisks2 was not provided by any .service files"
kf.solid.backends.udisks2: Failed enumerating UDisks2 objects: "org.freedesktop.DBus.Error.ServiceUnknown"
"The name org.freedesktop.UDisks2 was not provided by any .service files"
kf.solid.backends.udisks2: Failed enumerating UDisks2 objects: "org.freedesktop.DBus.Error.ServiceUnknown"
"The name org.freedesktop.UDisks2 was not provided by any .service files"
kf.solid.backends.udisks2: Failed enumerating UDisks2 objects: "org.freedesktop.DBus.Error.ServiceUnknown"
"The name org.freedesktop.UDisks2 was not provided by any .service files"
kf.solid.backends.udisks2: Failed enumerating UDisks2 objects: "org.freedesktop.DBus.Error.ServiceUnknown"
"The name org.freedesktop.UDisks2 was not provided by any .service files"
kf.solid.backends.udisks2: Failed enumerating UDisks2 objects: "org.freedesktop.DBus.Error.ServiceUnknown"
"The name org.freedesktop.UDisks2 was not provided by any .service files"
kf.dbusaddons: Can not find 'kdeinit5' executable at "/home/user1/bin:/home/user1/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games" "/usr/bin, /usr/lib/qt5/bin"
kf.service.services: KServiceTypeTrader: serviceType "ThumbCreator" not found
kf.service.services: KServiceTypeTrader: serviceType "ThumbCreator" not found
kf.service.services: KServiceTypeTrader: serviceType "ThumbCreator" not found
kf.service.services: KServiceTypeTrader: serviceType "ThumbCreator" not found
kf.coreaddons: Error detected in cache, re-generating
kf.service.services: KServiceTypeTrader: serviceType "ThumbCreator" not found
Кстати хотел клоуна в теги засунуть так пишет
Некорректный тег: '🤡'
Поставил на ноут новую память, решил её на всякий случай проверить. Итоги:
memtest86 пишет «file /boot/memtest86.bin not found» в grub-е, хотя такой файл там есть
memtest86+ виснет на самом первом тесте где-то в середине (спустя пару сек после запуска).
Установил юзерспейсный memtester (он локает память чтоб она не уходила в свап и делает тесты на ней, разумеется не по всему адресному пространству), запустил его в 4 потока по 2G+2G+2G+1G + браузер со всяким медиа чтоб занять остальное (памяти всего 8g) - ошибок не показывает, ничего не виснет.
update:
В конфиге grub-а скопипастил всякие insmod и root из memtest86+ в memtest86 - он после этого запустился и тоже повис на первом тесте
Pass 0%
Test 24%
Test #1 [Address test, own address Sequential]
Testing: 4096M-6144M 2048M of 8078M
Pattern: address
Виснет всегда на одном и том же месте.
upd: Это не первый тест а второй, там нумерация с нуля. Первый #0 это «walking ones».
Если сделать skip на test#1 то виснет на #2 если его тоже skip то на #3 на том же «testing 4096-6114».
Сделан из платы ASRock Q1900-ITX и самодельного многоэтажного корпуса.
У платы питание 19V, оно даётся извне ноутбучным БП на верхнюю панель корпуса, где стоят измерители потребляемой мощности каждого этажа и разводка к ним питания.
В первоначальном варианте в качестве хранилища был миррор из двух 2.5" wd black, но они что-то быстро перестали удовлетворительно работать (один вроде вообще сдох) и стал использовать ссд. Изначально на втором этаже была другая система которой я тоже иногда пользовался, и вообще этажей планировалось сильно больше двух (кластер с hardware-изоляцией между разными задачами), и хотел ещё сделать красивую переднюю панель вместо вынесенных на шлейфах кнопок с индикаторами, но...
По факту материнка оказалась не особо хорошей (я не знал что asrock это asus, когда её брал): одна сдохла ещё больше 5 лет назад перестала включаться, у второй потекла батарейка, неудачно расположенная рядом с греющимся разъёмом питания ссд (заметил это в мае этого года, когда я и сделал эту фотку, да забыл выложить), и вот осталась последняя третья плата, изначально бывшая запасной. Хотя та что потекла — включается и работает, но на всякий случай отключил её. На фотке она внизу. И и у как минимум двух экземпляров из трёх есть признаки нестабильной работы при большой нагрузке на память.
В итоге на дальнейшую доработку забил, а то, что осталось, работает как есть в качестве сервера с несколькими qemu для побочных задач.
Это выглядит странно - я случайно ткнул на реакцию, хотел её отменить и мне пишет про лимит - она не отменяется. Ладно, пусть попытку я потратил и возвращать её не надо, но убирать ошибочную реакцию хотя бы в течение минуты после установки по-моему надо давать безо всяких лимитов.
| следующие → |