crower

Не смог решить загадку, как условия оной усложнились.

Вот уже который день необходимости в перезагрузке роутера не наблюдается. Пинги ходят надёжно, как в швейцарском банке. :)
Ладно если бы нагрузка упала. Так ведь наоборот, нагрузил железку. Опять запустил magnetico, и тот трудится непрерывно. В прошлый раз, кстати, он наоборот ускорял ухудшение связи, а тут — третьи сутки, как 20/20 пингов возвращаются.
Роутер? Но какой фактор мог повлиять? Разве что похолодало на улице в эти дни. Хотя дома на градуснике что рядом с компом как было 22-24. Хорошо, в следующий раз, если случится такая проблема, попробую поохлаждать. :)
Провайдер? Возможно. Помнится в прошлый раз, когда были проблемы, связанные с хреновой картой, симптомы были похожие. И техник говорил, что мой комп не закончив предыдущую сессию, начинал новую. А провайдерское оборудование, как я понимаю, трафик мне отправляло по обоим сессиям. Фича, что-ли, для лоадшаринга. Но одно дело если бы шнурка было два и это был реальный лоадшаринг, и совсем другое, если отправляемое по первой сессии/шнурку трафик уходит в никуда…

В последнее время с интернетом стала наблюдаться пакость. Поработает некоторое время и начинает подтормаживать.
С пол-года уже, наверно. Пускаю куда-нибудь пинг — пинги теряются.
Перегружаю tplink — всё опять работает как часы. В последнее время просто каждый день перегружаю точку доступа. За сутки тормоза практически не заметны, но на всякий случай, чтобы не запускать симптомы...
То ли провайдер мутит, то ли точка глючит. IP-адрес белый, но динамический и поэтому не знаю может ли какой-нибудь левый трафик душить пропускную способность. Хочется думать на провайдера, но в точке тоже не уверен. По крайней мере временами, когда наблюдаются сильные тормоза, даже до точки добраться бывает проблематично. Через локалку. То есть доступ к его интерфейсу совершенно не должен зависеть от wan. Если только через нагрузку. В самом начале инет включался прямо в мой комп и тогда можно было ещё чего-нибудь наснифить прямо на компе. А сейчас лениво что-то переделывать чисто для эксперимента. Эх, стар я стал. :)

А сегодня обнаружил ещё одно чудо. Перед перезагрузкой по привычке пускаю пинг, и по нему вижу когда точка перезагружается. И тут вдруг обращаю внимание, то до перезагрузки пинг был 68мс, а после — 74мс. Стабильно.
Раньше такого что-то не замечал.

Ох и люблю же я что-нибудь такое сделать, чтобы ничего не делать. :) Ну, почти ничего не делать. Т.с.
воспользоваться былыми результатами повторно. :)

Есть на станции такие файлы, в которые она сохраняет команды между дампами. Зовут их RELCMDHDF, если что.
Новые создаются при каждом дампе, старые становятся не нужными и если специально не пошевелиться, плодятся годами. Место поедают, конечно, но файлы, в общем-то, не большие. Впрочем, технология выделения дискового пространства там чуточку другая, из-за чего места занимать они могут гораздо больше, чем реально используют. Если станция не сильно старая, то проблема нехватки места может так и не наступить. Скорее станцию заменят. :D
Но вот в рамках эксплуатации могут возникать сложности. Работает там конструкция типа кластера и в случае смены активного узла происходит синхронизация дисков. Сначала будет попытка сделать быстрый апдейт - только того, что изменилось после того как узел находился в забытьи. Если не получилось и процесс затягивается, то происходит переключение на длинный апдейт, то есть тупая синхронизация всего подряд, чуть ли не по кластерам. И чем больше всяких файлов валяется, тем вероятнее переключение на длинный процесс. Поэтому много лет назад, приехавший настройщик, тяжело вздохнут собрался поудалять древние файлы. Хорошо что он ленился. Я тогда про них ещё ничего не знал, а как узнал какое богатство собираются удалять, спохватился и уговорил что сам всё сделаю. Товарищ, конечно, обрадовался, потому что автоматизировать рутинные операции не умел, а команд вводить пришлось бы долго. А тут ему предлагают ничего не делать, но работа при этом сделается. В итоге, файлы эти я скачал, и только после этого удалил те что надо. Потом уже сделал нужные настройки, чтобы станция сама эти файлы и через даталинк отправляла, и удаляла старые. В результате получил архив вносившихся в станционные данные изменений. Зачем? Очень удобно отыскивать когда нечто делалось. Например, возникает вопрос: имеется странный маршрут, зачем и почему он сделан таким? Идеальным был бы электронный журнал, хоть и требовал бы дополнительных телодвижений на протоколирование всего подряд. Но начиналась эта работа слишком давно. Есть два шкафа толстых папок распоряжений, по которым эти изменения вносились. Но когда? И вот тут на помощь приходит RELCMDHDF.
Долгое время пользовался простым grep-ом. Потом прикрутил врапер для удобства. Со временем к враперу прикрутил отыскивание по TRLOG1FILE, в который вообще все диалоги со станцией пишу. Собирался было прикрутить скрипт на веб-страницу, но задумался … и решил, что нужно грузить всё это в БД. Глаза боятся, а руки делают.
В результате получил возможность быстрого поиска, удобного доступа (и не только мне), и сводной таблицы.
Сотрудники тоже оценили фичу. Теперь даже непонятно как можно было без этого обходиться. :)

