[OpenIndiana-discuss] Debugging systems startup

[James Carlson]

Jim Klimov wrote:
> 2012-10-01 15:28, James Carlson пишет:
>> Jim Klimov wrote:
>>> I want to inject some echo's into my SMF startup scripts to
>>> report about the progress of my systems startup (and possible
>>> problems). Actually I did that, and "echo... > /dev/console"
>>> if a special flag-file exists in the /etc/ filesystem.
>>
>> SMF was actually designed to *avoid* that sort of mess, but I guess to
>> each his own.
> 
> Well, in my case I'm debugging (or seeing the progress of)
> mounting the split-root filesystem components. Sometimes
> things break in the BEs that I test, but I can repair stuff
> by booting into the basic BE that works. Enabling/disabling
> logs by a flag-file like this (or by a kernel option) is
> IMHO much easier than doing it with SMF from another BE.

The way it was intended to be used was that you'd log into that failing
system at the console, run "svcs -xv" to find out what was wrong at a
high level, and then use that information to drill down to the component
of interest.

But it's your project, so you're certainly on your own.

>>> 1) I wanted to make this mechanism more convenient by also
>>> logging the information if the kernel was booted with the
>>> "-m verbose" or "-v" option; how can a userland program
>>> query the options passed to OI kernel?
>>
>> Looking at the source for svc.startd (usr/src/cmd/svc/startd.c), it
>> looks like that just sets an internal flag and isn't exposed to
>> applications.
> 
> Sad... I think in Linux all the options are exposed as readable
> command-line parameters of some process (#1? #0? something...)

The line between sad and intentional can get blurry, I suppose.

Yes, of course, if you want to grovel through someone else's command
line parameters, you're welcome to do so.  Either use ps(1) or look at
proc(4) for a way to get the information in a programmatic way.

I'd hope that nobody building a real system would do that, as it
obviously violates a number of architectural principles, but if you're
just hacking, have at it.  "svcs -p svc/restarter" might be a good
starting point to get that information.

Personally, I'd just create an "options/verbose" parameter inside my
service and use that to control whether a given service was chatty at
start-up time, rather than attempting to piggy-back on the restarter's
idea of verbosity.

-- 
James Carlson         42.703N 71.076W         <carlsonj at workingcode.com>