Время ожидания системного вызова?

Question

Я использую системные вызовы unix для файлов gunzip и gzip. Иногда с очень большими файлами (т. Е. На вычислительном узле кластера) они прерываются, тогда как в других случаях (т. Е. На узлах входа в систему) они проходят. Есть ли какое-то мягкое ограничение на время, которое может занять системный вызов? Что еще это может быть?

Answer 1

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

Что означает возвращаемое значение?

Answer 2

Звучит так, как будто я сталкиваюсь с той же периодически возникающей проблемой, указывающей на тайм-аут какого-то типа Мой сценарий запускается каждый день. Я начинаю верить, что у GZIP есть тайм-аут.

1. gzip -vd filename.txt.gz 2 >> tmp / errorcatch.txt 1 >> logfile.log
2. stderr: ошибка для filename.txt.gz
3. Переходит к следующей команде 'cp filename * new / directory /', в результате чего в новом каталоге
4. stdout из более раннего gzip, показывающий успешное распаковывание того же файла: filename.txt.gz: 95,7% - заменено на filename.txt
5. Успешный файл из gzip отсутствует в исходном или новом каталоге.
6. После предупреждений ручной запуск gzip -vd filename.txt.gz никогда не завершается неудачей.

подробности:

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

Я просто поработаю над этим с помощью логики повторов и общих улучшений сценариев, но я хочу, чтобы следующий гуглер знал, что они не сумасшедшие. Это происходит с другими людьми!

Answer 3

Если это система Linux, я бы порекомендовал использовать strace , чтобы увидеть, что происходит и какие блоки системного вызова.

Вы можете даже присоединить strace к уже запущенным процессам: # strace -p $PID

Answer 4

Я использую системные вызовы Unix () файлы gunzip и gzip.

Вероятно, глупый вопрос: почему бы не использовать zlib непосредственно из вашего приложения?

И system () не является системным вызовом. Это обёртка для fork () / exec () / wait (). Проверьте справочную страницу системы (). Если он не разблокируется, возможно, ваше приложение каким-то образом мешает wait () - например, у вас есть обработчик SIGCHLD?

Answer 5

Почти наверняка проблема не в использовании system (), а в выполняемой вами операции.Всегда проверяйте возвращаемое значение, но, тем более, вы захотите увидеть вывод команды, которую вы вызываете.Для неинтерактивного использования часто лучше написать stdout и stderr для файлов журнала.Один из способов сделать это - написать скрипт-обертку, который проверяет основную команду, регистрирует командную строку, перенаправляет stdout и stderr (и закрывает stdin, если вы хотите быть осторожным), а затем запускает командную строку.Запустите это через system (), а не через команду OS напрямую.

Могу поспорить, что на сбойных машинах ограничено дисковое пространство или отсутствуют целевой файл или команды gzip / gunzip.