Re: почему ядро не сбрасывает кэш?

[Hleb Valoshka]

On 12/2/15, Aleksandr Sytar  wrote:
>> А вот сегодня мне пришлось вручную сбрасывать кэш, занимавший около
>> 60% всего объёма ОЗУ, пока этого не сделал, была загрузка процессора
>> ядром под 90% и в логи валились сообщения типа "[6848409.216723] java:
>> page allocation failure. order:1, mode:0x20
>> [6848409.216929] Pid: 17814, comm: java".
>>
>> Там ещё прозрачные huge pages включены, но это, думаю, не столь важно.
>>
>> Вопрос, почему ядро не сбрасывает кэш?
>>
>
> Все несколько сложнее чем кажется на первый взгляд, но сообщения о нехватке
> памяти может быть получено когда память есть, но не та которая нужна
> приложению - в данном случае java попросила 1 страницу 8к, и их не

Это вы к примеру сказали, или из сообщения определили (order:1, mode:0x20)?

> оказалось, а вот страниц 4к, 16к и т.д. вполне могло быть в достатке.

И при этом 250 ГБ заняты под кэш, почему бы не почистить его?

Re: какой правильный способ работать с /sys из initrd?

[Andrey Melnikoff]

Dmitry E. Oboukhov  wrote:
> [-- text/plain, кодировка quoted-printable, кодировка: utf-8, 74 строк --]

> проблема в том что usb контроллер инициализируется сколько-то времени
> и файлики в /sys/bus появляются далеко не сразу.
Они там появляются когда udev загрузит модуля.

> что лучше вкрутить? просто скрипт в initramfs или есть какой-то
> конкретный механизм на эту тему?
В udev засунь правило реагирующее на твой USBID

Re: почему ядро не сбрасывает кэш?

[Aleksandr Sytar]

2 декабря 2015 г., 17:33 пользователь Hleb Valoshka <375...@gmail.com>
написал:

> On 12/2/15, Aleksandr Sytar  wrote:
> >> А вот сегодня мне пришлось вручную сбрасывать кэш, занимавший около
> >> 60% всего объёма ОЗУ, пока этого не сделал, была загрузка процессора
> >> ядром под 90% и в логи валились сообщения типа "[6848409.216723] java:
> >> page allocation failure. order:1, mode:0x20
> >> [6848409.216929] Pid: 17814, comm: java".
> >>
> >> Там ещё прозрачные huge pages включены, но это, думаю, не столь важно.
> >>
> >> Вопрос, почему ядро не сбрасывает кэш?
> >>
> >
> > Все несколько сложнее чем кажется на первый взгляд, но сообщения о
> нехватке
> > памяти может быть получено когда память есть, но не та которая нужна
> > приложению - в данном случае java попросила 1 страницу 8к, и их не
>
> Это вы к примеру сказали, или из сообщения определили (order:1, mode:0x20)?
>

(2^order)*page_size - количество нехвативших страниц


> > оказалось, а вот страниц 4к, 16к и т.д. вполне могло быть в достатке.
>
> И при этом 250 ГБ заняты под кэш, почему бы не почистить его?
>

Почистить можно то что свободно, то что занято можно выдавить в свап, но не
сразу, а только через dirty_background_ratio и подобным ручкам.

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

Re: какой правильный способ работать с /sys из initrd?

[sergio]

On 12/02/2015 04:31 PM, Dmitry E. Oboukhov wrote:

> надо сделать
> echo 1 > /sys/bus/usb/bla/path

sysfsutils не про то?

-- 
sergio

Re: какой правильный способ работать с /sys из initrd?

[Sergey B Kirpichev]

On Wed, Dec 02, 2015 at 04:31:18PM +0300, Dmitry E. Oboukhov wrote:
> вопрос: а какой кошерный способ есть в initramfs сделать это
> автоматически?

Думаю смотреть в сторону /etc/initramfs-tools/scripts/

> проблема в том что usb контроллер инициализируется сколько-то времени
> и файлики в /sys/bus появляются далеко не сразу.

ROOTDELAY точно не устроит?

Re: почему ядро не сбрасывает кэш?

[Oleksandr Gavenko]

On 2015-12-02, Hleb Valoshka wrote:

> Вопрос, почему ядро не сбрасывает кэш?

Известная страница:

  http://www.linuxatemyram.com/