И вот ещё одна станция оказалась под рукой. Всё ходил вокруг неё, облизывался. Вот только в отличие от нашей, доступа к даталинку нет. А без него файлы качать только через IOFAT. А это не совсем файлы. Точнее, чтобы получить оригинал, нужно его обработать. Старые командники оттуда таким образом я уже давно вытащил. Нужное искал обычным грепом, но это же оскорбляет эстетическое чувство. И вот вчера наконец набросал конвертилку из IOFAT в оригинальные файлики. Таблицы в базе, оказывается, я уже давно сделал и даже скрипты готовы. Так что осталось это дело только загрузить. Класс! Теперь только нюансы отлаживаю. То командные строки оказываются чрезмерно длинные. То внутриблочные счётчики команд решил вернуть.

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

С оптимизацией получился облом.

Напомню, что была попытка соптимизировать запрос с select ... where date(field) in (...) group by .... Я в курсе, что конструкция field in (...) сама по себе дорогая, но вполне приемлема, если потеря скорости незначительна, а альтернатива может оказаться ещё дороже.

В моей ситуации потеря скорости оказалась слишком велика, чтобы её игнорировать.

Попробовал другое "дешёвое" решение — внедрить ограничение диапазона, где код where date(field)≥{min_time} and date(field)<{max_time} призван был сократить первоначальную выборку, и уже после этого работал бы var in (...). Нужно было планчик составить, но лениво. А потом оказалось что и var in лишний. С выборкой нужных дат в самом скрипте всё оказалась гораздо быстрее. И поначалу всё заработало как надо. И дело даже не в кешировании. Потому как регулярно, раз в час поступают новые данные.

Эффект был кажущимся из-за того, что на момент тестирования дат было не так много и group by на все эти даты не сильно тормозил. Но наступление события "С", ради которого весь этот сыр-бор, задержалось. И получилось что между первой и последней датой времени прошло настолько много, что быстродействие от экономии на отказе от var in полностью пожралось group by. Долгим и бессмысленным.

Ещё бы:

4 таблицы: 1.2млн, 1.3млн, 26млн и 27млн записей.
интересующие данные (без уточнения по дате) составляют 64К, 10К, 130К и 20К записей.
в таблицах сидит timestamp, а выборку и результат нужно делать от функции по нему. Хоть через substr, хоть по date.

Можно было плюнуть и вернуться к старой схеме, но "мы не привыкли отступать"© и это оскорбляет эстетическое чувство.

Поэтому пришлось делать красиво и по-полной схеме. При обращении к странице, скрипт запрашивает данные, уже сгруппированные по дате и лежащие в специальной дочерней таблице. Если на определённую дату данных нет, то запрашиваются данные в родительской таблице. Если они оказываются полными за указанную дату (24 часа, 1440 минут или 86400 минут), то они вставляются в дочернюю таблицу и в следующий раз будут извлекаться оттуда. Считать их заново будет не нужно. Операция сия была необходима для одного определённого объекта, так что пухнуть дочерние таблицы не будут. При периодическом опросе данные за прошедшие дни обстчитываются постепенно, и только за текущий - постойнно. В результате подтормаживание составляет при пересчёте прошедших суток считанные доли секунды, а за текущую дату - даже не заметно. Всё-таки выборка по timestamp ≥ {time} and (timestamp < {time} + INTERVAL 1 DAY) гораздо быстрее, чем упоминавшиеся ранее конструкции. Да и group by нужно будет убрать, т.к. алгоритм и ткак каждый раз выдёргивает по одной строке.

Зато теперь всё классно. :)

Спасибо Виктории.

обидеть Таню может каждый,
не каждый может убежать
----
ищу приличную работу,
но чтоб не связана с трудом
----
( Read more... )

…весь тот катаклизьм в ЖЖ, принял решение сворачивать там манатки:
1. Перестать кросспостить посты отсюда туда.
2. Поудалять тамошние посты, благо всё уже импортировано в дрим.
3. Свести тамошнюю активность до минимума.
Будет хуже там — больше народа станет перебираться в т.ч. сюда.

