A contract between OpenSolaris and GNU/Linux users
Hello there… one of the objectives of the OpenSolaris distro, is to make easy the platform’s adoption for the GNU/Linux users. I think one thing that every user does when facing a new operating system is execute a simple command like: “ls /”. And some other “ls” to try to explore the new system… Ok, and what’s the matter with that?
Well, the users will find some directories that they don’t know, and with names a little “strange” for the new guests… an example is the “/system/contract” (i wonder what an user can think of a directory with that name on a SUN distribution ;).
But wait! You don’t have to pay anything for your listing… the contract filesystem is a pseudo filesystem, so providing filesystem semantics to the solaris subsystem used for process management (formaly contract subsystem). Contract is just a formal definition for a relationship between two or more processes. It’s a powerful feature of Solaris/OpenSolaris!
If you are new to Solaris/OpenSolaris, the SMF (Solaris Management Facility) can be a good point of start to understand one side of the contract subsystem. One important information we can have of SMF is the relation of SMF instances and processes. As you may be thinking, that information is from the contract subsystem. Let’s see an example:
# svcs -p hal
STATE STIME FMRI
online Oct_03 svc:/system/hal:default
Oct_03 704 hald
Oct_03 706 hald-runner
Oct_03 774 hald-addon-netw
Oct_03 778 hald-addon-cpuf
Oct_03 807 hald-addon-stor
Oct_03 875 hald-addon-stor
Oct_03 883 hald-addon-stor
The “-p” option in the svcs command “Lists processes associated with each service instance“. So, using that option we can know that seven processes are related to the hal service (pids = 704 706 774 778 807 875 883). But we can see more about that “magic”, with just one more option to svcs…
# svcs -v hal STATE NSTATE STIME CTID FMRI online - Oct_03 64 svc:/system/hal:default
Using the “-v” we can see the contract id (CTID) for that service: 64. That is the contract, and that is the information used to give us the processes managed by that SMF service. There is a utility to allows a user to observe the contracts active on a system, so let’s use it to show the informations about that specific contract:
# ctstat -vi 64
CTID ZONEID TYPE STATE HOLDER EVENTS QTIME NTIME
64 0 process owned 8 0 - -
cookie: 0x20
informative event set: none
critical event set: hwerr empty
fatal event set: none
parameter set: inherit regent
member processes: 704 706 774 778 807 875 883
inherited contracts: none
service fmri: svc:/system/hal:default
service fmri ctid: 64
creator: svc.startd
aux: start
Look at the line: “creator: svc.startd“, and the line: “member processes: 704 706 774 778 807 875 883“, and you will have a good understanding about the word “contract” used in this subsystem. That is the subsystem used for the SMF to monitor the execution for each process under control. If you look other contract id’s, you will see that everyone has the svc.startd (Service Management Facility master restarter) as the creator.
But there is another important information we can have using the contract subsystem, that maybe is not that easy to new users to realize. I’m talking about the reverse way. I mean, given a process, to know what SMF service it belongs.
# ps -octid -p 704 CTID 64
We have just used one pid and did ask to print the ctid. So, with that information we can know what is the SMF service related to that process (ctstat -vi 64). And remember that pgrep can list processes using a ctid:
# pgrep -c 64 774 807 778 706 704 875 883
Now, when you see a process in your system, and don’t know what was the SMF instance that started it (if was one ;), i think you can find it out.
That’s all
peace.
Excellent! More like this!