Переехал на новый хостинг и понеслась. Все, что до сих пор работало как часы - повалилось. Больше всего раздражает неработоспособность сессий. Не могу добиться от скриптов выполнения задач более чем смена языка страницы. Как только запускаются скрипты с перезагрузкой страницы и передачей сессии - сессия слетает. Такое впечатление, что Пых-Пых просто не знает: где хранятся сессии. Попробовал принудительно загнать по адресу из phpinfo() и сессии тут же зависли - ни выйти, ни значения изменить. Хуже всего, что не работают комманды типа session_save_path() и session_set_cookies(). Что это может быть? Никогда ранее с таким не сталкивался, хотя уже живу на четвертом хостинге. Панель управления ISP, хостинг PHP + Mysql стандартный.

Что значит "session_save_path()"? А как тогда пытался "загнать по адресу из phpinfo()"?

Туда-то сессии отправились (хотя я проверить не могу а эти хостеры ничего толком сказать не могут). Речь идет о записи сессии в мою папку (в данном случае ./cache (777)).

Почему проверить не можешь? 
Открываешь файл phpsess*идентификатор* в указанной папке.

А кто меня в ту папку допустил? Она ведь выше моего аккаунта. Там же стоит путь  |/home/urr/data/mod-tmp| no value | а такой папки у меня вообще нет. И разве могут эти два значения различаться? Обычно стоит | /tmp | /tmp | в путях сессий 

Это сообщение отредактировал(а) VotVam - 7.8.2009, 19:27

Какая разница? К чему все эти теоретические рассуждения? Ты попробовал или нет?
Вообще, я теперь хостера понимаю. С таким описанием проблемы и с таким представлением о работе сессий.

"Пустить" туда обязаны. Как бы в этом суть сессий и состоит - "пускать" скрипт к своим файлам сессий. Если проверили у нас есть доказательства, что не пустили - то предъявляем их хостеру. Но если бы не пускало, то тогда бы была ошибка "failed to write" или как-то так.
Значит, пускают. Значит, проблема, скорее в скриптах. Не удивлюсь, если это банальное register_globals.
Но в любом случае, без диагностики, без выявления причин, без тестового скрипта ответ получить невозможно ни от суппорта, ни здесь.

 Пробовал попасть в папку /home/urr/data/mod-tmp ? Такой папки у меня в аккаунте не существует. Я в понедельник попробую их заставить выставить пути до сессий /tmp|/tmp, потому что лажа какая-то с путями по-мому. У меня до этого скрипты работали по session_name() элементарно. Вообще никаких путей для сессий не указывал. А некоторые файлы спокойно работали вообще по простому session_start() и никаких проблем. Единственное, в редких случаях садил сессии в куки. Скрипты нормально работали на двух хостингах минимум.

P.S. Нашел эту папку - прав доступа в нее у меня нет и лежит она выше моего аккаунта

Это сообщение отредактировал(а) VotVam - 7.8.2009, 20:26

Не понимаю этого упрямого "у меня в аккаунте не существует" А /tmp в аккаунте существует? Она же ведь тоже выше. То есть, дело совсем не в "высоте" и не в "принадлежности к аккаунту".
Откуда такая уверенность в том, что проблема именно в путях? Где test case, показывающий проблему с путями? Где тестовый скрипт?
Вы не программист, вы просто пользователь готовых скриптов?

 У меня никогда не было проблем с сессиями - ни на локали, ни на хостинге, поэтому я не вдавался в проблему их хранения на сервере. К тому же до переноса файлов все работало и мне стоило больших усилий догадаться, что скрипты перестали работать именно из-за сессий, потому что ошибки у хостера тоже не отдаются! Как я могу получить ошибку, если error_reporting() молчит? Попытался вывести сессии для отладки в свою папку ./cache, которая в корне моего аккаунта - СЕССИИ НЕ ЗАПИСЫВАЮТСЯ! В куки ТОЖЕ НЕ ПИШУТСЯ! Так как программисту определить: где ошибка? Позвать Хоттабыча?

Нет, никого звать не надо. Все можно (и нужно) посмотреть самостоятельно.
Директива error_reporting() и не должна ничего говорить. Она отвечает за тип показываемой ошибки, а не за ее показ. 
Если сообщения об ошибках не выводятся в браузер, то они пишутся в лог. По умолчанию - error_log сайта. 
Так же можно включить показ ошибок в браузер, директивой display_errors, в .htccess или в скрипте через ini_set()
И не нужно ни о чем "усиленно догадываться" - все проблемы будут расписаны на экране.

А можно полюбопытствовать, работа с сессиями ведется через session_register?

А при чем тут PHP для профи?
Переношу в хостинг.

Сессии включаю через session_start() как учили, а далее $_SESSION[''][] = ... Я ж говорю, что вопрос сессий у меня снялся году так в 2004-м и до настоящего времени не возникал. В логи у них тоже ничего не пишется! В них только стандартные отписки типа там нет файла роботс.текст и т.д. Про дисплей эррорс - я ее и имел в виду, просто ошибся здесь - не в скрипте.

Тестовый скрипт работает? Идентификатор во время его работы передается тот же самый, или меняется?

!  MoLeX

Перенесено в Администрирование Web серверов и Web служб

Я не могу проверить работу скриптов и идентификаторы. В общем, я покопался - дело так обстоит. Часть сессий каким-то образом оказывается в папке bin-tmp, но там только с части поддоменов. А папка mod-tmp, которая записана в phpinfo(), недоступна для чтения. Сегодня постараюсь добиться от них нормального расклада по сессиям, а потом уже буду все проверять. Хотя мне все равно непонятно: почему не работает session_save_path() и session_set_cookie()