Знал я что where field in (…) — довольно дорогая конструкция, но чтобы на столько!
Иногда приходится её использовать в тех случаях, когда расходы на неё совсем небольшие, а методы обхода оказываются гораздо дороже.
Была старая задача, которая генерировала сводку по нескольким таблицам. В таблицах — результаты работы измерительных программ по изменению нагрузки. Ключевые параметры — дата/время, период, объект измерения. Данные собираются по 5, 15, или часовым интервалам. И тут нужно нарисовать табличку: колонка - дата, строка - параметр. Диапазон дат — до месяца, но не подряд, а выборочно. Вот тут-то и корячится where date in (date1, …, dateN). Свинство в том, что поля date нет, а есть datetime, то есть timestamp. А значит нужно делать или date(datetime), или substr(datetime, 1, N) в тех случаях, когда группировка по другим критериям. А это тоже накладно. Потом ещё будет group by по этому полю. Но where вырастает в date(datetime) in (…) и работает, соответственно, гораааздо дольше. Пока табличка была маленькая, всё работало довольно шустро. Но вот данных за год нападало уже на 23 миллиона и запрос стал выбираться несколько секунд. А это неприятно. Пришлось брать из загашников бубен. ;)
Первым делом попытался ограничить область поиска дополнительным условием. Т.е. минимальная и максимальная даты определяют вилку, за пределами которой можно ничего не искать.
Не помогло.
Без особой надежды решил убрать in (…) вообще, благо алгоритм обработки получаемых данных был построен так, что заполнял таблицу только нужными датами, а поправить нужно было только подсчёт итоговых значений, что делается одной строчкой.
Запускаю — и удивляюсь. Вместо нескольких секунд запрос стал выполняться доли секунды.
И это при том, что из-за group by калькуляция в запросе вынуждена выполняться над лишними датами!
Ладно, думаю. Может этот период просто незаполнен и пока ещё нечего считать? Делаю запрос за прошлый год и картина почти такая-же. Значит на самом деле 8*SUM+2AVG за 20 дней (по 288 измерений) выполняется гораздо быстрее, чем то же самое с IN (date1..date20).
«Вот что крест животворящий делает»©

Crossposts: http://c70we7.livejournal.com/113806.html

Удивительно, но сегодня приложение запустилось, спросило хочу ли я подключиться к идущей сессии только 1 раз и ни разу не предложило купить расширенную версию.
Но за время гонки оно один раз просто упало, а когда я на втором экране попытался поменять колонку лучшего времени на интервалы, зависло. И так три раза при трёх запусках подряд. После чего я уже не стал искушать судьбу, и ограничивался просмотром первого экрана.
А результат…
Доволен что Сэб обошёл Льюиса.
Не рад что Даня финишировал позади Карлоса. Хотя информация в начале гонки об отказе КЕРСа обещала ещё более худшим исходом. Но задумался — лучше бы не просили Сайнса пропускать Даню. Так была бы надежда обойти его своими силами и не требовалось бы уступать при неуспехе обгона Чеко.
А так-то, в общем-то, на плохо. И жаль, что БК не удержался за Даней. Мелочь, а было бы приятно.

Crossposts: http://c70we7.livejournal.com/113472.html

«Эх, были времена»© — на разных сайтах можно было спокойно найты повремёнку гонки. В онлайне.
Потом этих мест становилось всё меньше. На f1news.ru нашёл текстовую трансляцию и было не плохо.
Потом нашёл ещё и спортбокс. Особое удовольствие было в том, что без рекламы.
Повремёнку стал смотреть на сайте Ф1. Вроде ничё так, но клиет слишком тяжёлый.
Потом обнаружил нативного (!) под линукс (!) клиента - текстового(!!!). Юзал он тот же канал что и ф1-повремёнка. И было счастье.
Ещё оно добавлось после того, как обнаружил канал Sky Sport F1 через torrent-TV. С нашлёпкой на VLC.
И вот это был кайф, ибо в разных окнах были трансляция в спортбоксе, скайспорт, текстовая трансляция с f1news.rum, повремёнка текстовая либо на крайний случай тяжёлая в браузере, и карта трассы.
«Та не довго сонце гріло, не довго світило…» ©
Началось «западло» с того, что Берни со товарищи стал жадничать и с повремёнки пропали времена по секторам.
Потом пропал старый лёгкий интерфейс и появился толстый тяжёлый, через ещё какую-то хрень, которая работать не хотела.
Тут появилось приложение для андроида и я стал смотреть ливтайм там.
Потом перестал работать торрент-тв.
Потом какая-то жопа стала со спортбоксом.
В приложении, кстати, время на секторах тоже пропало.
Как ни странно, появилось предложение платить денежки и под этот шумок из фриварной версии пропало много и других фич.
В прошлом году цена на ф1аксэс выросла сразу втрое. Берни совсем совесть потерял. Покупать уже не стал.
После пары обновлений эта дура стала глюкавой, как не знаю что. Она стала виснуть. И чем дальше, тем чаще.
А как минимум, между годами не апгрейдиться нельзя, потому что на новый сезон расписание ему нужно.
И вот наконец сегодя первая квала сезона. Запускаю приложение. Предупреждает, как обычно — идёт трансляция, хотите присоедениться? Ясен пень! А зачем я его запускаю. И тут-же предлагает сапгрейдиться до про-версии, чтобы все фичи смотреть. Вот только вываливется в последнее время почему-то по две пары эих окошек. Да, нет, да, нет. В прошлом году после этого подключалась. А тут просит емейл, появляется клава, начинаю вводить... а поля-то ввода ничерта не видно - клавой закрыло. После нескольких попыток умудряюсь изловчиться, да только без толку, так как приложение вусмерть зависло. Если поторопиться, можно успеть несколько букв емейла ввести, до того как эта дура зависнет. А можно не вводить — всё равно зависнет. Пробовал переустанавливать — не помогло.
В общем, убили хорошие вещи.
Теперь остаётся только тупо пялиться в ТВ и текстовую трансляцию смотерть.

