以下问题可以视为与 CIFS/AD 相关的问题（特定观点）或与服务重启、错误处理和日志解析有关的问题（一般观点）。我将在这里介绍这两个领域，但很乐意收到任何领域的答案（只需跳过您不感兴趣的部分）。
特定情况：idmap 不会定期重新扫描域控制器
在兼容 Windows Server 2008 的 Active Directory 中，通常有多个域控制器以实现高可用性。如果所有这些服务器同时不可用，并且具有活动内核 SMB/CIFS 服务器的 OmniOS (r151018) 文件服务器（已成功加入域并按预期工作）启动，则会发生以下情况：
该idmap服务尝试在 60 秒内到达 DC，然后放弃......
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），之后 ID 已被手动删除。
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，但它似乎也只在关键条件下起作用，而不是在普通通知（或任何用户可指定的字符串）上起作用。这是正确的吗？
- 如果这是唯一的方法，您建议使用什么以及为什么？
答案1
感谢您在问题中如此详细地描述这个问题。我最近也遇到了这个问题，但需要注意的是，MS AD 控制器是运行在（后）OpenSolaris 主机上的 VM，随着该站点对 Win/AD 的支持逐渐减少，这是唯一幸存的副本。因此，当启动初期（并且 idmap 是通往多用户服务器的依赖关系树的一部分）时，VM 尚未运行，idmap 无法与它联系，就像您发布的那样，并且 smbd 会抱怨。我想这比由于联系 AD 时出现故障而无法完全启动服务器要好。
我认为直接回答你的问题，还有其他日志守护进程:)例如，如果记录的消息与你设置的某些模式匹配，rsyslog 可以触发命令。
由于 SMF svc 日志尚未完全系统记录，我猜想必须针对这种情况制作一个临时脚本来检查 /var/svc/log/... 中的特定日志文件并重新启动服务。
还可以执行延迟操作（例如，初始化脚本echo "svcadm restart idmap" | at now + 10min）以在启动后始终启动它，我想这就是我在这里要做的。
最后，可以在 VM 启动脚本中添加一些活动以在 VM 启动后启动 idmap（因此不依赖于纯粹的硬编码时间） - 但不是作为 SMF 依赖树的一部分，因为 idmap 在启动的早期阶段是必需的......或者至少不是作为严格的依赖关系，而是像 restart_on 这样的东西......