?

Log in

No account? Create an account

Категория: медицина

Chrome, слетают настройки Adblock Plus
tux
oyx
Chrome: Версия 64.0.3282.186 (Официальная сборка), (64 бит), Adblock Plus 1.13.5.
После закрытия браузера очищается список фильтров, ни одного не остаётся. Лечится?

P.S. стоящий рядом Chromium: Version 64.0.3282.167 (Official Build) Built on Ubuntu , running on LinuxMint 18.3 (64-bit). Adblock тот же - всё нормально.

Viber
tux
oyx
Виснет наглухо. Запустился как-то разок, синхронизировался с телефоном, и всё.
И дело вовсе не в недавних железячных проблемах - это на разных машинах.
Я так понимаю, что веб-клиента у них нет (чтобы засунуть в какой-нибудь Rambox и не плодить сущности)? Или что делать с десктопным?
Качал деб отсюда. Виндовый пытался, но вайн грохается в инсталляторе.

UPD:

Ха! Я его просёк!

Если коротко, то лечится сносом ~/.ViberPC/[циферки] + ~/.ViberPC/stickers

Если подробней - дело не в Qt и зависимостях. А в том, что после какого-то количества сообщений и/или всякой херни в кэше у него башню сносит. Завтра попробую подтвердить (или опровергнуть) более доказательно.

Policy routing и Reverse Path Filtering
dil
Есть у меня машинка с двумя сетевыми интерфейсами (eth0 и eth1), подключёнными к разным провайдерам. Оба провайдера используют серые адреса и NAT. Пусть будут, скажем, 172.16.1.2 и 192.168.3.4. Default route смотрит в первого провайдера. Понадобилось мне отправить трафик на определённый порт через второго провайдера.

Задача типичная, много раз в интернетах разжёванная.
Создаём дополнительную маршрутную таблицу foo, добавляем в неё маршрут ip route add default via 192.168.3.1 dev eth1 table foo, маркируем нужный трафик с помощью iptables -t mangle -A PREROUTING -p tcp --dport $port -j MARK --set-mark 5, и маршрутизируем этот трафик по дополнительной таблице с помощью ip rule add fwmark 5 table foo.

Трафик начинает ходить через eth1, но... уходит он с адреса 172.16.1.2, и естественно, ничего не работает. По совету лучших собаководов маскарадим маркированный трафик: -t nat -A POSTROUTING -m mark --mark 5 -j SNAT --to 192.168.3.4.

Теперь трафик уходит с правильного адреса, ответы приходят, но... до программы не доходят.
Дальнейшее гугление показало, что его убивает Reverse Path Filtering. Лечится путём echo 0 > /proc/sys/net/ipv4/conf/eth0/rp_filter, и то же самое для eth1 и ещё для all, иначе таки не работает. Почему срабатывает RPF - не сильно понятно, по идее он должен убивать входящие пакеты, ответы на которые через этот интерфейс ходить не должны. А в данном случае они как раз должны.

Вопрос: нельзя ли достичь нужного результата менее извращёнными методами, без SNAT и отключения RPF? Программа ни к какому адресу явно не байндится, он должен подставляться автоматически, а подставляется почему-то всегда только 172.16.1.2.

Добавление к маршруту параметра src 192.168.3.4 (ip route add default via 192.168.3.1 dev eth1 src 192.168.3.4 table foo) никакого эффекта не дало. Чувствую, что я упустил какую-то простую вещь, но не пойму, какую..
Метки:

[Решено] OpenSUSE 11.4, xinit чудит
creo_void
Всех с наступающим!
На днях поставил себе OpenSUSE 11.4 (kde в качестве рабочей среды, если это важно). Всё хорошо, всё здорово, но перестала работать команда:
xinit -- :1
Ругается вот:
Fatal server error:
Cannot open log file "/var/log/Xorg.1.log"
Please consult the The X.Org Foundation support 
         at http://wiki.x.org
 for help. 

Что это может быть и как лечить?

UPD: при ручном создании файлов логов ошибка меняется на

Fatal server error:
xf86OpenConsole: Cannot open /dev/tty0 (No such file or directory)

UPD2: проблема решилась с помощью этой темы

Mdadm
yearshow
очень прошу совета - гугл однозначного ответа не даёт...

дано:
Mandrake 10.2 (2005 LE) 2.6.11-6mdk

mdadm-ом собран raid1 на двух hdd
конфигурация разделов следующая

sda1 (sdb1) * 1 191 Linux swap (82)
sda2 (sdb2) 192 и до конца Linux raid (fd)

файловая система ext3

в результате пятничного обвала электричества в Спб сервер был выключен аварийно (питание отрубилось)
после включения - на первом диске слетело lilo
тупо загрузились со второго диска - всё ок, рэйд завёлся на одном втором диске

вставили второй. делаем синхронизацию
доходим до определённого места, получаем ошибку
"unrecoverable i/o read error" for block 89733632
процесс синхронизации прерывается, начинается заново и так до бесконечности
лечится выключением и запуском вновь с одного диска

полагаю, что загрузка с liveCD (или дистр в rescue режиме) и запуск e2fsck меня может спасти
но - в таком режиме я рэйд собрать не могу - вижу только раздел sdb2

есть идея запустить e2fsck -с тупо на раздел sda2 - чем это может быть чревато в дальнейшем?
или - как в этой ситуации поступить наиболее правильно?
Метки:

kacpid и kacpi_notify
43
j_sheridan
Ни с того ни с сего на серванте процессы kacpid и kacpi_notify начали нехило кушать процессор. То есть полностью. Пока что перегружусь с acpi=off и apm=off, но хотелось бы узнать - это лечится? А то судя по гуглу проблема тянется еще с 7го года...

(без темы)
Я
bukky_boogwin
Почему-то регулярно после переключения окон по Alt+Tab Tab залипает - как бы остается нажатой и, например, в текстовом редакторе начинает вставлять символы табуляции, и лечится это только еще одним нажатием на эту клавишу - мелочь, но неприятно. Как с этим бороться?
Система - Kubuntu 10.04, оболочка - KDE 4.4.2. Клавиатура в порядке - в установленной на том же компе винде такого глюка нет.

В гугле нашел только это: http://forum.ubuntu.ru/index.php?topic=91963.0 - проблема та же, решения не нашли.

Server refused to allocate pty
default
alexrat
Имею VPS-хостинг. Попытался зайти по ssh и получил ошибку Server refused to allocate pty.
Физического доступа к машине не имею, только просить техподдержку перезагрузить виртуальный сервис? Или есть какие-то другие варианты лечения?

куда-то ушли все tty
Камешки на доске
italler
Скорее всего после очередных обновлений openSuSE 11.0 у меня пропала возможность логиниться на консоль при нажатии Ctr+Alt+F(1,2,3,4,5,6).
Runlevel по умолчанию 5, поэтому wdm, загружается, там логин принимается, всякие терминалы запускаются без проблем.

Кто-нибудь сталкивался с таким? Как лечится?

подтверждение удаления файлов в Гноме (Nautilus)
rvp74
Помню, такая беда была в Ubuntu 7.04, 8.04, а сейчас и в 9.04 (подозреваю что в других дистрибутивах аналогично): если помеченные в Nautilus файлы удалять по клавише del, то они удаляются незамедлительно и без запроса подверждения. Причем это происходит в независимости от того что в параметрах Nautilus стоит опция "спрашивать перед очищением корзины или удалением файлов".
Кто-нибуть знает как это безобразие лечится?