Crossposts: http://c70we7.livejournal.com/113251.html

Вот некоторые одарённые компании любят у себя писать "Техподдержка 24x7x365". Это значит, что они 29 февраля не работают? ;)
Зачем писать 365, если из 7 это и так следует?
И вообще, если написано "круглосуточно", то это должно значить и 7, и 365, и 366, и т.д.
Да, понимаю — просто маркетинговый ход. :) Расчитано на идиотов? Придумано идиотами? В лучшем случае и те и другие играют идиотов. В худшем — идиотов играют идиоты.
Точно, как сейчас модно:

И4^©

Crossposts: http://c70we7.livejournal.com/112978.html

После обновления с 12.04 до 16.04 на комп стало невозможно зайти по ssh со старого trustix.
Жаловался, что "

no matching cipher found: client aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael128-cbc,rijndael192-cbc,rijndael256-cbc,rijndael-cbc@lysator.liu.se server chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com

".
Не иначе как в борьбе за защищённость соединений отключили более слабые алгоритмы. Времени заняться сразу не было, и на время стал ходить с citrix в обход - через 12.04. Новые алгоритмы он знает, а старые у него не выключали.
Наконец дошли руки это дело полечить.
В итоге получилось довольно просто. В sshd_config добавил: "Ciphers +aes128-cbc". Пока разбирался с синтаксисом и мелочами "за компанию" добавил "Macs +hmac-sha1".
Клиент сменил тональность брани на "no kex alg".
Погуглил, нашёл совет, добавил "KexAlgorithms diffie-hellman-group1-sha1", после чего всё заработало.
Бинго.
А то я уже начал переживать, что придётся транзитный сервак оставлять как 12.04. Впрочем, пока его действительно нельзя трогать, потому что кое-какие важные проги (к сожалению, не opensource) на 16.04 глючат. На 12.04, кстати, тоже немного глючат, но по крайней мере использовать их это не мешает.

Crossposts: http://c70we7.livejournal.com/112786.html

Похоже, подошла очередь к гонениям на трекеры. Да, формально их в списки не заносили. Но в последнее время трекеры, откоторых "дорогих россиян" бытаются защищать начали отваливаться.
Сравните:

Сверху трейс с трекером, которого не блочат, снизу - заблоченный.
Интересно что DPI не дропает прямые пакеты, а только возращает RST чтобы сброс сделать руками клиента. Получается забавный эффект — статистика до трекеров всё-таки доходит. Можно было бы подумать, а почему бы и прямые пакеты не дропать? Но тогда можно было тем кто платит за трафик, требовать скидки за то, что их трафик на самом деле не пропускается ;)

UPD: Через реестр РКС обнаружил, что трекеры всё-таки прикрыли. Причём некоторые сначала по имени, а потом по айпишнику. Пришлось пробрасывать трафик к трекерам через тор. В торе вроде предусмотрен прозначный прокси, но у меня не получилось его заюзать. А вот через промежуточное звено в виде redsocks получилось сразу.

Это что-же такое получается? Прежде чем о чём-то написать нужно обязательно выяснить не является то, о чём ты собрался написать, запрещённым кем-нибудь где-нибудь? А если с того момента как ты ознакомился со всеми списками там этого ещё не было, а к тому моменту как ты кликнешь "запостить" появилось, то можешь хоть до посинения доказывать что ты не верблюд? Или всё-же это относится только к журналистам? А то мало-ли — нагнать сколько там надо троллей на страницу, чтобы выполнить "план по валу" не долго. Глядь — а тебя уже в "блогеры" произвели и повысили твою, никем нечитаемую страницу, до СМИ.

Crossposts: http://c70we7.livejournal.com/112457.html

Как средство борьбы с MITM-атакой (перехват DNS-запроса и выдача подложного ответа).
sudo apt-get install dnscrypt-proxy
Поставил на порт 8053.

