fopen () не может открыть файл в / tmp share

У меня есть приложение C, которое иногда не может открыть файл, хранящийся на /tmp Поделиться.

Вот соответствующий фрагмент кода:

  // open file and start parsing

  notStdin = strcmp(inFile, "-");
  if (notStdin) {
     coordsIn = fopen(inFile, "r");   <----- inFile = file that I want to open
     if (coordsIn == NULL) {
        fprintf(stderr, "ERROR: Could not open coordinates file: %s\n\t%s\n", inFile, strerror(errno));
        exit(EXIT_FAILURE);
     }
  }
  else
     coordsIn = stdin;

После восьми-десяти попыток я получаю NULL Указатель FILE. Вот пример сообщения об ошибке:

ERROR: Could not open coordinates file: /tmp/coordinates.txt
       File or directory does not exist

Однако файл /tmp/coordinates.txt действительно существует, так как я могу открыть его стандартными утилитами, такими как head, cat или more, и т.д.

Разрешения разных /tmp/coordinates.txt пробные файлы такие же.

Вот результат uname -a:

$ uname -a
Linux hostname 2.6.18-128.2.1.el5 #1 SMP Wed Jul 8 11:54:47 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux

Если я использую другой inFile который хранится в другом, не/tmp поделитесь, то я этого симптома не наблюдаю.

Есть ли что-нибудь, что могло бы вызвать fopen() сбой в файле, хранящемся в /tmp Поделиться? Могу ли я выполнить другие действия по устранению неполадок?

Слишком много открытых файлов?
Ваша программа открывается лоты файлов? Возможно, у вас заканчиваются файловые дескрипторы? Вот ссылка о том, как изменить вашу программу, оболочку и ОС, если это так. Чтобы увидеть, как много вы используете в своей программе:

sudo lsof | grep <PID> | wc -l

В моей системе Ubuntu ограничение оболочки составляет 1024, включая stdout, stderr и stdin. Это установлено в /etc/security/limits.conf. Следующая небольшая программа показывает это:

#include <stdio.h>

int count=0;

int main( void ) {
    while(1) {
        FILE *fd = fopen("foo", "r");
        if ( fd == NULL) {
            printf("%i\n", count);
            return(1);
        }
        count++;
    }
    return(0);
}

Когда я запускаю, он печатает «1021» со статусом выхода 1.

Проверьте системные ошибки:
В более общем смысле вы всегда можете проверить вывод dmesg или / var / log / messages на наличие ошибок.

Посмотрите файл, посмотрите, не портится ли с ним что-то еще:
Возможно файл не существует, что-то его из-под вас удаляет? Вы можете захотеть используйте inotify для просмотра всех событий в файле или инструменты, использующие inotify, такие как Incron или инструменты inotify.

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

Есть ли что-нибудь постороннее по отношению к вашей программе, модифицирующей / изменяющей этот файл, или ваша программа многопоточная и работает с этим файлом? Если так, то это могло быть состояние гонки.

Чтобы проверить, так ли это, вы можете использовать inotify, как предлагает Кайл (вы, вероятно, после удаления и перемещения из событий), чтобы точно увидеть, что происходит с файлом.

В качестве альтернативы вы можете попытаться статировать файл и посмотреть, совпадают ли его ctime и / или mtimes с ошибкой fopen с ENOENT.

Может какая-то программа блокирует этот файл? Это может быть еще одна копия вашей программы.

Делает lsof /tmp/coordinates.txt показать что-нибудь?

Вим?

Просто дикая догадка. Открытый ли у вас файл /tmp/coordinates.txt в vim при возникновении этой проблемы?

У меня возникли проблемы с файлом, который я редактирую в vim, который исчез из файловой системы и вскоре снова появился. Я никогда не видел, чтобы файл отсутствовал с помощью ls, но у меня было, например, gcc терпит неудачу при попытке открыть файл только для успешной второй попытки.

Это не очень редкий артефакт, в течение дня случается регулярно.

Я не знаю, каково решение, но знаю, что я наблюдал ту же проблему, и не только в / tmp. Это может произойти при монтировании NFS и даже локальном монтировании, например / lib. Проблема, которую я обнаружил сегодня, воспроизводит это (неправильно) путем открытия, поиска, небольшого чтения и закрытия одного и того же файла тысячи раз (вместо того, чтобы просто держать файл открытым на протяжении всей операции). Иногда одна из функций fopen () завершалась ошибкой ENOENT. Открыто не так много файлов, как предположил один человек - он буквально думает, что файла нет на долю секунды.

Я искал, есть ли у кого-нибудь похожие проблемы, и это самое близкое, что я подошел. Однако у меня нет ответов, я просто ищу решение.

Я не думаю, что это характерно для Linux (или RHEL), потому что я не вижу этого везде, только в одной среде. Я не знаю, чем отличается эта среда, что может вызвать эту проблему (есть различия). Хотя неприятно видеть, что все, что есть, не исправлено в RHEL5 (я вижу это в RHEL4).