Как Вы уже знаете, запускаю я процесс следующей командой: ./process > somefile 2>&1 & Так вот, размер файла somefile желательно периодически сбрасывать, для чего в линуксе я обычно использую банальный "> somefile", на в HP-UX почему-то наблюдается, что размер файл сначала обнуляется, но после следующей операции записи из процесса его размер восстанавливается и продолжает расти. Думаю, что это связано с тем, что система сохраняет значение курсора в хендле открытого файла даже после ">" (lsof, кстати, подтверждает эту теорию). Как быть? Нагуглил уже кучу подобных ситуаций, но ни в одной из них не нашёл нормальных путей решения. Может, вместо > нужно >> юзать? В саппорте HP мне вообще порекомендовали заюзать какие-то ключи к ls и file, которые системой даже не поддерживаются - ересь полная.
может быть, сделать тогда обнуление размера и запись отдельными операциями? Вроде cat /dev/null > somefile ./process > somefile 2>&1 &
ну может проще на Си накатать программку которая будет сбрасывать stdout и stderr в файл и по определенному сигналу обнулять этот файл. Или использовать уже готовую программу логер. Тот же стандартный syslogd/logger например.
green Разве cat /dev/null > somefile чем-то отличается от > somefile ? Останавливать процесс нельзя. Никакие изменения вносить в его код тоже нельзя. Нашёл в гугле, что можно посылать процессу какой-то стандартный сигнал, по которому он сам обязан закрывать все открытые файлы, но не факт, что процесс правильно обработает этот сигнал, а не упадёт. Поэтому тоже отпадает. tigsid Так мне всё равно придётся перезапускать процесс, чтоб он писАл в эту программку, а не в файл напрямую. Не вариант
Странно, что перенавправление каналов не дает нужного эффекта. По идее, '>' уничтожает содержимое целевого файла, а '>>' дописывает в его конец. Но раз дело дошло до брутальностей, то можно сделать так: 1. Посылать процессу SIGUSR1/2. В обработчике этого сигнала грохать файл. 2. Переписать механизм самого sh. К счастью действий потребуется выполнить минимум: 1. Ваша программа получает имя процесса, тип перенаправления (с уничтожением/без), и имена файлов куда надо перенаправлять. 2. Процесс fork'ается. 3. Родительский процесс отправляется на тот свет. 4. Дочерний процесс, в зависимости от опций, уничтожает/открывает файл, замещая дескрипторы STDIN, STDOUT, STDERR на дескриптор открытого файла. 5. Дочерний процесс делает exec на целевой процесс. Правда, я не помню точно, могут ли возникнуть сложности с наследованием открытых дескрипторов, но, кажется, с STDIN, STDOUT, STDERR проблем нет.
Mika0x65 Как я уже сообщил выше, менять в процессе ничего нельзя, даже перезапускать его нельзя, а воздействовать извне нужно максимально осторожно. О каком sh речь? Интересует решение на уровне внешних операций с файлом, а не со стороны процесса. Кстати, раньше всё это прекрасно работало в Линуксе с помощью crontab: архивирую текущий файл, обнуляю его размер (командой >) - и все дела. А теперь система мигрировала на HP-UX и начались проблемы.
Quantum Ага, значит вариант с сигналами отпадает. Тогда вариант с sh. Речь идет о том sh, который выполняет запуск программы -- можно написать программу, которая сама выполняет перенаправление каналов, вместо sh. Ведь проблема, как я понимаю, именно в этом: операция '>' реализована sh не совсем так, как требуется. Почему бы не сделать перенаправление самому, гарантированно обнулив файл? Правда, для запуски программы с перенаправлением каналов потребуется еще одна программа, но если это не запрещено, то можно воспользоваться.
Quantum Тогда, наверно, не остаётся ничего, кроме как переоткрыть хендл изнутри процесса. Отладчиком, например.
Уже перезапустил процесс и отключил лог. Пришлось вырубить мониторинг кластера. Вроде, никто не заметил.
Quantum Раз длина обнулялась, значит тебе просто не повезло - ты затирал в момент записи. Надо было просто повторить операцию несколько раз и желательно написать Си-шный вариант для "быстроты" действий или приоритет дать задачке затирания наивысший.
valterg Попытка обрезать файл применялась неоднократно на протяжении нескольких дней Как оказалось, нужно было юзать >> вместо >, как я и предполагал в самом начале.