/etc/bind/named.conf.options
…
<options>
    forwarders {
        127.0.0.1 port 8053;
…

Можно ещё в /etc/tor/torrc прописать "DNSPort <port>" и к нему привязаться.
Вот только после перезагрузки оказалось что dnscrypt-proxy автоматом не поднялся, и луковая часть со своей задачей не справилась. Первый до перезагрузки работал потому что поднимал вручную. В общем, надо было сделать systemctl enable dnscrypt-proxy. А вот с луковым разрешением адресов не понятно. Нужный адрес определился не правильно и браузер попал куда не надо. Если бинд обращался к тору за определением адреса и получил неправильный, то каков был механизм получения им неправильного адреса? Удивительно что если есть правильный адрес, то луковая маршрутизация работает правильно. То есть https до нужного хоста доходит, а запрос на определение его адреса — нет. Если же бинд после неудачной попытки определить адрес через dnscrypt не стал обращаться ко второму форвардеру, то тут мысль останавливается: через кого тогда вообще адреса были получены, если больше форвардеров не прописано?

В общем, работает — и ладно.

PS. dnssec включен, но увы — далеко не у всех зоны подписаны.

Crossposts: http://c70we7.livejournal.com/112361.html

Начался очередной спейсианский месяц, а у нас в земном феврале северного полушария [в Иркутске] всё тает и течёт. Посмотрел историю - в феврале 11 года было тоже тепло. Но только один день, хотя и 18-го. А у нас тут уже несколько дней так. До +6—+8°C. Офигеть.

Crossposts: http://c70we7.livejournal.com/111886.html

Слушая в очередной раз умных людей опять задумался об этом эффекте: человек объясняет причины некоторых явлений и механику процессов. Не сложных и вполне доступных для понимания. Которые ты бы и сам мог «придумать». Собственно удовольствие при восприятии этой информации заключается в том, что доступное и понятное объяснение мозг поощеряет и выделяет то ли эндорфин, то ли дофамин - всё время их путаю.
Мог придумать, но не придумал. Почему?
И пришло на ум такое объяснение: множество слов и смыслов организовывают такое немыслимо огромное пространство значений, что тупым обходом найти что-то стоящее невозможно. В вопросах, где ты компетентен, топология пространства смыслов тебе на столько знакома, что ты знаешь — вот за таким пригорком должен быть такой-то овраг, а дальше ручей, который впадает в речушку. Понятно, да? Но в незнакомой обстановке ты эти приметы не знаешь и поэтому выйти на цель не можешь. Отдельно некоторые вещи ты, конечно, знаешь. Что ручей впадает в речку. Что ручей будет где-то на склоне холма, если на нём топкая местность. Но в "диком" месте много элементов ландшафта, о взаимосвязи которых ты не знаешь в силу своей некомпетентности, что невозможен целенаправленный поиск.
А набрести на него случайно не можешь в силу немыслимо огромного пространства, где всё это существует.

Блин. Написал, прочитал - выглядит коряво. Ну и пофиг, пусть будет. :)

Crossposts: http://c70we7.livejournal.com/111621.html

Пришло простое текстовое письмо на яндекс почту.
И посреди этого pure текста одно слово ТТК написано синим текстом и рядом иконка (розовая запятая высотой со строку)…
ТТК в данном случае — это ТрансТелеком.
Оказывается он посинел потому, что яндекс впендюрил туда линк на яндекс карты. И запятая - это стилизованный указатель на картах, типа дорожного знака. Но у гугля он симметричный, а у яндекса запятушкой. Интересно почему бы не использовать натуральный знак? Или его кто-нибудь уже использует?
Долго не мог понять какая связь между ТТК и объектом на карте (какая-то дорожная развязка).
Наконец-то дошло: развязка находится на Третьем Транспортном Кольце.
Офигеваю.

Crossposts: http://c70we7.livejournal.com/111496.html

Да, да, да — пришли новые дрова (304.135 из альтернативного репозитария) и я решил, что в достаточной мере набил руку чтобы справиться возможными проблемами, которые могут возникнуть.
Нет, я конечно, справился, но это не было "лёгким движением руки".

Ну так и вот — сапдейтил, перезагружаюсь и начинается день сурка: во втором терминале на чёрном фоне серое окошко с надписью (тут подойдёт голос депрессивного робота Мерлина) "ну чё это у вас такое низкое разрешение — я отказываюсь работать в таких условиях".
Конечно, последователь действий уже отработана: надо начинать с Xorg.log. А лучше сразу запускать nvidia-bug-report.sh и там будут все интересующие логи.

[    72.326] (EE) NVIDIA(0): Failed to initialize the NVIDIA kernel module. Please see the
[    72.326] (EE) NVIDIA(0):     system's kernel log for additional error messages and
[    72.326] (EE) NVIDIA(0):     consult the NVIDIA README for details.
[    72.326] (EE) NVIDIA(0):  *** Aborting ***
[    72.326] (EE) NVIDIA(0): Failing initialization of X screen 0

Таких сообщений не помню, но удивления не вызываает. Не пытаюсь особо вникать в обстоятельства (а может и стоило бы) — первая мысль: опять кто-то конфиг сожрал. И точно. Запускаем nvidia-xconfig… Помнится как-то получалось поднимать иксы даже без перезагрузки. Но не в этот раз.
Модуль? Ну да: "modprobe nvidia-304 тоже всегда помогал".
Но ни в этот раз. "Sent; server replied with: Couldn't connect to server"

