I may have run into that before. I thought it came up in only relatively
obscure circumstances, so hadn't gotten to it yet. Looking at it again, it
still looks like it can only happen in failure cases.
Please try this and report the output that shows up in
/var/svc/log/system-idmap:default.log
# svccfg -s idmap setprop config/debug = boolean: true
# svcadm restart idmap
Brent Jones wrote:
On Sat, Oct 3, 2009 at 4:49 PM, Alan.M.Wright <[email protected]> wrote:
What does the stack look like in the idampd core file?
Alan
# pstack /var/cores/core.idmapd.682
core '/var/cores/core.idmapd.682' of 682: /usr/lib/idmapd
----------------- lwp# 1 / thread# 1 --------------------
0806a48c reload_dcs (80f5e28, 8047d70, 1, 0, 0, 0) + ac
08068e8e idmap_cfg_load (80f9f10, 0, 8047dd8, 8069f90) + 332
08069fbf load_config (2, 1, 8047e08, 8069ab2, 80d1cc8, 8060210) + 3b
08069f28 init_mapping_system (80d1cc8, 8060210, 4, 40000, 80d2260, 1) + 28
08069ab2 init_idmapd (29, fef87034, 10000, 10000, 8047e14, feffb804) + 82
08069938 main (1, 8047e58, 8047e60, 8047e4c) + 18c
0805d11d _start (1, 8047ef8, 0, 8047f08, 8047f1a, 8047f2b) + 7d
----------------- lwp# 2 / thread# 2 --------------------
feef1577 __nanosleep (fec7efbc, 0, 0, fef85180) + 7
0805f2c5 adreaper (0, fef7f000, fec7efec, feeed34e) + 21
feeed386 _thrp_setup (fed50200) + 7e
feeed610 _lwp_start (fed50200, 0, 0, feeed34e, 0, 0)
_______________________________________________
cifs-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/cifs-discuss