а из признаков зависания тока отсутствие пинга? или все таки локально он тоже в подвисшем состоянии?? в одно и тоже время виснет? графики какиенить по нему есть?

Прогони memtest, возможно есть проблемы с памятью, следи за /var/log/messages

Плюсую предыдущего товарища. А еще проверь кондеры на материнке и термопасту, возможно проблема все же железная. Виснет РОВНО через сутки? Или примерно?

Грубо говоря. Вчера повис в 11 часов. перезагрузил. откатил обнову.накатил ядрышко 35. на котором уж точно все было нормально. где то в 11.30 ребут. Сегодня виснет в 11.30 Ровно через 24 часа после последнего ребута

Конфигурация случаем не intel+Core2D?

Т.к. пока нет конкретики, то главное установить четко закономерньі ли зависания (точно ли сутки и в какое время суток обічно происходят зависания) + нужньі логи, а вообще:

1) memtest, как уже советовали - память наиболее частая причина "чудес" - долго, но стоит глянуть;
2) диски случаем не WD "green" (ну или подобньіе) которіе пьітаются засьіпать, не всегда корректно предупреждая об єтом систему - об єтом только читал + у друга бьіла подобная ситуация - поменяли винтьі - все ок;
3) еще по винтам - посмотреть что в смарте;
4) проверить suspend\hibernate - у меня не давно на одном из серверов, работающих более 3-ех лет нормально, но после профилактической ежегодной чистки сервера... начались чудеса, а оказалось, что подохла батарейка на мамке и настройки стали по-умолчанию;
5) обновить bios.

Связь со временньіми критериями возникновения проблемьі (не привязанньіми к какой-либо конкретной части суток), равньіми 24-ем часам, у меня вьізьівают ассоциации только с кроном и диагностикой смарт... Ждем-с деталей :-) интересно все-таки, что же там.

cron.daily не единственное место, в котором могут быть ежедневные задания. Нужно посмотреть обычный /etc/crontab.

Может чтобы не гадать с CRON надо проверить дистрибозависимость? Оставить работать ПК даже в том же BIOS ну или для полноты картины работать под LiveCD каким-нибудь...

Тоже появилась такая проблема, правда на ноутбуке домашнем.
Там периодически (не замерял когда) возникает зависание всей системы. Весь GUI просто замерзает и помогает лишь перезагрузка через другую консоль.
тоже Arch Linux, который постоянно обновляю
Поначалу подумал, что какие-то кривые обновления и ждал исправлений.
Жду очередных зависаний

Имею те же зависания на ноуте acer aspire 5112wlmi, дистры - Linux Mint Debian, Crunchbang, Ubintu 10.04

подключенный монитор показал панику ядра. Произошло ровно на 24 час аптайма.

а что говорит dmesg до этого? И var/log/messages? У меня были похожие проблемы, только там помоему было 48 часов, но тоже стабильно, как часы в kernel panic. Кернел до этого ругался что-то про via-raid. Не было времени долго исать, переключил винт на другой контроллер и с тех пор 502 дня uptime...

Насколько я понял, 24 часа проходит с момента запуска системы, а не по часам в 23:00 - значит, крон и не может быть.

ИМХО, срабатывает какой-то процесс, запущенный с системой и что-то делает.

Из любопытства: проверить, что происходит, если запустить систему, перевести часы на 23:55 вперёд - умрёт через пять минут или куда (степень "умности" процесса + если метод срабатывает - можно тестировать успешно)

Просмотреть все сервисы, отключить, оставить только критичные сервисы

Только что в голову пришло, не знаю, как сработает: незадолго перед концом пооткывать с другой машины ssh-сесси, в них позапускать какой-нибудь вывод, который при смерти "зафризится". Например:
$ top, watch -n 0.1 # наиболее активные процессы в момент смерти
$ ps aux OT | tail -n 20 # последние 20 запущенных процессов


Кернел паники всё-таки обычно от железа. Просто какой-то софт пытается сделать что-то с железом.

Появилось просто вдруг или всё-таки после обновления какого-нибудь?

$ top # наиболее активные процессы в момент смерти
$ watch "ps aux OT | tail -n 20" # последние 20 запущенных процессов

неправильно строки разбил. также извиняюсь за опечатки - спешу

А что при панике пишет? Там должен быть стек вызовов, он достаточно точно позволяет определить в чем проблема.