Кроме юмора есть детали: http://www.linuxatemyram.com/play.html

-- 
Best regards!

Re: какой правильный способ работать с /sys из initrd?

[Dmitry E. Oboukhov]

> On Wed, Dec 02, 2015 at 04:31:18PM +0300, Dmitry E. Oboukhov wrote:
>> вопрос: а какой кошерный способ есть в initramfs сделать это
>> автоматически?

> Думаю смотреть в сторону /etc/initramfs-tools/scripts/

в том вопрос и состоит: скрипт надо писать или можно в конфиг
какой-то влезть каким-то образом?

-- 

. ''`.   Dmitry E. Oboukhov
: :’  :   email: un...@debian.org jabber://un...@uvw.ru
`. `~’  GPGKey: 1024D / F8E26537 2006-11-21
  `- 1B23 D4F8 8EC0 D902 0555  E438 AB8C 00CF F8E2 6537


signature.asc
Description: Digital signature

Re: какой правильный способ работать с /sys из initrd?

[Victor Wagner]

В Wed, 2 Dec 2015 18:26:18 +0300
sergio  пишет:

> On 12/02/2015 04:31 PM, Dmitry E. Oboukhov wrote:
> 
> > надо сделать
> > echo 1 > /sys/bus/usb/bla/path
> 
> sysfsutils не про то?
> 



-- 
   Victor Wagner 

Re: почему ядро не сбрасывает кэш?

[Hleb Valoshka]

On 12/2/15, Oleksandr Gavenko  wrote:
>> Вопрос, почему ядро не сбрасывает кэш?
>
> Известная страница:
>
>   http://www.linuxatemyram.com/
>
> Кроме юмора есть детали: http://www.linuxatemyram.com/play.html


Вы вопрос-то прочитали?

Re: почему ядро не сбрасывает кэш?

[Hleb Valoshka]

On 12/2/15, Aleksandr Sytar  wrote:

>> Это вы к примеру сказали, или из сообщения определили (order:1,
>> mode:0x20)?
> (2^order)*page_size - количество нехвативших страниц

В логах 71 запись, из них 39 принадлежат процессц swapper, pid 0, 1 -
kswapd0, ещё 26 яве, остальное прочим, и всем не хватало 1-ого буфера
в 8 кб. И это на машине с 512 ГБ ОЗУ и 2 ГБ свопа.

>> И при этом 250 ГБ заняты под кэш, почему бы не почистить его?
> Почистить можно то что свободно, то что занято можно выдавить в свап, но не
> сразу, а только через dirty_background_ratio и подобным ручкам.

Это тянулось явно побольше 10 сек (dirty_background_ratio), при этом,
после чистки руками, кэш до 200 ГБ около часа, т.е. кандидатов на
выбросить оттуда было более чем достаточно.


> Но при этом нужно понимать - если система будет перекладывать страницы в
> свап, она будет дольше из него доставать (поищи страницы в памяти, получи
> ошибку, что она в свапе, загрузи в память, отдай приложению), что скажется
> на скорости работы. Поэтому разумнее ограничить аппетиты нового приложения
> с учетом текущих реалий по кешу.

Приложение уже ограничено по памяти, т.к. ява.

Учитывая соседнюю тему, где сброс кэша помогает ускорить apt-get,
несмотря на наличие 12 ГБ свободной памяти, есть подозрение, что в
Линуксе работа с памятью поломана.

[DONE] wml://security/2008/dsa-1{637,690,659,561,688,575,548,678,505,660}.wml

[Lev Lamberov]

Cheers!
Lev Lamberov
--- english/security/2008/dsa-1505.wml	2014-04-30 13:16:15.0 +0600
+++ russian/security/2008/dsa-1505.wml	2015-12-02 23:58:55.113411629 +0500
@@ -1,23 +1,24 @@
-kernel memory leak
+#use wml::debian::translation-check translation="1.3" maintainer="Lev Lamberov"
+утечка памяти ядра
 
