Вот планировал закончить год красиво, провиженом, но пока откладывается, до выяснения следующего странного поведения железки. Стоит далеко далеко железка, физического доступа к ней у меня нет, инет через проксю 9кбпс, астериск тихонько работал никого не трогал, и вот 12 дней дому, он повис наглухо в 3:03, даже локально не отзывается. корки нет, все бы ничего, но ситуация повторилась опять в 3:03. и опять наглухо. smbusа нет(таз еще прошлого тысячелетия) мониторинг напряжения на +12 показывает 15В(chm -I). Явно не случайность, тем более что дейли скрипты стартуют в 3:01, перенес их на утро, и отключил что не использую, в результате решил написать, о periodic.conf.
Буду использовать копипасту, о чем сразу предупреждаю, со своими замечаниями.
Система periodic ежедневно, еженедельно и ежемесячно поставляет информацию обо всех важных(тут конечно есть вопросы) событиях, происходящих в операционной системе.
Кусочек /etc/crontab


1 3 * * * root periodic daily
15 4 * * 6 root periodic weekly
30 5 1 * * root periodic monthly


Все параметры по умолчанию находятся в /etc/default/periodic.conf, чтобы их переопределить используются файлы /etc/periodic.conf, /etc/periodic.conf.local (не пугайтесь, изначально их не существует). Periodic скрипты не из базовой комплектации кладем сюда: /usr/local/etc/periodic
Все параметры конкретного скрипта можно почитать в [2].

Теперь пройдемся по daily параметрам
daily_output=”root” # кому пишем письма, или в какой файл писать
daily_show_success=”YES” # scripts returning 0
daily_show_info=”YES” # scripts returning 1
daily_show_badconfig=”NO” # scripts returning 2

