Мои сеансы PHP на моем веб-сервере Debian с использованием Apache2 с mod_php кажутся случайными ошибками, говоря, что нет места для их записи:
sudo tail -60 /var/log/apache2/error.log
[Fri Jan 30 15:55:35 2015] [error] [client xxx.xxx.xxx.xxx] PHP Warning: session_start() [<a href='function.session-start'>function.session-start</a>]: open(/tmp/sess_555555555555555555, O_RDWR) failed: No space left on device (28) in /path/to-first-session-use/core/bootstrap.php on line 18
Когда я пытаюсь:
ls /tmp
Просто висит вечно, так что это плохо.
Но когда я проверяю свободное место и проверяю, что использование inode разумно ...
$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 150G 121G 22G 85% /
tmpfs 2.0G 0 2.0G 0% /lib/init/rw
udev 10M 16K 10M 1% /dev
tmpfs 2.0G 4.0K 2.0G 1% /dev/shm
$ df -i
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/sda1 19922944 11143605 8779339 56% /
tmpfs 513524 4 513520 1% /lib/init/rw
udev 513524 135 513389 1% /dev
tmpfs 513524 3 513521 1% /dev/shm
Цифры кажутся хорошими. Конечно, 85% - это больше, чем мне хотелось бы, но это не 99% или что-то в этом роде.
Я подозревал, что это проблема из-за того, что компьютер не перезагружался в течение 5 лет и, возможно, было создано много небольших файлов, но информация об индексах, которую я получаю, как бы противоречит этому. Где мне вместо этого исследовать?
Редактировать:
ls -l /
drwxrwxrwt 4 root root 692M Feb 1 11:09 tmp/
drwxr-xr-x 10 root root 4.0K Jan 1 2013 usr/
drwxr-xr-x 14 root root 4.0K Oct 7 2010 var/
...etc
Может быть, /tmp/ сам каталог заполнен устаревшими сеансами PHP, которые не очищаются; это означает, что источник проблем может быть изолирован от /tmp/ сам каталог. Если это так, я бы просто удалил все /tmp/sess_* файлы. Сначала перечислите все sess_* такие файлы:
ls -la /tmp/sess_*
Или вы можете рассчитывать с wc как это:
ls -la /tmp/sess_* | wc -l
Теперь, когда вы получите какое-то подтверждение, что там какое-то безумное количество файлов, запустите эту команду, чтобы удалить /tmp/sess_* файлы:
sudo rm -rf /tmp/sess_*
И эфемерные файлы сеансов будут унесены ветром.
Но еще один грубый способ - но относительно безопасный - способ справиться с этим - сдуть /tmp каталог, воссоздайте /tmp каталог и перезагрузите сервер.
Поскольку /tmp Каталог - это, по сути, ручка для кодирования кэшированного материала, в нем нет ничего действительного. Поэтому мой лучший совет - запустить следующую команду, чтобы удалить и перестроить /tmp каталог.
rm -rf /tmp && mkdir /tmp/ && chown root:root /tmp && chmod 1777 /tmp
Теперь, когда один лайнер представляет собой список команд оболочки, соединенных && что сначала удалит /tmp, воссоздать /tmp, смените владельца /tmp вернуться к root:root а затем установите соответствующие разрешения для /tmp каталог. Если вы хотите, вы можете запускать каждую команду по очереди, если вы чувствуете себя безопаснее.
sudo rm -rf /tmp
sudo mkdir /tmp
sudo chown root:root /tmp
sudo chmod 1777 /tmp
Как только это будет сделано, я бы рекомендовал перезагрузить сервер. Все должно быть спокойно, снова прояснено.
Иногда поврежденная файловая система может вызывать подобные эффекты - например, когда поврежден каталог / tmp. Или - когда файлов слишком много.
Для «быстрого» исправления:
mv /tmp /tmp.xxx
mkdir /tmp
chmod a+rwxt /tmp
Если это поможет - попробуйте перезагрузить систему и корневую файловую систему fsck. Если все в порядке - просто удалите каталог /tmp.xxx.
Другая возможность - когда / tmp является «другим» разделом или tmpfs (видно на vservers Linux), но он не отображается df (потому что df получает список разделов из файла / etc / mtab, что иногда неверно). Попробуйте проверить место на диске прямо в tmp командой:
df /tmp
df -i /tmp
Другой вариант, который обычно помогает в сессиях - это использование другого сессионного механизма. Если у вас много временных сессий, которые не должны быть очень постоянными, я бы порекомендовал использовать memcache для хранения сессий. Настроить его очень просто - вы должны установить php-memcache, memcached, а затем в php.conf настроить:
session.save_handler = memcache
session.save_path="tcp://server:port?persistent=1&weight=1&timeout=1&retry_interval=15"
Затем - сессии будут храниться в кэше памяти до определенного размера. над ним - старые будут автоматически удалены.
Для меня изменение fs.inotify.max_user_watches помогло.
root@grostruc:/# service ssh restart
Error: No space left on device
root@grostruc:/# sysctl fs.inotify.max_user_watches
fs.inotify.max_user_watches = 65536
root@grostruc:/# sysctl fs.inotify.max_user_watches=262144
fs.inotify.max_user_watches = 262144
root@grostruc:/# service ssh restart
Исправить измененное значение в /etc/sysctl.conf