-Takashi Iwai supplied a fix for a memory leak in the snd_page_alloc module.
-Local users could exploit this issue to obtain sensitive information from
-the kernel (https://security-tracker.debian.org/tracker/CVE-2007-4571;>CVE-2007-4571).
+Такаши Ивай предоставил исправление утечки памяти в модуле snd_page_alloc.
+Локальные пользователи могут использовать эту уязвимость для получения чувствительной информации
+ядра (https://security-tracker.debian.org/tracker/CVE-2007-4571;>CVE-2007-4571).
 
-For the oldstable distribution (sarge), this problem has been fixed in
-version 1.0.8-7sarge1. The prebuilt modules provided by alsa-modules-i386
-have been rebuilt to take advantage of this update, and are available in
-version 1.0.8+2sarge2.
+В предыдущем стабильном выпуске (sarge) эта проблема была исправлена в
+версии 1.0.8-7sarge1. Предварительно собранные модули, предоставляемые пакетом alsa-modules-i386,
+были собраны заново с учётом этого обновления, они доступны в
+версии 1.0.8+2sarge2.
 
-For the stable distribution (etch), this problem has been fixed in
-version 1.0.13-5etch1. This issue was already fixed for the version
-of ALSA provided by linux-2.6 in DSA 1479.
+В стабильном выпуске (etch) эта проблема была исправлена в
+версии 1.0.13-5etch1. Данная проблема уже была исправлена для версии
+ALSA, поставляемой в linux-2.6 в DSA 1479.
 
-For the unstable distributions (sid), this problem was fixed in version
+В нестабильном выпуске (sid) эта проблема была исправлена в версии
 1.0.15-1.
 
-We recommend that you upgrade your alsa-driver and alsa-modules-i386
-packages.
+Рекомендуется обновить пакеты alsa-driver и
+alsa-modules-i386.
 
 
 # do not modify the following line
--- english/security/2008/dsa-1548.wml	2014-04-30 13:16:15.0 +0600
+++ russian/security/2008/dsa-1548.wml	2015-12-02 23:51:37.860621783 +0500
@@ -1,28 +1,29 @@
-several vulnerabilities
+#use wml::debian::translation-check translation="1.6" maintainer="Lev Lamberov"
+несколько уязвимостей
 
-Kees Cook discovered a vulnerability in xpdf, a set of tools for
-display and conversion of Portable Document Format (PDF) files.  The
-Common Vulnerabilities and Exposures project identifies the following
-problem:
+Кис Кук обнаружил уязвимость в xpdf, наборе инструментов для
+отрисовки и преобразования файлов в формате Portable Document Format (PDF).  Проект
+Common Vulnerabilities and Exposures определяет следующую
+проблему:
 
 
 
 https://security-tracker.debian.org/tracker/CVE-2008-1693;>CVE-2008-1693
 
-Xpdf's handling of embedded fonts lacks sufficient validation
-and type checking.  If a maliciously crafted PDF file is opened, 
-the vulnerability may allow the execution of arbitrary code with
-the privileges of the user running xpdf.
+В коде обработки встроенных шрифтов в xpdf отсутствуют достаточные проверки
+(в том числе проверки типов).  При открытии специально сформированного файла PDF
+эта уязвимость может позволить выполнить произвольный код с
+правами пользователя, запустившего xpdf.
 
 
 
-For the stable distribution (etch), these problems have been fixed in
-version 3.01-9.1+etch4.
+В стабильном выпуске (etch) эти проблемы были исправлены в
+версии 3.01-9.1+etch4.
 
-For the unstable distribution (sid), these problems have been fixed in
-version 3.02-1.2.
+В нестабильном выпуске (sid) эти проблемы были исправлены в
+версии 3.02-1.2.
 
-We recommend that you upgrade your xpdf package.
+Рекомендуется обновить пакет xpdf.
 
 
 # do not modify the following line
--- english/security/2008/dsa-1561.wml	2008-04-28 19:46:41.0 +0600
+++ russian/security/2008/dsa-1561.wml	2015-12-02 23:42:19.559013522 +0500
@@ -1,24 +1,25 @@
-programming error
+#use wml::debian::translation-check translation="1.1" maintainer="Lev Lamberov"
+ошибка программирования
 
-Christian Herzog discovered that within the Linux Terminal Server Project,
-it was possible to connect to X on any LTSP client from any host on the
-network, making client windows and keystrokes visible to that host.
-
-NOTE: most ldm installs are likely to be in a chroot environment exported
-over NFS, and will not be upgraded merely by upgrading the server itself.
-For example, on the i386 architecture, to upgrade ldm will likely require:
+Кристиан Херцог обнаружил, что в Linux Terminal Server Project можно
+подключиться к X на любом LTSP-клиенте с любого узла в
+сети, что делает клиентские окна и нажатия клавиш видимыми на этом узле.
+
+ВНИМАНИЕ: большинство установок ldm использую окружение chroot, экспортируемое
+через NFS, они не будут обновлены при простом обновлении сервера.
+Например, на архитектурах i386 для выполнения обновления 

Re: Проверка сложнойсти паролей.

[Oleksandr Gavenko]

On 2015-12-01, Oleksandr Gavenko wrote:

> Собственно я чего то подобное искал - высчитывание энтропии на овновании
> разумных допущений + там рекомендации сколько бит для каких нужд.

В общем энтропия - энтропией, но теория без практики - пустое место.

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

У меня Spring Security, в настройках md5 без соли. На известный пароль:

  $ printf PASSWROD | md5sum -

дало hex идентичный лежащему в базе.

Так вышло что одна запись была словарной и сайт:

  http://www.md5decrypter.com/

быстро выдал ответ. Но другие не вошли в список 1 часто используемых
паролей ))

