Приведенная ниже установка некоторое время работает так, как ожидалось. В конце концов, хост CIFS отключается (исправления, питание и т. д.). Когда это происходит ... PHP, кажется, теряет рассудок и отказывается получить доступ к файлам в точке монтирования до перезапуска php-fpm, несмотря на то, что общий ресурс CIFS полностью доступен для ОС.
Warning: scandir(repository/Some Series/Some Title): failed to open dir: No such file or directory in /var/www/audiobooks/libraries/bookScan.php on line 169
Любые указатели на то, что мне не хватает, чтобы не требовать перезапуска php-fpm?
У меня есть следующая точка монтирования на Linux-сервере:
//10.68.x.x/Media/Audiobooks on /var/www/audiobooks/repository type cifs (rw,relatime,vers=default,cache=strict,username=xxxxxx,domain=/,uid=48,forceuid,gid=996,forcegid,addr=10.68.x.x,file_mode=0755,dir_mode=0775,soft,nounix,mapposix,rsize=1048576,wsize=1048576,echo_interval=60,actimeo=1)
Выполняется следующий код:
public function getBookFiles($book)
{
$path = $book["path"];
$files = scandir($path);
$files = array_diff($files,array('..','.'));
return $files;
}
Перезапуск PHP-FPM устраняет проблему. У ОС нет проблем с доступом к этим файлам во время простоя.
[root@audiobook audiobooks]# stat /var/www/audiobooks/repository/Some\ Series/Some\ Title/01\ Some\ Title.mp3
File: '/var/www/audiobooks/repository/Some Series/Some Title/01 Some Title.mp3'
Size: 4170169 Blocks: 8152 IO Block: 16384 regular file
Device: 77h/119d Inode: 179 Links: 1
Access: (0555/-r-xr-xr-x) Uid: ( 48/ apache) Gid: ( 996/ nginx)
Access: 2018-03-31 17:09:58.810843700 +0000
Modify: 2018-03-21 20:33:16.000000000 +0000
Change: 2018-04-01 05:58:06.448224400 +0000
Birth: -
Версия PHP:
php72-php.x86_64 7.2.4-1.el7.remi @remi-safe
php72-php-cli.x86_64 7.2.4-1.el7.remi @remi-safe
php72-php-common.x86_64 7.2.4-1.el7.remi @remi-safe
php72-php-fpm.x86_64 7.2.4-1.el7.remi @remi-safe
php72-php-json.x86_64 7.2.4-1.el7.remi @remi-safe
php72-php-mbstring.x86_64 7.2.4-1.el7.remi @remi-safe
php72-php-pdo.x86_64 7.2.4-1.el7.remi @remi-safe
php72-php-pecl-http.x86_64 3.1.1~RC1-2.el7.remi @remi-safe
php72-php-pecl-propro.x86_64 2.0.1-4.el7.remi @remi-safe
php72-php-pecl-raphf.x86_64 2.0.0-5.el7.remi @remi-safe
php72-php-pecl-zip.x86_64 1.15.2-1.el7.remi @remi-safe
php72-php-xml.x86_64 7.2.4-1.el7.remi @remi-safe
php72-runtime.x86_64 1.0-1.el7.remi @remi-safe
Есть отзывы на мой комментарий?






Попробуйте сначала проверить, существует ли каталог и доступен ли он для чтения (еще лучше оберните его каким-нибудь методом класса).
Если тест не прошел, и вы подозреваете, что это произошло из-за того, что CIFS ушел в самоволку, попробуйте выпустить clearstatcache(). Если ОС может получить доступ к общему ресурсу, это означает, что внутренние кэши SMB надежны, но это может быть не так для копии PHP, которая является общей и централизованной внутри модуля FPM.
У меня есть виртуальная машина Ubuntu 18.04, и я попытаюсь воспроизвести проблему через несколько часов.
То, что я предлагаю, - это просто возможное обходное решение для изучения. Проблема может быть здесь просто в ограничении. Перед
scandir($path);добавьтеclearstatcache(); stat($path);и посмотрите, поможет ли это. Если нет, то добавьте файл в каталог, который, как вы знаете, существует, а затем попробуйтеclearstatcache(); stat($path + "/myfile.txt");и посмотрите, изменится ли что-нибудь. Затем попробуйтеln -fs /var/www/audiobooks/repository/ /var/www/abc2и посмотрите, когда scandir не работает на/var/www/audiobooks/repository/, он все еще не работает на/var/www/abc2