Как автоматически перезапустить службу / демон Opensolaris/OmniOS, который регистрирует уведомления, но не критические ошибки в системном журнале?

Следующая проблема может рассматриваться как проблема, связанная с CIFS/AD (конкретное представление) или как вопрос о перезапусках службы, обработке ошибок и разборе журнала (общий вид). Я представлю обе области здесь, но был бы рад получить ответы на любые из них (просто пропустите части, которые вам не интересны).

Особая ситуация: idmap периодически не сканируется для контроллеров домена

В Active Directory, совместимом с Windows Server 2008, обычно существует несколько контроллеров домена для обеспечения высокой доступности. Если все эти серверы недоступны одновременно, и файл-сервер OmniOS (r151018) с активным SMB/CIFS-сервером ядра (который успешно присоединен к домену и работает как положено) загружается, происходит следующее:

idmap служба пытается достичь DC в течение 60 секунд, а затем сдается...

root@omnios:/root# tail -n 20 /var/svc/log/system-idmap:default.log
@ Tue Sep  6 10:19:42 2016
Global Catalog servers not configured/discoverable
Domain controller servers not configured/discoverable
created thread ID 3 - 1 threads currently active
[ Sep  6 10:19:42 Method "start" exited with status 0. ]
@ Tue Sep  6 10:19:53 2016
created thread ID 4 - 2 threads currently active
getdcname wait begin
@ Tue Sep  6 10:19:57 2016
DNS: _ldap._tcp.dc._msdcs.testdomain.intranet: Host name lookup failure
@ Tue Sep  6 10:20:08 2016
getdcname timeout
@ Tue Sep  6 10:20:12 2016
DNS: _ldap._tcp.dc._msdcs.testdomain.intranet: Host name lookup failure
@ Tue Sep  6 10:20:27 2016
DNS: _ldap._tcp.dc._msdcs.testdomain.intranet: Host name lookup failure
@ Tue Sep  6 10:20:42 2016
DNS: _ldap._tcp.dc._msdcs.testdomain.intranet: Host name lookup failure
Domain discovery took 60 sec.
Check the DNS configuration.

... но не подводит критически

root@omnios:/root# svcs -xv idmap
svc:/system/idmap:default (Native Identity Mapping Service)
 State: online since Tue Sep  6 10:19:42 2016
   See: man -M /usr/share/man -s 1M idmapd
   See: man -M /usr/share/man -s 1M idmap
   See: /var/svc/log/system-idmap:default.log
Impact: None.

После этого, smbd каждую минуту (по праву) жалуется в системном журнале, что не может найти DC:

smbd[525]: [ID 510351 daemon.notice] smb_locate_dc status 0xc0000233
smbd[525]: [ID 199031 daemon.notice] smbd_dc_update: testdomain.intranet: locate failed

Это сохраняется даже после того, как DC снова подключен и доступен. Это обходит мгновенно путем перезапуска idmap с svcadm restart idmap, Конечно, поскольку эти отключения могут произойти без планирования, это не должно быть сделано вручную.

• Как мог idmap перезапуск быть сценарием для автоматического возникновения этих событий? Я пытался использовать SMF, но кажется, что это работает только для сбойных служб, в то время как idmap сообщает о проблемах (и smbd только отчеты, уведомления). Другой возможностью будет постоянный мониторинг файлов журналов и поиск событий, но это кажется мне неэффективным. Я также пытался уменьшить config/rediscovery_interval значение до 60 секунд, но кажется, что оно игнорируется (или не применимо здесь).
• В качестве альтернативы, какое может быть решение, которое устраняет саму проблему? К сожалению, я не нашел ничего полезного, кроме публикации, которая признает, как полный перезапуск решает проблему (как idmap там тоже перезапускается).

Изменить: вывод svccfg -s idmap listprop - единственное, что я изменил, было config/rediscovery_interval (по умолчанию 3600), идентификаторы были впоследствии удалены вручную.

config                                           application
config/id_cache_timeout                          count    86400
config/list_size_limit                           count    0
config/name_cache_timeout                        count    604800
config/preferred_dc                              astring
config/stability                                 astring  Unstable
config/use_ads                                   boolean  true
config/use_lsa                                   boolean  true
config/value_authorization                       astring  solaris.smf.value.idmap
config/machine_uuid                              astring  [...]
config/machine_sid                               astring  [...]
config/rediscovery_interval                      count    60
config/domain_name                               astring  testdomain.intranet
debug                                            application
debug/all                                        integer  0
debug/config                                     integer  0
debug/discovery                                  integer  0
debug/dns                                        integer  0
debug/ldap                                       integer  0
debug/mapping                                    integer  0
debug/stability                                  astring  Unstable
debug/value_authorization                        astring  solaris.smf.value.idmap
rpcbind                                          dependency
rpcbind/entities                                 fmri     svc:/network/rpc/bind
rpcbind/grouping                                 astring  require_all
rpcbind/restart_on                               astring  restart
rpcbind/type                                     astring  service
filesystem-minimal                               dependency
filesystem-minimal/entities                      fmri     svc:/system/filesystem/minimal
filesystem-minimal/grouping                      astring  require_all
filesystem-minimal/restart_on                    astring  error
filesystem-minimal/type                          astring  service
manifestfiles                                    framework
manifestfiles/lib_svc_manifest_system_idmap_xml  astring  /lib/svc/manifest/system/idmap.xml
general                                          framework
general/action_authorization                     astring  solaris.smf.manage.idmap
general/entity_stability                         astring  Unstable
general/single_instance                          boolean  true
general/value_authorization                      astring  solaris.smf.manage.idmap
start                                            method
start/exec                                       astring  /usr/lib/idmapd
start/timeout_seconds                            count    60
start/type                                       astring  method
stop                                             method
stop/exec                                        astring  :kill
stop/timeout_seconds                             count    60
stop/type                                        astring  method
refresh                                          method
refresh/exec                                     astring  ":kill -HUP"
refresh/timeout_seconds                          count    60
refresh/type                                     astring  method
tm_common_name                                   template
tm_common_name/C                                 ustring  "Native Identity Mapping Service"
tm_man_idmapd1M                                  template
tm_man_idmapd1M/manpath                          astring  /usr/share/man
tm_man_idmapd1M/section                          astring  1M
tm_man_idmapd1M/title                            astring  idmapd
tm_man_idmap1M                                   template
tm_man_idmap1M/manpath                           astring  /usr/share/man
tm_man_idmap1M/section                           astring  1M
tm_man_idmap1M/title                             astring  idmap

Общая проблема: как эффективно реагировать на сообщения системного журнала, если процесс работает нормально?

Эта проблема может быть обобщена на вопрос о том, как наиболее эффективно просматривать файлы журналов в Solaris. Я искал и наткнулся на несколько инструментов, таких как swatch, logsurfer, logwatcher или обычное старое задание cron, выполняемое каждую минуту и ​​связанное с простым скриптом, который читает dmesg выход.

• Это единственно возможные способы сделать это или есть лучшее решение?
  • Есть ли способ сообщить SMF, что определенные уведомления о некоторых процессах должны встречаться с действиями, даже если не возникло критических условий?
  • Я наткнулся на FMA диспетчера сбоев, но, похоже, он также работает только в критических условиях, а не на простых уведомлениях (или любых определяемых пользователем строках). Это правильно?
• Если это единственный способ, что бы вы предложили использовать и почему?