Мне нужны 2 вещи - генератор слов по заданным правилам и чекер md5. Что бы не
велосипедить - поискал готовые продукты:

  http://hashcat.net/hashcat/

Оно паралельно по заданным правилам строит обфусцированые пароли и сравнивает
со списком. Подробне:

  http://hashcat.net/wiki/doku.php?id=hashcat

В итоге расколол 4 из 9 паролей, один в словаре:

  $ ./hashcat-cli64.bin -m 0 -a 1 -r ./rules/best64.rule pass.txt 
/usr/share/dict/cracklib-small

3 в классе символов цифр до 10 шт. длиной:

  $ ./hashcat-cli64.bin -m 0 -a 3 --increment -o pass.out pass.txt 
?d?d?d?d?d?d?d?d?d?d

На 4 ядрах первое с 1 MiB словарем паролй отработало за десяток секунд, второе
10 минут.

Хотя о цифрах я получил представление перебирая все символы до 6 штук длиной:

  $ ./hashcat-cli64.bin -m 0 -a 3 --increment -o pass.out pass.txt ?a?a?a?a?a?a

На процессоре выполнять эти работы глупо. Есть GPU версия:

  http://hashcat.net/oclhashcat/

Я не знаю какие еще есть нормальные утилиты востановления пароля. Вычитывал о
John the Ripper - но показалось чем то древним и заброшеным.



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

Всегда нужно использовать наиболее широкий класс символов. 10 цифр вскрываются
не успев попить чай. Аналогично 6 шт alphanum+punct.

Дефолтные 8 символов от pwgen не стойки для пасивной атаки. Для логина
пользователя - норм с временной задержкой или блокировкой после 10 неудач, но
если украдут /etc/shadow - беда. И стремно если сервис доступен онлайн для
перебора без аудита или временных блокировок.

Человеко-придуманые короткие пароли тоже зло. Я пробовал:

  $ ./hashcat-cli64.bin -m 0 -a 1 -r ./rules/best64.rule pass.txt 
/usr/share/dict/cracklib-small

(конкатенация 2 слов из словара с 64 стандартными модификациями) - программа
предположила возможное время 3 часа.

Потому пароли из 3 слов - стремные даже с "хитростями" для пасивного перебора.
xkcd#936 право на счет выбраных наугад 4 слов.

-- 
Best regards!

APT очень медленно читает списки пакетов

[Andrey Tataranovich]

Доброго времени суток.

С некоторого времени APT стал невероятно медленно читать списки пакетов

% sudo apt-get update
Reading package lists... 68%

В этот момент смотрю список процессов

% ps -t 4 f 
  PID TTY  STAT   TIME COMMAND
 1407 pts/4Ss 0:00 zsh
14902 pts/4S  0:00  \_ sudo schroot
14903 pts/4S  0:00  \_ schroot
15011 pts/4S  0:00  \_ -bash
15018 pts/4D+ 0:04  \_ apt-get install sudo

Если зацепиться strace, то вижу следущее