Изучаю логи ещё внимательнее и начинаю удивляться: "Parsing /var/crash/nvidia-304.0.crash."
Или вот: "modprobe: FATAL: Module nvidia-304 not found in directory /lib/modules/4.4.0-63-generic"
"Становится что чудастее и чудастее"©.


NVRM: API mismatch: the client has the version 304.135, but
NVRM: this kernel module has the version 304.134.  Please
NVRM: make sure that this kernel module and all NVIDIA driver
NVRM: components have the same version.

Но это я еще не сразу заметил.
После очередной перезагрузки на второй консоли депрессивный Марвин, но на седьмой — работающий стол. Да, с таким тоже сталкивался.

Ещё несколько камланий с перезагрузками и решаю откатить дрова назад. А они не откатываются. Даунгрейдом занимался только один раз и сейчас понимаю что недопонял синтаксис. Если на 304.134-0ubuntu0.16.04.1 даунгрейдиться, то надо указывать 304.134-0ubuntu0, а если на 304.135-0ubuntu0~gpu16.04.1? Я указывал 304.135-0ubuntu0, а, похоже, надо 304.135-0ubuntu0~gpu?
Ну, не важно, "и так хорошо получилось"©.

В общем, решил сделать даунгрейд более серьёзным образом: снести дрова с зачисткой purge, естественно, отключить альтернативный репозитарий, и инсталировать что есть уже из основного. Точнее, в нём лежат, например, 304.131-0ubuntu3, на которые я уже один раз возвращался.

Сказано — сделано. Но, лыжи, извиняюсь, почему-то всё-равно не едут. Что за хрень?
Снова штудирую логи: "Failed to start /etc/rc.local Compatibility"
Ага. Это я в прошлый раз поставил тут костыль: если ничего не получилось автоматом, то запускать "modprobe nvidia-304". ;) Вообще-то это не правильно, надо убрать.
Проверяю за компанию /etc/modules. Прописан и закоменчен с прошлых камланий nvidia_304. В /etc/modprobe.d/nvidia-graphics-drivers.conf как положено введён модуля алиас, в чёрный список загнаны близкие дрова, которые не должны загрузиться по ошибке и присвоен алиас off тому же nouveau. Вроде порядок.
На всякий случай проверяю лежащие там-же остальные конфиги и обнаруживаю в blacklist-local.conf "blacklist nvidia_304". Ах ты …~~(зачёркнуто)~~… "нехороший человек"© "с низкой социальной ответственностью"©. :) Вот что за сволочь и когда это сделала?
Убираем, перезагружаемся — работает. "Не дышим". На вчера с меня было достаточно.

Но удовлетворение будет не полным, если не попытаться — да, да, да, я люблю плясать по граблям ;)!!! — из основного репозитария поставить всё-таки последние дрова — не 131, а 134.
Собственно, стою на пороге паразагрузки. Поехали? ;)

UPD. Итог: при перезагрузке система зависла в фазе выключения. Вообще, с этим systemd выгрузка стала проходить на порядок дольше. Но загрузка оказалась успешной, вплоть до рабочего стола. Медленно, конечно, но может это ureadahead трудился.

Crossposts: http://c70we7.livejournal.com/111141.html

