leading underscore in /etc/system variables
By Alan Hargreaves-Oracle on Aug 08, 2004
While working an escalation the other week I needed to increase the default size of a kernel stack for a customer in order to provide relief1 while a new bug was fixed. The default size of a kernel stack is governed by _defaultstksz. Unfortunately the way that the lexical analyzer for /etc/system is written, we can't have a leading underscore in a variable name in /etc/system. Normally we can work around this with the following addition to /etc/system:
Unfortunately, the problem that we were seeing was using a thread that was created specifically using _defaultstksz, so this workaround didn't help.
Well, the only way that we could provide relief was to actually modify the variable in the kernel binary (in this case /platform/i86pc/kernel/unix as it was a v20z) with a bit of mdb.
# echo _defaultstksz/W0x4000 | mdb -w /platform/i86pc/kernel/unix
As you can guess, this is not something that we feel particularly comfortable about.
Apart from the fact that we are really patching a kernel binary, the next time that the customer installs a patch, the workaround is silently gone (we're actually working on something for this, more as I can talk about it).
Well, it appears that I am not the first to encounter this problem. Bug 4025675 complains about precisely this issue, and apparantly it was addressed in build 50 of Solaris 10. The actual fix itself was pretty simple, so I endeavoured to backport the fix to Solaris 8 and 9.
The actual backport and builds for the various systems did not take too long. What did take some time was the verification on all combinations of (Solaris 8, Solaris 9) vs (SPARC32, SPARC64, x86).
I finished my final test yesterday and submitted my request to integrate to get this into the kernel updates for the aforementioned systems. The request has been granted and now I'm just waiting on the gates to open for the patch builds.
With luck this will get integrated shortly, and after the kernel patches go through their thorough workout before release, we shoudl be seeing it for Solaris 8 and 9.
1. The way that we work in PTS is that the focus is on getting the customer running with some kind of workaround until the process of producing a patch (which includes an awful lot of testing) can be completed.