% sudo strace -tt -p 15018
Process 15018 attached
13:26:31.707260 read(6, "emented-in::perl, role::devel-li"..., 32362) =
32362 13:26:33.111764 read(6, "::TODO, suite::gnome, works-with"...,
32080) = 32080 13:26:33.112216 gettimeofday({1449051993, 112275}, NULL)
= 0 13:26:33.112401 write(1, "\rReading package lists... 53%\r", 30) =
30 13:26:33.114972 read(6, "ore (>> 1:3.5.4+dfsg2) | languag"...,
32421) = 32421 13:26:33.117854 read(6, "p-gu,
libreoffice-grammarcheck-g"..., 32286) = 32286 13:26:33.147820 read(6,
"ammarcheck-pt-br\nDescription: of"..., 32268) = 32268 13:26:33.150284
read(6, "misc\nPriority: extra\nFilename: p"..., 32039) = 32039
13:26:35.011315 read(6, "freedesktop, gir1.2-glib-2.0, gi"..., 32591) =
32591 13:26:35.059340 read(6, "ort\nRecommends: librsvg2-common\n"...,
32428) = 32428 13:26:35.061636 read(6, "re: i386\nDepends: perl (>=
5.14."..., 32576) = 32576 13:26:35.999087 read(6, " Files\nHomepage:
http://www.sfml;..., 32243) = 32243 13:26:35.999875
gettimeofday({1449051995, 82}, NULL) = 0 13:26:36.000230 write(1,
"\rReading package lists... 54%\r", 30) = 30 13:26:36.128400 read(6,
"0-2\nInstalled-Size: 192\nMaintain"..., 32701) = 32701 13:26:36.148923
read(6, "ple tool to use Socialtext RESTf"..., 32428) = 32428
13:26:36.176194 read(6, "tra\nFilename: pool/main/libs/lib"..., 32374)
= 32374 13:26:36.203956 read(6, "umentation for libspring-ldap-ja"...,
32477) = 32477 13:26:36.231686 read(6, "265570e806ce4cdd\nTag:
devel::lan"..., 32355) = 32355 13:26:36.259096 read(6, "Section:
perl\nPriority: optional"..., 32401) = 32401 13:26:36.261050 read(6,
"42093865fcb9bc92f6623c67e0ba8a97"..., 32076) = 32076 13:26:36.288090
read(6, "ends: perl (>= 5.14.2-12), perla"..., 32603) = 32603
13:26:37.147618 read(6, "alled-Size: 67\nMaintainer: Debia"..., 32715)
= 32715 13:26:37.148648 gettimeofday({1449051997, 148747}, NULL) = 0
13:26:37.148984 write(1, "\rReading package lists... 55%\r", 30) = 30
13:26:39.082964 read(6, "l-perl\nVersion: 1.3-1\nInstalled-"..., 32749)
= 32749 13:26:43.127996 read(6, "b7599c7d58986ff3e\n\nPackage:
libt"..., 32059) = 32059 13:26:43.147988 read(6, "ection:
perl\nPriority: optional\n"..., 32342) = 32342

Система стоит на SSD и никаких ошибок ядра или других проблем не
наблюдаю. Насколько я понял - это лечится перезагрузкой.

Что это может быть?

-- 
WBR, Andrey Tataranovich

Re: APT очень медленно читает списки пакетов

[Иван Лох]

On Wed, Dec 02, 2015 at 01:32:31PM +0300, Andrey Tataranovich wrote:
> Доброго времени суток.
> 
> С некоторого времени APT стал невероятно медленно читать списки пакетов

Есть такое. Можно вылечить переносом /var/cache/apt на tmpfs

> 

Re: APT очень медленно читает списки пакетов

[Andrey Tataranovich]

On Wed, 2 Dec 2015 13:32:31 +0300
Andrey Tataranovich  wrote:

> С некоторого времени APT стал невероятно медленно читать списки
> пакетов

http://askubuntu.com/questions/251781/reading-package-list-takes-forever

echo 3 | sudo tee /proc/sys/vm/drop_caches

Решает проблему, но я не могу понять что не так. Получается, что если
сбросить кеш и буферы, то проблема решается.

% dpkg --print-architecture 
i386

% uname -a
Linux dragoncore 3.16.0-4-686-pae #1 SMP Debian 3.16.7-ckt11-1+deb8u6
(2015-11-09) i686 GNU/Linux

% cat /proc/meminfo 
MemTotal:   16534356 kB
MemFree:14946292 kB
MemAvailable:   14890632 kB
Buffers:   25368 kB
Cached:   763860 kB
SwapCached:40080 kB
Active:   871468 kB
Inactive: 628172 kB
Active(anon): 635356 kB
Inactive(anon):   508656 kB
Active(file): 236112 kB
Inactive(file):   119516 kB
Unevictable:  48 kB
Mlocked:  60 kB
HighTotal:  15772812 kB
HighFree:   14276820 kB
LowTotal: 761544 kB
LowFree:  669472 kB
SwapTotal:   7340028 kB
SwapFree:7154136 kB
Dirty:   620 kB
Writeback: 0 kB
AnonPages:698588 kB
Mapped:   288520 kB
Shmem:433600 kB
Slab:  46292 kB
SReclaimable:  20496 kB
SUnreclaim:25796 kB
KernelStack:3608 kB
PageTables:10008 kB
NFS_Unstable:  0 kB
Bounce:0 kB
WritebackTmp:  0 kB
CommitLimit:15607204 kB
Committed_AS:3943828 kB
VmallocTotal: 122880 kB
VmallocUsed:   26736 kB
VmallocChunk:  21816 kB
HardwareCorrupted: 0 kB
AnonHugePages: 0 kB
HugePages_Total:   0
HugePages_Free:0
HugePages_Rsvd:0
HugePages_Surp:0
Hugepagesize:   2048 kB
DirectMap4k:   14328 kB
DirectMap2M:  890880 kB


-- 
WBR, Andrey Tataranovich

Re: APT очень медленно читает списки пакетов

[Andrey Tataranovich]

On Wed, 2 Dec 2015 13:42:34 +0300
Иван Лох  wrote:

> On Wed, Dec 02, 2015 at 01:32:31PM +0300, Andrey 
> > С некоторого времени APT стал невероятно медленно читать списки
> > пакетов
> 
> Есть такое. Можно вылечить переносом /var/cache/apt на tmpfs

Похоже и без tmpfs можно обойтись. Я в следующем письме писал про
костыльное решение:

echo 3 | sudo tee /proc/sys/vm/drop_caches

После сброса кеша и буферов все работает как нужно. Но мне очень
интересно, почему так получается.

-- 
WBR, Andrey Tataranovich

почему ядро не сбрасывает кэш?

[Hleb Valoshka]

Классическая ситуация: поставил кто-то себе GNU/Linux, узнал о
существовании комманды free и пишет в рассылки/форумы/irc: "а куда
делась вся свободная память?", а ему отвечают: "не парься. кэш видишь?
будет нужна память ядро само почистит кэш, и вернёт память".

А вот сегодня мне пришлось вручную сбрасывать кэш, занимавший около
60% всего объёма ОЗУ, пока этого не сделал, была загрузка процессора
ядром под 90% и в логи валились сообщения типа "[6848409.216723] java:
page allocation failure. order:1, mode:0x20
[6848409.216929] Pid: 17814, comm: java".

Там ещё прозрачные huge pages включены, но это, думаю, не столь важно.

Вопрос, почему ядро не сбрасывает кэш?

Re: APT очень медленно читает списки пакетов

[Andrey Tataranovich]

On Wed, 2 Dec 2015 14:45:35 +0300
Hleb Valoshka <375...@gmail.com> wrote:

> On 12/2/15, Andrey Tataranovich  wrote:
> > Похоже и без tmpfs можно обойтись. Я в следующем письме писал про
> > костыльное решение:
> >
> > echo 3 | sudo tee /proc/sys/vm/drop_caches
> >
> > После сброса кеша и буферов все работает как нужно. Но мне очень
> > интересно, почему так получается.
> 
> Было бы интересно увидеть вывод free перед сбросом кэша.

Посмотрю, когда в следующий раз подвиснет. Помню, что свободной памяти
в top показывалось около 12G.

-- 
WBR, Andrey Tataranovich

Re: APT очень медленно читает списки пакетов

[Andrey Melnikoff]

Andrey Tataranovich  wrote:
> On Wed, 2 Dec 2015 13:32:31 +0300
> Andrey Tataranovich  wrote:

> > С некоторого времени APT стал невероятно медленно читать списки
> > пакетов

> http://askubuntu.com/questions/251781/reading-package-list-takes-forever

> echo 3 | sudo tee /proc/sys/vm/drop_caches

> Решает проблему, но я не могу понять что не так. Получается, что если
> сбросить кеш и буферы, то проблема решается.

В районе 4.1-4.2 ядра была бага в cgroup (точнее в менджменте cgroup) давала
точно такой-же эффект. Могли забакпортить :)

Re: APT очень медленно читает списки пакетов

[Hleb Valoshka]

On 12/2/15, Andrey Tataranovich  wrote:
> Похоже и без tmpfs можно обойтись. Я в следующем письме писал про
> костыльное решение:
>
> echo 3 | sudo tee /proc/sys/vm/drop_caches
>
> После сброса кеша и буферов все работает как нужно. Но мне очень
> интересно, почему так получается.

Было бы интересно увидеть вывод free перед сбросом кэша.

какой правильный способ работать с /sys из initrd?

[Dmitry E. Oboukhov]

есть USB-хаб.

у него такая хрень, что ему надо сделать

echo 1 > /sys/bus/usb/bla/path

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

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

далее я руками делаю вышеупомянутый echo 1 > path и продолжаю
загрузку.

вопрос: а какой кошерный способ есть в initramfs сделать это
автоматически?

проблема в том что usb контроллер инициализируется сколько-то времени
и файлики в /sys/bus появляются далеко не сразу.

что лучше вкрутить? просто скрипт в initramfs или есть какой-то
конкретный механизм на эту тему?

-- 

. ''`.   Dmitry E. Oboukhov
: :’  :   email: un...@debian.org jabber://un...@uvw.ru
`. `~’  GPGKey: 1024D / F8E26537 2006-11-21
  `- 1B23 D4F8 8EC0 D902 0555  E438 AB8C 00CF F8E2 6537


signature.asc
Description: Digital signature

[DONE] wml://security/2007/dsa-1{341,266,379,375,386,296,303,419,388,384,263,411,287,412,410}.wml

[Lev Lamberov]

Cheers!
Lev Lamberov
--- english/security/2007/dsa-1263.wml	2014-04-30 13:16:12.0 +0600
+++ russian/security/2007/dsa-1263.wml	2015-12-02 17:24:12.660612923 +0500
@@ -1,33 +1,34 @@
-several vulnerabilities
+#use wml::debian::translation-check translation="1.4" maintainer="Lev Lamberov"
+несколько уязвимостей
 
-Several remote vulnerabilities have been discovered in the Clam
-anti-virus toolkit, which may lead to denial of service. The Common
-Vulnerabilities and Exposures project identifies the following problems:
+В наборе антивирусных инструментов Clam было обнаружено несколько удалённых уязвимостей,
+которые могут приводить к отказу в обслуживании. Проект Common
+Vulnerabilities and Exposures определяет следующие проблемы:
 
 
 
 https://security-tracker.debian.org/tracker/CVE-2007-0897;>CVE-2007-0897
 
-It was discovered that malformed CAB archives may exhaust file
-descriptors, which allows denial of service.
+Было обнаружено, что некорректные архивы CAB могут привести к использованию всех файловых
+дескрипторов, что приводит к отказу в обслуживании.
 
 https://security-tracker.debian.org/tracker/CVE-2007-0898;>CVE-2007-0898
 
-It was discovered that a directory traversal vulnerability in the MIME
-header parser may lead to denial of service.
+Было обнаружено, что уязвимость, проявляющаяся в обходе каталога, в коде для грамматического
+разбора заголовков MIME может приводить к отказу в обслуживании.
 
 
 
-For the stable distribution (sarge) these problems have been fixed in
-version 0.84-2.sarge.15.
+В стабильном выпуске (sarge) эти проблемы были исправлены в
+версии 0.84-2.sarge.15.
 
-For the upcoming stable distribution (etch) these problems have been fixed
-in version 0.88.7-2.
+В готовящемся стабильном выпуске (etch) эти проблемы были исправлены
+в версии 0.88.7-2.
 
-For the unstable distribution (sid) these problems have been fixed in
-version 0.90-1.
+В нестабильном выпуске (sid) эти проблемы были исправлены в
+версии 0.90-1.
 
-We recommend that you upgrade your clamav packages.
+Рекомендуется обновить пакеты clamav.
 
 
 # do not modify the following line
--- english/security/2007/dsa-1266.wml	2007-03-14 21:55:44.0 +0500
+++ russian/security/2007/dsa-1266.wml	2015-12-02 16:43:33.057054094 +0500
@@ -1,22 +1,23 @@
-several vulnerabilities
+#use wml::debian::translation-check translation="1.1" maintainer="Lev Lamberov"
+несколько уязвимостей
 
-Gerardo Richarte discovered that GnuPG, a free PGP replacement, provides
-insufficient user feedback if an OpenPGP message contains both unsigned
-and signed portions. Inserting text segments into an otherwise signed
-message could be exploited to forge the content of signed messages.
-This update prevents such attacks; the old behaviour can still be
-activated by passing the --allow-multiple-messages option.
+Жерардо Ричарте обнаружил, что GnuPG, свободная замена PGP, предоставляет
+недостаточную информацию пользователю в случае, если сообщение OpenPGP содержит и неподписанные,
+и подписанные части. Вставка текстовых фрагментов в уже подписанное
+сообщение может использоваться для подделки содержимого подписанных сообщений.
+Данное обновление предотвращает подобные атаки; старое поведение всё ещё
+может использоваться при передаче опции --allow-multiple-messages.
 
-For the stable distribution (sarge) these problems have been fixed in
-version 1.4.1-1.sarge7.
+В стабильном выпуске (sarge) эти проблемы были исправлены в
+версии 1.4.1-1.sarge7.
 
-For the upcoming stable distribution (etch) these problems have been
-fixed in version 1.4.6-2.
+В готовящемся стабильном выпуске (etch) эти проблемы были
+исправлены в версии 1.4.6-2.
 
-For the unstable distribution (sid) these problems have been fixed in
-version 1.4.6-2.
+В нестабильном выпуске (sid) эти проблемы были исправлены в
+версии 1.4.6-2.
 
-We recommend that you upgrade your gnupg packages.
+Рекомендуется обновить пакеты gnupg.
 
 
 # do not modify the following line
--- english/security/2007/dsa-1287.wml	2014-04-30 13:16:12.0 +0600
+++ russian/security/2007/dsa-1287.wml	2015-12-02 17:33:25.402859841 +0500
@@ -1,28 +1,29 @@
-multiple vulnerabilities
+#use wml::debian::translation-check translation="1.3" maintainer="Lev Lamberov"
+многочисленные уязвимости
 
-Two vulnerabilities have been identified in the version of
-ldap-account-manager shipped with Debian 3.1 (sarge).
+В версии ldap-account-manager, поставляемой в составе Debian 3.1 (sarge), было
+обнаружено две уязвимости.
 
 
 
 https://security-tracker.debian.org/tracker/CVE-2006-7191;>CVE-2006-7191
-An untrusted PATH vulnerability could allow a local attacker to execute
-arbitrary code with elevated privileges by providing a malicious rm
-executable and specifying a PATH environment variable referencing this
-executable.
+Уязвимость недоверенной переменной PATH может позволить локальному злоумышленнику выполнить
+произвольный код с повышенными привилегиями путём 

Re: почему ядро не сбрасывает кэш?

[Aleksandr Sytar]

2 декабря 2015 г., 14:23 пользователь Hleb Valoshka <375...@gmail.com>
написал:

> Классическая ситуация: поставил кто-то себе GNU/Linux, узнал о
> существовании комманды free и пишет в рассылки/форумы/irc: "а куда
> делась вся свободная память?", а ему отвечают: "не парься. кэш видишь?
> будет нужна память ядро само почистит кэш, и вернёт память".
>
> А вот сегодня мне пришлось вручную сбрасывать кэш, занимавший около
> 60% всего объёма ОЗУ, пока этого не сделал, была загрузка процессора
> ядром под 90% и в логи валились сообщения типа "[6848409.216723] java:
> page allocation failure. order:1, mode:0x20
> [6848409.216929] Pid: 17814, comm: java".
>
> Там ещё прозрачные huge pages включены, но это, думаю, не столь важно.
>
> Вопрос, почему ядро не сбрасывает кэш?
>

Все несколько сложнее чем кажется на первый взгляд, но сообщения о нехватке
памяти может быть получено когда память есть, но не та которая нужна
приложению - в данном случае java попросила 1 страницу 8к, и их не
оказалось, а вот страниц 4к, 16к и т.д. вполне могло быть в достатке.

Подробнее - Understanding The Linux Virtual Memory Manager -
https://www.kernel.org/doc/gorman/pdf/understand.pdf