Ну и какая же из сволочей виновата?
Не исключено, что все три. Но всё началось с последней. Именно после апгрейда последней начались утечки памяти и прочая хрень, которая закончилась необходимостью глобального апгрейда и "всем тем катаклизмом, который я тут наблюдаю"©.
Удивительно, но не прав, похоже, второй. Вывод сделан на основании того, что после перевода обоих компов на xfce истерические падения (на втором) и катастрофическое утекание памяти (на первом) угомонилось.
И, естетсвенно, первый участник соцсоревнования (кто устроит ситуацию гаже) тоже к этому причастен и не смог справиться с наплывом проблем.
Разгребание проблем ещё далеко не закончилось, не смотря на то что уже и так дофига всего пришлось докрутить.
От xfce, кстати, есть один побочный положительный эффект: оказалось возможным переключалку раскладки сделать однокнопочной, как было раньше - л-меню первая, п-меню последняя.
Из печальных последствий - сломалась тулза станционной онлайн-документации. Не полностью - тулбар получить дефаултовую инфу от демона не может. А по оглавлению и ссылкам всё открывает и выдаёт. Тот же тулбар с фиктивно-заданным именем файла получить тоже возможно, и форма для поиска открыватся. Как так? Надо будет подумать как попатчить это дело.
Отвалился apparmor - пришлось шаманить. Кажется это как раз та история с fancontrol была, о которой уже рассказывал.
Не поднялся ht-кэшклинер. Поискал нужный модуль - прицепил. Решил заюзать для апача седьмой php, раз уж он в системе уже стоит.
На вики-сервере перестали обрабатываться мат-формулы. Долго колдовал с texvc - не помогло.
Ясное дело - там и апач, и php проапгрейдился и ещё куча всякой хрени. Год назад уже наступал на грабли: апргрейдил его-же, но новый код был заточен на более новую версию php. Прикрутил альтернативный репозитарий, подхватил оттуда требуемую версию php и вроде поехало. Ну, тут-то дело очевидное. Разбираться по мелочам? Нафиг нужно. Апгрейдим весь сервак, все расширения из фарма и все по-отдельности установленные, апдейтим базу. Сходу не пошло - ага! там же композер ~~теперь~~ давно. Композер тогда прикладывал без установки, "на коврике". А тут, похоже, штатный появился, а подхватывался тот что "на коврике". Поэтому и апдейт его проходил как-то криво. "Выстирал коврик". :) Поехало. Дальше понятно уже - апдейтим базу, ок. Вдруг ни с того, ни с сего ругается на права. Пошарился по логам, по дебаговому логу тоже. Е-моё! А чего это l10n_cache-en.cdb с правами от www-юзера, а l10n_cache-ru.cdb - от рута? Ясное дело - апгрейд-же от рута делался. А от кого-же ещё? От www-юзера нельзя, потому что у него хомяка нет. Ну и хрен с ними. Човним файло, а за компанию весь каталог по рекурсии с wiki-движком.
Бинго! Работает? А как-же!
Как бы не так. Потом обнаружил, что оформленная через него записнушка нифига не отображает. Опять кучу времени угрохал, пока разобрался. Оказывается DPL старого кода юзает переменные из Cite, а в последнем они с какого-то времени стали приватными. И что делать? Cite "свежее", но не намного. DPL вообще от "третьей стороны". Глянул гитом хронологию - и плюнул. Полез в код Cite и ~~национализировал~~ запубличил переменные. Заработало.

И тут бы расслабиться, но стали наблюдаться глюки. То конки себя почувствует ван Гогом, то у фокс упадёт, но компиз отметится. И загрузка что компиза, что иксов стала подрасать и памяти отъедать подозрительно больше чем надо.
А тут вызываю полуночного командира и через некоторое время он тоже падает. Ну ладно: упал - отжался. Хрен там. Теперь уже каждый раз при запуске сразу в корку падает. Охреневший чего только не делал. Отпустило только после того как в /tmp удалил mc-user. "Что это было, Пух?"©

Интересно, что на компе с меньшем количеством памяти (да и хрени всякой на нём меньше установлено) глюков наблюдалось заментно меньше. В борьбе за память пришлось уползти на xfce и глюки наблюдаться перестали. До этого ещё пытал metacity. Тоже без компиза, но тоже, скотина, прожорлив. Ну и с настройками не очень хорошо получалось. Поэтому в итоге xfce решил попробовать более основательно. Короче. На второй машине тоже перешёл на xfce. И что-то больше глюков не наблюдаю. Белочка - так же самая, nvidia та-же самая, иксы - тоже. Выходит самое слабое звено в этой цепочке был компиз? Ну, или юнити.
Вот, кстати, пока бодался с дровами на первой машине, пробовал nouveau. Тоже изрядно гадили в syslog. Я думал что проблема именно в них, но теперь подозреваю что в компизе.
Надо будет попробовать их ещё раз, но теперь уже с Mir и Unity8.

Crossposts: http://c70we7.livejournal.com/111055.html

Эх, зря я так надеялся что наблюдаемые гадости — мелкие. :)

Из гадостей регулярно наблюдаемых — глюченье и падение conky. Самый наблюдаемый глюк: перестаёт очищать рабочее поле и новый текст ложится поверх старого. То ли второй буфер ему перестают выдавать, то ли вместо нового указателя выдают указатель на первый буфер - ХЗ. Может это глюки не его, а того кто выделяет ему память? Может. но падать приходится ему. Пришлось завернуть его цикл, снова запускающий его после падения. Из странного: "Invalid MIT-MAGIC-COOKIE-1 keyconky: can't open display: :0", над чем нужно будет подумать.
Интересно что за последнюю неделю к нему трижды приходил oom-killer. Раз в три дня. Регулярно. Точнее, один раз к нему, и два — к его дочернему процессу. С segfault, как самому активному процессу, ему пришлось падать больше сотни раз.

Падать приходится не только ему, но и firefox. Я его не закрываю и где-то этот мусор накапливается, приводя к падению: "Out of memory: Kill process 2250 (firefox) score 49 or sacrifice child". Но он падает гораздо реже, что огорчает не менее.

Вот, кстати, даже компиз с десяток раз падал. Что за хрень?