100.clean-disks
Этот скрипт удаляет все файлы, имена которых соответствуют заданным шаблонам (по умолчанию это [#,]*, .#*, a.out, *.core, *.CKP и .emacs_[0-9]*) и возраст которых больше заданного в параметре daily_clean_disk_days числа дней. По умолчанию не выполняется.

110.clean-tmps
Удаляет все «временные» файлы (по умолчанию из /tmp, задаётся переменной daily_clean_tmps_dirs), старше указанного возраста (daily_clean_tmps_days), кроме соответствующих шаблонам, указанным в daily_clean_tmps_ignore. По умолчанию не выполняется, но если используемое вами ПО часто «забывает» подчищать за собой временный каталог, то имеет смысл включить выполнение этого файла, установив в /etc/periodic.conf переменную daily_clean_tmps_enable в YES.

120.clean-preserve
Удаляет старые файлы из /var/preserve, куда редактор vi в давние времена сохранял служебные файлы при аварийном завершении работы (например, при разрыве соединения) для последующего восстановления. По умолчанию выполняется, что несколько странно, так как «бэкапные» файлы vi уже давненько пишет в /var/tmp/vi.recovery, а изменить каталог /var/preserve, кроме как прямым редактированием сценария, нельзя. Рекомендую этот скрипт отключить.

130.clean-msgs
Очищает устаревшие msgs-сообщения (см. man msgs). Утилита msgs позволяет пользователям системы оставлять короткие сообщения всем остальным пользователям и читать такие сообщения. То есть играет роль доски объявлений. По умолчанию выполняется, но если вы не используете механизм msgs-сообщений, то нет смысла каждую ночь впустую вызывать скрипт, так что установите daily_clean_msgs_enable в NO.

140.clean-rwho
Очищает каталог /var/rwho – в нём накапливается информация, собираемая демоном rwhod. Этот демон собирает рассылаемую другими машинами UNIX-сети информацию, аналогичную той, которую возвращает команда who (аптайм, средняя загрузка, список подключенных пользователей). По умолчанию выполняется, но, поскольку такие доверительные отношения между машинами сети сейчас редко встречаются, скорее всего, смысла в этом сценарии на большинстве систем нет.

150.clean-hoststat
Sendmail в процессе своей работы может собирать статистику доступности хостов, чтобы не тратить время на попытки соединиться с теми, которые недавно были недоступны. Эта статистика со временем устаревает и начинает впустую расходовать память и место на диске. Задача скрипта заключается в вызове утилиты purgestat, которая очищает устаревшие данные. По умолчанию выполняется, но если вы не используете Sendmail, то в запуске этого скрипта не будет особого смысла.

200.backup-passwd
Копирует в /var/backups файлы master.passwd и group из каталога /etc. С одной стороны, такое копирование создаёт дополнительную «точку ответственности» для администратора, но с другой – позволяет восстановить случайно испорченные файлы, являющиеся жизненно важными для работы системы. По умолчанию выполняется.

210.backup-aliases
Ещё один пример копирования важных файлов. На этот раз в /var/backups будет сохраняться /etc/mail/aliases. По умолчанию выполняется.

220.backup-pkgdb
Бекапит базу установленного софта /var/db/pkg

300.calendar
Запускает утилиту calendar с ключом -a, которая обрабатывает файлы «календарей» всех пользователей и отсылает им по электронной почте сегодняшние и завтрашние задачи. По умолчанию не выполняется, и разработчики планируют удалить эту функцию из periodic, предлагая при необходимости использовать задания cron непосредственно.

310.accounting
Выполняет ротацию acct-файлов в /var/account. Учёт процессов (см. man acct(2)) позволяет сохранять в файл статистику всех запускавшихся процессов, такую как число вызовов процесса, израсходованное им процессорное время, среднее число операций ввода-вывода и т.п. По умолчанию выполняется, но, учитывая, что сбор подобной статистики на «боевых» серверах выполняется не часто, над необходимостью выполнения этого сценария стоит задуматься.

330.news
Когда-то предназначался для запуска сценария /etc/news.expire сервера новостей. В базовой системе я уже давно news-сервера не наблюдаю, тем не менее по умолчанию этот сценарий выполняется (если в /etc/periodic.conf выставить daily_show_badconfig в YES, то ежедневно вы будете получать сообщение об отсутствии файла /etc/news.expire; по умолчанию сообщения об ошибках не отсылаются). Однозначно нужно отключать (задав конфигурационной переменной daily_news_expire_enable значение NO).

400.status-disks
Этот сценарий выводит информацию о состоянии локальных файловых систем (выполняя команду «df -l -h») и о последних дампах. Очень полезно для контроля за свободным пространством на дисках. Кроме того, позволяет обнаружить «лишние» файловые системы (скажем, забытую флешку или диск с резервной копией). По умолчанию выполняется.

404.status-zfs
Выводит информацию о состоянии пулов ZFS. По умолчанию не выполняется, но если вы используете ZFS, то имеет смысл выставить в /etc/periodic.conf параметр daily_status_zfs_enable в значение YES.

405.status-ata-raid
Возвращает данные о статусе RAID-контроллеров (по результатам вывода утилиты atacontrol). По умолчанию не выполняется.

406.status-gmirror, 407.status-graid3, 408.status-gstripe, 409.status-gconcat
Эти скрипты выводят информацию о состоянии соответствующих дисковых массивов, управляемых подсистемой GEOM. По умолчанию не выполняются.

420.status-network
Выводит результат работы команды «netstat -i», позволяя контролировать состояние интерфейсов на момент выполнения скрипта (интерфейсы, находящиеся в состоянии down, будут отмечены звёздочкой «*»), а также число переданных и принятых пакетов, в том числе ошибочных. По умолчанию выполняется.

430.status-rwho
Выводит информацию о времени непрерывной работы (uptime) машин UNIX-сети, которую собирает rwhod. По умолчанию выполняется, но по тем же причинам, о которых шла речь при обсуждении сценария 140.clean-rwho, на большинстве систем он фактически не нужен.

440.status-mailq
Скрипт выполняет команду mailq, возвращающую информацию о почтовой очереди. Выставив переменную daily_status_mailq_shorten в YES, вы будете получать сводную статистику вместо информации по каждому сообщению в очереди. По умолчанию выполняется.

450.status-security
Это своего рода «мета-скрипт» для запуска заданий из /etc/periodic/security. Как вы видели, в заданиях cron присутствуют вызовы только для daily, weekly и monthly, поскольку проверка безопасности предполагается как ежедневное задание. Можно было бы все security-сценарии разместить и непосредственно в daily, но разработчики приняли решение, что для такой ответственной задачи лучше выделить отдельный каталог. Вы тоже вполне можете использовать этот приём для выполнения «пакетных» задач.

460.status-mail-rejects
Этот сценарий выполняет анализ почтового лог-файла (/var/log/maillog) и выводит статистику по отклонённым письмам (с указанием причины). Вывод группируется по хостам-отправителям и сортируется в порядке убывания числа отклонённых соединений. Параметр daily_status_mail_rejects_logs задаёт число «архивных» файлов, полученных в ходе ротации (maillog.0.bz2 и т.д.), которые также будут обрабатываться. Если ротация почтовых логов в вашей системе выполняется ежедневно, имеет смысл выставить данный параметр в 0 (по умолчанию используется значение 3), чтобы не обрабатывать одни и те же данные несколько раз. Если вы используете другую политику ротации (например, по достижении определённого размера файла), подберите число обрабатываемых файлов таким образом, чтобы полностью охватить все логи, накапливаемые за сутки (если, конечно, для вас достоверность информации представляет какую-то ценность). По умолчанию выполняется.

470.status-named
Выбирает из файлов /var/log/messages записи процесса named, сообщающие о той или иной ошибке (failed, REFISED), а также о пересылках зон (transfer). По умолчанию выполняется.

480.status-ntpd
Выводит список известных NTP-серверу соседей (peer). По умолчанию не выполняется, но если стабильная работа системы времени для вас важна, можете включить эту проверку.

490.status-pkg-changes
Показывает изменения в пакетах.

500.queuerun
Запускает обработку почтовой очереди (командой «sendmail -q»). По умолчанию выполняется, но подумайте о его отключении, если используете другой почтовый сервер.

Недельные задачи носят в основном сервисный характер:

310.locate
Проводит обновление базы locate (утилитой /usr/libexec/locate.update). База позволяет выполнять быстрый поиск файлов в системе, не прибегая каждый раз к глобальному просмотру всех каталогов. Периодическое обновление необходимо, чтобы поддерживать базу в актуальном состоянии. По умолчанию выполняется, но если возможности locate вам не требуются или создаваемая утилитой locate.update нагрузка на файловую систему нежелательна даже раз в неделю, запуск этого сценария можно отключить.

320.whatis
Аналогично предыдущему сценарию, этот скрипт поддерживает в актуальном состоянии базу whatis (которая осуществляет контекстный поиск по содержимому man-страниц). По умолчанию выполняется, однако если состав man-страниц меняется редко (что верно для большинства рабочих серверов), то имеет смысл вызов скрипта отключить, а обновление базы whatis выполнять по мере необходимости вручную.

330.catman
Выполняет переформатирование man-страниц (командой catman). По умолчанию не выполняется, и на большинстве систем необходимости в нём не возникает.

340.noid
Ищет файлы и каталоги, не принадлежащие ни одному из пользователей и групп. По умолчанию не выполняется, хотя в некоторых случаях (особенно при обновлении ОС до другой версии) может быть полезным для поиска «осиротевших» файлов.

400.status-pkg
Выводит список установленных пакетов, требующих обновления. По умолчанию не выполняется. Однако, если ваша система настроена на автоматическое обновление коллекции портов (например, по cron с помощью portsnap), то данная информация может быть полезна – установите в /etc/periodic.conf переменную weekly_status_pgk_enable в YES.

Ежемесячно в текущих версиях FreeBSD исполняется только один сценарий:

200.accounting
Он собирает статистику по использованию пользователями процессорного времени. По умолчанию выполняется, но на большинстве серверов особой необходимости в этом нет. Разве только в порядке соц. соревнования – кто из администраторов сильнее нагружает систему?

И, наконец, наиболее важный каталог – security (все сценарии по умолчанию выполняются, так что я не буду указывать это отдельно):

100.chksetuid
Скрипт проверяет изменения в составе файлов, для которых установлен бит suid или sgid. Поиск выполняется утилитой find по всем файловым системам, кроме смонтированных с опцией nosuid или noexec, результат сравнивается с предыдущим значением (обычно сохраняется в /var/log/setuid.today). Обнаруженные отличия отправляются администратору. И хотя такой поиск довольно сильно может нагружать файловую подсистему, лучше от него не отказываться. Впрочем, если вы ведёте аудит безопасности другими средствами, проверку можно отключить.

110.neggrpperm
Checking negative group permissions

200.chkmounts
Сравнивает текущий список смонтированных систем (возвращаемый командой «mount -p») со вчерашним списком, сохранённым в /var/log/mount.today.

300.chkuid0
Проверяет наличие в master.passwd пользователей с идентификатором 0, отличных от root и toor. Поскольку права суперпользователя определяются именно нулевым значением UID, а не символьным именем, такая проверка позволяет выявить опасные опечатки (или «чёрный ход», оставленный взломщиком или предыдущим администратором).

400.passwdless
Ищет пользователей с пустыми паролями.

410.logincheck
Проверяет права на файл login.conf (должен принадлежать пользователю root и группе wheel).

460.chkportsum
Проверяет порты с битыми контрольными суммами

500.ipfwdenied, 510.ipfdenied, 520.pfdenied
Эти три скрипта выводят информацию о запрещающих правилах пакетных фильтров (соответственно ipfw, ipf и pf), изменившихся с момента предыдущей проверки.

550.ipfwlimit
Выводит список правил ipfw, по которым были превышены заданные лимиты.

610.ipf6denied
Показывает статистику запрещенных пакетов через ipf6

700.kernelmsg
Отображает изменения вывода dmesg, произошедшие с момента последней проверки. Например, если за предыдущие сутки к серверу подключалась флешка.

800.loginfail
Выводит информацию обо всех ошибках входа в систему, зафиксированных в /var/log/auth.log за прошедшие сутки.

900.tcpwrap
Возвращает предупреждения системы TCP Wrappers, найденные в файлах /var/log/messages.

Помимо рассмотренных сценариев в каталогах daily, weekly и monthly вы найдёте файлы 999.local. Их назначение – запуск скриптов /etc/daily.local, /etc/weekly.local и /etc/monthly.local соответственно. По умолчанию эти скрипты отсутствуют, но если хотите запускать свои команды вместе с другими periodic-задачами, вы можете их создать.

немного подправил дейли и получил вот это, посмотрим на поведение системы:

daily_output="/var/log/daily.log"
weekly_output="/var/log/weekly.log"
monthly_output="/var/log/monthly.log"
daily_status_security_output="/var/log/sec_log.log"
daily_show_badconfig="YES"
daily_clean_preserve_enable="NO"
daily_clean_msgs_enable="NO"
daily_clean_rwho_enable="NO"
daily_backup_pkgdb_enable="NO"
daily_accounting_enable="NO"
daily_news_expire_enable="NO"
daily_status_network_enable="NO"
daily_status_rwho_enable="NO"
daily_status_mailq_enable="NO"
daily_status_mail_rejects_enable="NO"
daily_status_named_enable="NO"
daily_queuerun_enable="NO"

Литература:
1. http://www.samag.ru/archive/article/2055
2. /etc/default/periodic.conf
3. Немного гугла)

З.Ы. Раз уж вспомнил о проксе то в csh она прописывается вот так:
для csh, или пишем в файл(/home/user/.cshrc) или применяем для сеанса, по вкусу
setenv HTTP_PROXY http://ip:port
setenv FTP_PROXY http://ip:port
Или через /etc/make.conf

FETCH_ENV=FTP_PROXY="http://user:pass@address:port/"
FETCH_ENV=HTTP_PROXY="http://user:pass@address:port/"


Советы, замечания, предложения, как всегда приветствуются.