File descriptor 5 left open

strace command и смотреть что за 5й дескриптор

вместо command подставляется, например, lvdisplay?

как в выводе strace будут выглядеть упоминания этого дескриптора?

что-то в таком духе:

open("/proc/devices", O_RDONLY|O_LARGEFILE) = 5
fstat64(5, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7ff7000
read(5, "Character devices:\n 1 mem\n 4 /"..., 4096) = 448
close(5) = 0

там полно чего открывается, скорее всего нужно ошибки на open и close смотреть

как бы на него grep натравить? strace pvdisplay | grep не работает(((

какие бы ключики передать strace? судя по тексту ошибки подходит -trace=file. Но всёравно очень много выводит(((

strace -o outputfile command

Перед выполнением любой команды связанной с лвм запускается функция которая закрывает все открытые файлы, кроме stdin, stdout и stderr. Вот только почему-то не всегда это получается.

В моем случае незакрываются какие-то пайпы.

Предлагаю Вам такой эксперимент:

1. Сделайте su потом, к примеру, pvs

2. Сделайте su - потом pvs

Спорим, что во втором случае ругани не будет ;)

Пронаблюдать можно так ll /proc/PID_вашего_шелла/fd/ Файловые дескрипторы незакрывающихся файлов будут показывать на вещи где-то в родительских процессах что ли...

Вопрос в зал: как понять что такое запись вида pipe:[16202]?

0.000651 open("/proc/meminfo", O_RDONLY) = 5
0.000351 fstat(5, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
0.000135 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f9682cf3000
0.000105 read(5, "MemTotal: 1798720 kB\nMemFre"..., 1024) = 826
0.000248 close(5) = 0

больше ничего с "= 5" не находится

Как бы воспроизвести это на убунте? пароль руту прописывать не хочется. Чем грозит появление данной ошибки, как оно сказывается на работе LVM?

Нет смысла смотреть что за дескриптор - он закрывает все подряд с 0 до максимума (по лимитам).

root@big:~# ls -l /proc/8274/fd/
итого 0
lrwx------ 1 root root 64 2008-11-22 00:11 0 -> /dev/pts/0
lrwx------ 1 root root 64 2008-11-22 00:11 1 -> /dev/pts/0
lrwx------ 1 root root 64 2008-11-22 00:09 2 -> /dev/pts/0
lrwx------ 1 root root 64 2008-11-22 00:11 255 -> /dev/pts/0
lr-x------ 1 root root 64 2008-11-22 00:11 5 -> /dev/urandom

получается оно не может закрыть urnadom? с этим имеет смысл бороться?

всам деле после ещё одного sudo -s ошибка исчезла) отчего так?

>отчего так?

Мне не хватит знаний, чтобы уверено ответить на этот вопрос.

Пусть анонимусы выскажутся.

>с этим имеет смысл бороться?

Думаю нет. Он закрывает файлы из соображений безопасности (чтоб ничего на дисках не поломалось). В случае /dev/urandom это смысла не имеет.

ЗЫ Теперь Вам известно как сделать так, чтобы все закрывалось ;)

>как бы на него grep натравить? strace pvdisplay | grep не работает(((

Ну так потому что strace в stderr пишет, а в stdout искать пытаетесь.

Попробуйте strace pvdisplay 2>&1 | grep

> как понять что такое запись вида pipe:[16202]?
16202 - это не пид случайно?

ты тупее, чем кажешься

>Вопрос в зал: как понять что такое запись вида pipe:[16202]?
16202 - это номер inode в ФС pipefs

>16202 - это номер inode в ФС pipefs

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

Наврядли про это можно почитать, т.к. от этого inode пользы мало. Пробегись по fs/pipe.c, там все просто.