>> Speaking as the Oracle person that Nico is obliquely referring to... :-)
Hehe, we called the miracle loud and insistent, and the miracle answered "Well, here I speaking as the oracle person ...". Nice! ;-) >> Other than that, what I would do is to try to collect a "truss" of idmapd >> running. Unfortunately, it's not convenient to get a truss of a service >> from its start. If it fails on restart (and not just on boot), what I'd >> probably try is to move idmapd out of the way, replace it with a shell >> script that sleeps before starting idmapd, and then "truss -f" it. I would >> also collect the state of the relevant files. Something like: > Thanks for your detailed analysis of my problem. I will try to realise your ideas. > Much simpler: just change the start method of the service! > > # svccfg -s idmap > svc:/system/idmap> listprop start > start method > start/exec astring /usr/lib/idmapd > start/timeout_seconds count 60 > start/type astring method > svc:/system/idmap> setprop start/exec = "truss -o /tmp/t -v all -t all > -f /usr/lib/idmapd" > svc:/system/idmap> ^D > # svcadm refresh idmap > <reboot> > > (Remember, this only happens on reboot, according to Marc). As I can say, the service will always change to maintenance mode, on system boot, and when I restart and clear the service at the running system. It falls everytime to this state, only when I run the service manually with "/usr/lib/idmap -d" than it runs as espected. To gain more time, I have installed a second system for my users to serve smb, cifs and nfs/nis functionalities, so I can examine the problem without the loaded revolver back of my head. I will play with your ideas tomorrow, at this point i will say thank you for your time and your insertion with my problems. Regards, .marc _______________________________________________ cifs-discuss mailing list cifs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/cifs-discuss
