# Поведение системы в условиях нехватки ресурсов

## fank

Привет, коллеги!

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

Требовалось обновление ntp и dev-lang/php на ВМ на базе vmware server с выделенным объемом ОЗУ 256 Мб, своп 1Гб.

```
# ulimit -a

core file size          (blocks, -c) 0

data seg size           (kbytes, -d) unlimited

scheduling priority             (-e) 0

file size               (blocks, -f) unlimited

pending signals                 (-i) 2048

max locked memory       (kbytes, -l) 32

max memory size         (kbytes, -m) unlimited

open files                      (-n) 1024

pipe size            (512 bytes, -p) 8

POSIX message queues     (bytes, -q) 819200

real-time priority              (-r) 0

stack size              (kbytes, -s) 8192

cpu time               (seconds, -t) unlimited

max user processes              (-u) 2048

virtual memory          (kbytes, -v) unlimited

file locks                      (-x) unlimited

```

Как видно, все значения стандартные для свежеустановленной gentoo (это предположение).

На ВМ установлен профиль hardened. При попытке сборки ntp (а далее и gcc) я получал ошибки такого содержания

```
grsec: From 111.222.333.1: denied resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 for /bin/bash[sh:3092] uid/euid:0/0 gid/egid:0/0, parent /usr/bin/gmake[make:3082] uid/euid:0/0 gid/egid:0/0
```

в одних случаях приходилось 

```
ulimit -c 16384
```

в других еще и 

```
ulimit -n 8192
```

значения были подобраны эмпирически...

Отсюда естественный вопрос - почему требуется увеличивать лимиты, а в некоторых случая на ВМ с одинаковыми параметрами и практически одинаковой нагрузкой еще и увеличивать open files?

----------

