Lubomir Petrik - Sun Microsystems wrote: > Hi, > is there a way, so that SMF puts the service to the maintenance if > process dump core (maybe after 3 times)? I think it would be nice if I > could tell in the service manifest that core file creation should be > treated same way as if start/stop methods would return non-zero code. > > My problem is as follows: > I have a service that contains just 1 process. During the development I > made some mistakes that caused it to dump core and I could see one 1 of > 2 behavior based on if I had 'ignore_error core' set or not. > a) core is an eror: SMF restarts process due to the core dump, logs > contained message about the core - nice > b) SMF ignored the core dump, but restarted the service due to the fact > that all services in contract exited, logs did not contain message about > core creation - not so nice > Unfortunately both settings led to the same behavior - service was being > infinitely restarted every 2secs or so and I definitely didn't like this > behavior.
Our restarting-too-quickly detection could definitely use improvement. I'm pretty sure there's a bug on this, but I don't know it off the top of my head. > Another problem occurred when I disabled the service and wanted to look > at the core file - didn't find it. > > Does SMF respect my setup done with coreadm? I've found somewhere that > SMF creates the core files in root directory, but didn't find it there > as well. Process created core file when not started over SMF. > > How does SMF affect core file creation? Should core file be created even > if 'ignore_error core' is set? SMF does nothing to affect core file creation. The only possible influence SMF has is it chooses (based on the service's definition) which directory to start the service in. In most cases this is /. If other services are dumping core, it is possible that your service's core file was overwritten. Services started under SMF respect coreadm's settings, so I recommend using coreadm to enable global core files with a pattern that avoids collisions. Dave
