Следующую проблему можно рассматривать как проблему, связанную с CIFS / AD (конкретное представление) или как вопрос о перезапусках службы, обработке ошибок и анализе журнала (общий вид). Я представлю здесь обе области, но был бы рад получить ответы по любому из них (просто пропустите части, которые вам не интересны).
В 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 только сообщает уведомления). Еще одна возможность - постоянно отслеживать файлы журналов и искать события с помощью grep, но мне это кажется неэффективным. Я также попытался уменьшить 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 вывод.
Спасибо, что так подробно описали эту проблему в вопросе. Я недавно тоже столкнулся с этим, с оговоркой, что контроллер MS AD - это виртуальная машина, работающая на (пост) хосте OpenSolaris, и поскольку поддержка Win / AD сокращается на этом сайте, это единственная сохранившаяся реплика. Поэтому, когда он находится на ранней стадии загрузки (а idmap является частью дерева зависимостей, ведущего к многопользовательскому серверу), виртуальная машина еще не работает, и idmap не может связаться с ней, как вы написали, и smbd жалуется. Я полагаю, это лучше, чем невозможность полностью загрузить сервер из-за сбоя связи с AD.
Я думаю, что в качестве прямого ответа на ваш вопрос, есть и другие демоны ведения журнала :) Например, rsyslog может запускать команды, если зарегистрированное сообщение соответствует некоторому шаблону, который вы установили.
Поскольку журналы SMF svc не совсем хранятся в системном журнале, я думаю, что для этой ситуации нужно было бы создать специальный сценарий, чтобы проверить конкретный файл журнала в / var / svc / log / ... и перезапустить службу.
Также может выполнять отложенное действие (например, сценарий инициализации, который echo "svcadm restart idmap" | at now + 10min), чтобы всегда запускать его после загрузки, что, я думаю, я и сделаю здесь.
Наконец, можно добавить некоторую активность в сценарий запуска виртуальной машины, чтобы активировать idmap после загрузки виртуальной машины (и поэтому не полагаться на чисто жестко запрограммированное время), но не как часть дерева зависимостей SMF, поскольку idmap требуется так рано при загрузке ... или хотя бы не как строгая зависимость, а что-то вроде restart_on ...