jbk, if you're okay with auto-assignment, the way I've gotten it to work is by using the "ips" field in the config. It takes an array, and the dynamic options are "dhcp" for ipv4 and "addrconf" for ipv6, but you can drop a static v6 in there too iirc. I've never tried it though.

fenix illumos#17575

FEATURE 17575: Have pstack support "-k" to see kernel thread stacks (New)

↳ illumos.org/issues/17575

(Am I on crack or is folding the mdb one-liner into pstack(1) a good idea?)

it seems useful enough... i think it'd be implied, but maybe good to reiterate the output would be 'not an interface' in case someone later wanted to be ambitious and maybe read /dev/kmem directly and format the output similar to the existing pstack output....

vs. spawning mdb

i mean, like 99% of the time some process is unkillable or is otherwise stuck in the kernel, that is the first thing I go to

@jbk -> only question I have is should -k only query kernel or should it be an additive to procfs user stack, and we have -K for only query kernel ? Silly UI design decision...

probably one of those things where seeing might help -- this is probably beyond the initial proposal, but as a 'future rainbows and ponies' behavior, showing the stack across the kernel boundary like it was one thing would be pretty neat

having the feature in pstack would be nice, implementing it that way seems off

Yeah I think we should probably implement it as code in pstack. I feel like a lot of the actual stack walky bits are in some library anyway?

(I do think being able to show both the user and kernel stack as a unifed thing would be neat, also)

Also feels like it would be good if pstack had a flag for the aggregating behaviour of ::stacks haha

that logic is all in findstack, but isn't rough to commonize

the interesting thing is that if your thread is a /proc victim like this, you do already know it's stack

'cos you stopped it for /proc