Тут ещё пытался разобраться что к чему и выяснял что за фрукт такой systemd. Оказывается Поттеринг придумал такой обобщённый статус, который выводится из статусов всех запущенных через него юнитов. На машинке с меньшим количеством памяти, но и с конфигурацией попроще эта беда не вылезала. А вот на второй обнаружилось что статус у неё — "деградированный". Причина: несколько модулей запущены с ошибками. Вот, например, fancontrol лежал и никому не мешал. Когда-то успешно работал, но потом кому-то умному пришло в голову всё ~~сломать~~ переделать, в результате чего старые дрова к фанам перестали пускать, а новые этот функционал поддерживать не умеют. Но ведь не мешал-же он никому? А systemd-у — мешает. Снёс. Долго не удалял, собираясь поковыряться и заставить работать. Впрочем, было это тогда ещё, когда кулер был шумным и тихая работа была осознанно нужна.
Но вот уже, кажется, два года как кулер заменён на тихоходный, но не менее эффективный, и добавлен в корпус второй такой-же тихоходный. Так что в принципе - не жалко.

Замотала какая-то хрень с miredo. При старте не поднимается, т.к. нужен ip-адрес шлюза, а его ещё нет. Пытался релятивировать его от запуска named-а, но не помогло. Нашёл где-то совет рестартануть его через rc.d, но мне как-то не очень это понравилось. Придумал другой хинт — прописал адрес шлюза прямо в hosts. В итоге miredo поднимается без дополнительных пинков, минус один failed юнит, но такое ощущение, что не всё там так гладко. Почему-то evolution считает что сети нет и соответственно почту с pop-сервера забрать не может. Хотя, вообще-то, к miredo он не привязан никак и до pop-сервера (и smtp тоже) ему надо ходить по обычному статику eth. Какого чёрта ему ещё надо - не пойму, но факт в том, что networking.service — failed, хотя сетевые дела работают без проблем.
От того-же мониторинга осталась запись в модулях на it87, но модуль - йок. Поэтому systemd-modules-load.service тоже долго болтался failed. Повозился с it87, поковырял fancontrol, посмотрел на sensors и решил, что обойдусь показаниями кулеров через atk0110. Отвинтил и - о чудо! - systemd-modules-load.service "узбагоилса". :)
С networking.service пока так и не разобрался.

При попытке разобраться откуда растут гадости зацепился за "nvidia: module verification failed: signature and/or required key missing - tainting kernel". Ну, думаю, перестарался. Наверно в альтернативной репе дрова не верифицированные. Увидел кроме установленного 134 доступный 131 - сдаунгрейдился. Увидел просьбу включить в биосе Cool'N'Quite - включил.
И тут началось нечто невообразимое — всё глючит, виснет, не реагирует ни на что.
Зашёл с планшета по ssh пытаюсь хоть так зашатдаунить - шатдаульная задача, которая теперь работает через systemd, отваливается по таймауту. Драсте.
Семь бед - один ресет.
В итоге отключит эту дрянь и вернул дрова, пока не начало глючить. Вроде глюки успокоились.
Разглядывая собранный nvidia-bug-report отчёт заинтересовался что за Mir такой и выяснил, что грядёт unity8. Народ говорит что у проприетарных дров от nvidia с ним могут быть поблемы, а вот nouveau в самый раз. Что-то не заладилось с нвидиа в последнее время. Читал где-то что выкатили нвидиа предложения затолкать в ядро их наработки, которые были бы типа очень классными для их карт, на что Линус их постал. Нехрен, мол, это ваше дерьмо в ядро совать. Так что вот. Такое ощущение, что нвидиа решила: "Ах, так?"… Собственно, вся эта хрень началась именно с очередного обновления дров от nvidia. Вот бы знать заранее. Не обязательно это осознанное вредительство. Скорее всего какие-то изменения вносили для дальнейшего развития с замахом на патчинг ядра, но не срослось. "Ну и вот".

Я бы уж и 12.04 вернул, вот только дрова бы найти "докризисные". :)

Crossposts: http://c70we7.livejournal.com/110654.html

Profile

crower

February 2018

S	M	T	W	T	F	S
				1	2	3
4	5	6	7	8	9	10
11	12	13	14	15	16	17
18	19	20	21	22	23	24
25	26	27	28

Syndicate

Page Summary

Style Credit

Style: Green Machine for Lefty by sarken

Expand Cut Tags

No cut tags

Page generated Jan. 26th, 2026 06:03 am

Recent Entries

Navigation

Поиск источника проблемы продолжается…

Загадка от провайдера

хронология команд

Неэффективная оптимизация

фейсбучек чтобы не заныкал, хочу вот это сохранить :)

Наблюдая…

Where var IN (…)

"Official F1 ® App" II

"Official F1 ® App"

О мемах

И4^©

ssh со старого хоста на новый

Про гонения на трекеры

Вопрос

dnscrypt-proxy

1488.0

Meaning mining

Закон дырявых абстракций в действии

И снова nvidia

xenial, compiz, nvidia

Последствия апгрейда на 16.04

Profile

February 2018

Syndicate

Most Popular Tags

Page Summary

Style Credit

Expand Cut Tags

Recent Entries

Navigation

И4©

Syndicate

Page Summary

Style Credit

Expand Cut Tags

И4^©