Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Dtrace for Linux

gnu.wildebeest.org

Post reply on HN
Print view View original

101–108 of 108 posts

Re: Dtrace for Linux

#101

Post by stock_toaster »

floatboth wrote: post #38
alberth wrote: post #34

What does this mean for DTrace on FreeBSD? Given that DTrace is now GPL'ed, does that kill DTrace on FreeBSD? https://wiki.freebsd.org/DTrace

You can't retroactively revoke CDDL :) And new DTrace userspace is actually under the Universal Permissive License now (which is, well, permissive). The Linux kernel module is GPL. I don't think FreeBSD needs anything from that module at all.

The UPL license also has some somewhat "unique" patent grant wording with regard to a "Larger Works" file, which can even reference external projects by name, and its supposed use as a CLA document.

Not being a lawyer (and similarly not a licensing or IP subject matter expert), and know the license was drafted by Oracle, I am somewhat suspicious of it.

Re: Dtrace for Linux

#102

Post by kloczek »

brendangregg wrote: post #81
kloczek wrote: post #77

Earlier quoted context omitted.

Better? OK, could you please show me eBPF oneliner code which is analogue of the DTrace command like: # dtrace -qn 'syscall::write:entry /execname == "mysqld"/ {self->stime = timestamp;} syscall::write:return /self->stime != 0/ {@LWrite = quantize(timestamp - self->stime);} tick-10s {printa(@LWrite);}' ?? Above is now working not only under Solaris but under Oracle UEK Linux kernel as well.

# funclatency -i 10 -p `pgrep -n mysqld` sys_write Whoops, that was easy. I think argdist can do this as well. I'd have picked a different one-liner. It's not hard to come up with DTrace one-liners that are currently horribly hard with eBPF and bcc. Which is why I said we could have DTrace's D as a front end to bcc/eBPF. Or the bpftrace project will do that, and already has similar one-liners. Check it out[1]. Either…

Just FTR. Your example is wrong.

[root@domek ~]# /usr/share/bcc/tools/funclatency -i 10 -p `pgrep -n mysqld` sys_write 0 functions matched by "sys_write". Exiting.

The correct one is:

funclatency -i 10 -p `pgrep -n mysqld` vfs_write

Nevertheless, I'm not happy that there this no in this case analogue of the language which I can use on correlating data from different probes. Tools like funclatency cover exact class of the cases and on implementing anything more sophisticated still, I wont to have something like DTrace as frontend.

Re: Dtrace for Linux

#103

Post by twic »

Smurfix wrote: post #75
twic wrote: post #58

Earlier quoted context omitted.

Threads still have PIDs! I have had an issue on some heavily-loaded systems where a process dies but leaves a pidfile around, then its PID is reused for a thread in another process. When i run a restart script for the process, it reads the pidfile, confirms that the PID is alive, and then kills it - so shanking some random completely unrelated process. I have modified the script to make some more careful checks befor…

You mean, like systemd?

I assume this was in response to "Really, we should just use a proper process manager, but that probably won't happen soon".

Yes, like systemd. Our servers even run systemd already!

Sadly, we don't have root on our servers, and user-level service support is broken on CentOS 7:

https://bugs.centos.org/view.php?id=8767

Maybe i could install another process manager of my own, and start it from cron. That really doesn't sound like fun, though. Is there a simple process manager which i can install and use without root privileges, and which won't make me restructure my whole deployment process?

Re: Dtrace for Linux

#104

Post by lscotte »

severino wrote: post #55
jsiepkes wrote: post #4

Really cool! However isn't it a bit too late for DTrace to gain market share on Linux now SystemTap and all have gotten such a head start? For me personally I like the idea of being able to use my DTrace skills (which I gained on FreeBSD and SmartOS) on Linux!

Well, it's never too late! I mean, when reading articles like this one: http://www.brendangregg.com/blog/2015-07-08/choosing-a-linux... Linux tracing looks like a mess, where there're dozens of incompatible alternatives, each one with its gotchas. But instead, dtrace is a mature standard framework which also works under BSD or macOS. You got one programming language, D, and tons of resources out there. So... my best…

It was a mess back then - in 2015. Instead, it's probably more useful to look at at where things are today rather than assuming things are the same as they were a few years ago. Things move fast in this space - for example, just a year later Brendan wrote this on eBPF: http://brendangregg.com/blog/2016-10-27/dtrace-for-linux-201...

Re: Dtrace for Linux

#105

Post by [deleted] »

cookiecaper wrote: post #80
brendangregg wrote: post #74

Earlier quoted context omitted.

I'm sorry, but Bryan did not "address" the real reasons I left Joyent. What he said was inaccurate. I no longer believe in illumos. It made a lot of sense in 2010 when competing with Linux, a lot less by 2014, and very little today. When we created illumos in August 2010, the latest Linux version was 2.6.35. The cutting-edge latest. Most people were still running older versions, 2.6.32, 2.6.27, etc. Linux had many pe…

Brendan, thanks very much for replying to this. It's great to get clarity around it. Your blog and HN posts have been great resources as I've gone down this rabbit hole, and since I've read so many of them, I know that's not the first time you've heard it. Your work has been hugely valuable to this community. Since the options for illumos employment are and were scant, the story that you were looking for a change of…

[deleted]

Re: Dtrace for Linux

#106

Post by paride5745 »

snw wrote: post #100
paride5745 wrote: post #3

Time for ZFS now! Even better yet, a new OpenSolaris under GPL instead of CDDL.

The new OpenSolaris is called illumos. And the CDDL is actually fine. Give it a try :)

I use OpenIndiana since its beginning, it's fine but IMHO not there for serious work. FreeBSD with ZFS is miles ahead.

And the CDDL is not fine, as it is not compatible with GPL, which makes it impossible to have it official in the Linux kernel.

Re: Dtrace for Linux

#107

Post by Annatar »

cookiecaper wrote: post #97
bcantrill wrote: post #93

Earlier quoted context omitted.

I'm definitely not trying to be "hand-wavy"; apologies if it's taken that way. So let me make this slightly blunter: our goal in SmartOS and illumos is to solve systems problems -- and yes, we do it with the courage to go our own way where we see fit. If that worldview is a match for you, that's awesome. If that's not a match for you, that's fine too -- world domination is not, in fact, our goal. Yes, we are a small…

I see the small community in illumos as a benefit, more or less. I'm not trying to denigrate it for its size. The issue is the attrition, the apparently-negative momentum, and the loss of prominent proponents and distributors, including Brendan, OmniTI, etc. That's bad when something is already small. It makes people wonder why others are fleeing. My concern, as it relates to this thread, is around the spectacular lo…

“A world where Bryan Cantrill is the lone SmartOS holdout, after his compatriots have declared it a lost cause, is just nerve-wracking.“

Bryan Catrill will never be alone for as long as I draw breath: I will single handedly continue working on illumos and SmartOS even if everybody else quits doing that. I have already made up my mind after a lengthy private exchange with Brendan Gregg a while ago.

Re: Dtrace for Linux

#108

Post by crest »

loeg wrote: post #96
JdeBP wrote: post #85

Earlier quoted context omitted.

We've talked before about FreeBSD's process descriptors and EVFILT_PROC kevents, ne?

Process descriptors are unfortunately a little incomplete -- pdwait() was never implemented. They don't seem to be getting much use.

You don't need pdwait(). You can watch the process descriptor with kqueue to get the process exit status look for EVFILT_PROCDESC in https://www.freebsd.org/cgi/man.cgi?kevent.
Post reply on HN