Looking for any information on /stand/vmunix

[Tracy Ann Bringhurst]

Command which verifies tcp connections was not working it uses the kernel at /stand/vmunix. To recover from this problem we replaced /stand/vmunix with /stand/vmunix.old. From my understanding any updates to the kernel requries and system reboot for the kernel to see the change. I'm really trying to understand why this took care of the problem. And why a reboot was not needed.

[Tony Vilardi]

When the system boots, it loads the kernel (/stand/vmunix) into memory. Once the system is up and running the kernel file (/stand/vmunix) can be moved or changed but the changes will not take effect until the next reboot.
If the command only reads the file /stand/vmunix then placing the old vmunix.old file there could trick the command.

Tony

[Bruce Regittko_1]

Hi,

On 11.00, some system processes "cheat" by looking at the /stand/vmunix file rather than looking at the kernel in memory. This is why a new kernel is installed with the kmupdate command and not cp'ed into place. It is left in /stand/build until the next reboot when it is moved into /stand.

Keep in mind that while netstat may be happy with the old kernel, other processes may be misled if there are differences between the old kernel on /stand/vmunix and the new kernel loaded into memory.

Bruce

[Darrel Louis]

Hi,

did you check the date of the /stand/vmunix file before, replacing it.
Has somebody created a new kernel, copied it, without a reboot.
check difference between the two files:
- what vmunix > /tmp/vmunix_out
- what vmunix > /tmp/vmunixold_out

- /usr/lbin/sysadm/get_sysfile /stand/vmunix >/tmp/system
- /usr/lbin/sysadm/get_sysfile /stand/vmunix.old >/tmp/system.old
Compare those two files.

Also check with kmtune -l.

It could be that /stand/vmunix.old was the running kernel

[Tracy Ann Bringhurst]

I did compare the files there was no difference. This problem doesn?t seem to be related to any kernel changes that were not planned and tested.

We think some type of corruption happen to the file. It was working fine one minute and not the next. It was strange.

[Paul Hite]

netstat uses nlist(3C) to obtain addresses from /stand/vmunix. It then uses those addresses to know where in /dev/kmem to read. If netstat was failing, then nlist was failing. The addresses could be wrong because the kernel had been rebuilt but not yet booted. This is the possibility that has already been mentioned.

Another thought is that the permissions on /stand/vmunix were wrong so netstat could not read it. netstat runs sgid to sys, it is not suid to root.

Finally, someone could have run strip(1) on it and removed the system table.

You might look at the date on /stand/system to see when it last was created. A "ls -lu /usr/sbin/mk_kernel" will tell you when that command was last read. That might be when it was run or backed-up or just examined.

If it happens again, look at the symbol table with "nm /stand vmunix". The output from one that works will be different from one that doesn't work.