% procstat -kk 5592
PID TID COMM TDNAME KSTACK
5592 103222 less - procstat can also do interesting things, like show current rusage state:
% procstat -r 5592
PID COMM RESOURCE VALUE
5592 less user time 00:00:00.010805
5592 less system time 00:00:00.002444
5592 less maximum RSS 3172 KB
5592 less integral shared memory 192 KB
5592 less integral unshared data 80 KB
5592 less integral unshared stack 256 KB
5592 less page reclaims 199
5592 less page faults 0
5592 less swaps 0
5592 less block reads 4
5592 less block writes 0
5592 less messages sent 0
5592 less messages received 0
5592 less signals received 0
5592 less voluntary context switches 59
5592 less involuntary context switches 0How about other languages? Python, ruby?
[1] https://stackoverflow.com/questions/4876274/kill-3-to-get-ja...
No, this is a _kernel_ backtrace: what is happening in kernelspace on behalf of your process. If the work is being done in userspace (that is, in state R; the thread isn't in a syscall or page fault handler), you'll see essentially nothing here. I just tried it on a userspace busylooper and got this:
[<0000000000000000>] exit_to_usermode_loop+0x57/0xb0
[<0000000000000000>] prepare_exit_to_usermode+0x20/0x30
[<0000000000000000>] 0xfffffffffffffff
If you want a userspace stack trace, you need a different tool. If you're using an interpreted (or perhaps JITted) language, yes, you probably want something language-specific.
Also note the current stack trace is a per-thread concept, not a per-process one. If you're looking at a multithreaded program, you want to target the thread(s) of interest with "/proc/<PID>/task/<TID>/stack".
Not on production images, though.
[citation needed]
Also, when talking about embedded systems, people aren't normally talking about full Linux distros.
What worked better was a last chance hardware fault handler that wrote a partial core dump out to flash, and a tool to create an ELF core dump file from that that GDB can accept.
Secondly, SIGABRT will cause the process to abort and dump core, will it not? That would give you a userspace stack trace (if you load the core into a debugger) whereas this is how you get the kernel-side stack trace of a still-running process.
I don't know of a way to get the kernel stack trace of a process in a cross-platform way. Is there such a thing?
As for SmartOS, as someone who ran it at home and in production for years: Keep flying that flag, I guess. I liked it. But I also realized that Joyent, even with the Samsung acquisition, does not have the resources to keep it going in any meaningful way for anyone beyond themselves and people who have the exact same usecase as them. Things like lx branded zones are clever. I miss SMF, and am not a fan of systemd. But bpf is better than dtrace. Container management is easier than zone management. I've got less bugs dealing with KVM on Linux than I ever did on SmartOS. I spend less time compiling things from source and having to find random patch files to make things work. I know plenty about Solaris and SmartOS and HPUX and AIX and the BSDs and I don't think anyone is making the incorrect choice in deciding to learn Linux over any other UNIX-like.
That ship has sailed, man. And there's no compelling reason that it shouldn't have.
Linux has no containers, cgroups aren't anything conceptually close to zones. There are 56 different solutions to virtualization on Linux, all competing, mainly because everyone there is still flapping on deployment and lifecycle management. We'll just have to disagree and vehemently at that.
As for Joyent having no resources: you debug it and fix it yourself. That's precisely how Linux got to be the hegemony that it is today. Oh, how quickly we forget, how short our memory is...
Sending SIGABRT doesn't do what the article is talking about, on any UNIX. Perhaps you would learn something from listening to the kids these days, like the distinction between a kernel stack and a userspace stack.
Also, doesn't SIGABRT generally kill off the process?
Yes, a SIGABRT will get you a core file and will kill a process, but if your process is hanging in an endless loop (like the author's was), one already has far bigger problems, and keeping such a process running will not amount to much.
And this goes both ways - at one point Linux folks famously managed to violate the BSD license when porting some WiFi driver, iirc, which is notable, since it’s not that easy given the licenses nature :-)
Can you disambiguate CTF? I only know that as capture the flag, which doesn't really make sense here.
Edit: ok, I figured it out.
No theyre not going to give you that raw information because it's a kernel ASLR bypass. You can totally get all the same information with the dwarf symbols, but you're going to have to opt in on a kernel for it to mean anything.
Edit2: bitching about how people aren't using portable Unix techniques, and then citing features that are Solaris specific isn't a great look.
https://docs.oracle.com/cd/E19253-01/816-5041/syntax-20/inde...
For that to be useful, you'd need the addresses in question, which is why it'd be an ASLR bypass. The kernel needs to give higher level information by default so it can sanitize the output.
And the debugging symbols exist on Linux anyway, they're just DWARF (which ironically is the more standards compliant way as opposed to CTF).
https://www.freebsd.org/cgi/man.cgi?query=ctf&apropos=0&sekt...
Linux is the one lagging behind, as usual.
How is embedding source code an "ASLR bypass"?
Embddeding debugging information in a way that allows to you to use it (ie. in a way that you'd care about the format as an end user) implies giving you kernel addresses, which implies an ASLR bypass. If it's an implementation detail, then DWARF works great.
That's a disingenuous way to put it. The GPL is a free software license. It is "free" as in libre by all common definitions of "free" in regards to software.
The GPL is not compatible with the BSD dev's preferred license, which is much more likely the reason they avoid using such code.
By all conventional definitions, the BSD and GPL licenses are "truly free [software licenses]."
You're welcome to argue that the BSD license is better (because, for example, it lets sony create derivative playstation OSs without providing that source code to their users, ensuring their users have less freedom than if it were linux) or that the GPL is better (because it would prevent the previous), but they're both free licenses.
"My freedom to lock down someone else's code is more important than my user's freedom to have access to the code."
I also listed several alternatives just a few comments below, but apparently you didn't read that. You know of the old saying "you can bring a horse to the water, but you can't make him drink"?