Many years ago I used to work (actually using the term "work' is a bit much in this context) in a Computing department at a University in the UK doing administration and some systems programming. It was a great learning ground and a great place to amuse oneself with ones colleagues. Can anyone ever get bored with using 'xset' to change the mouse acceleration of someone that left their display open? Ahh, happy days.
Still, now I'm big and responsible I would never do anything like that and could never condone such behaviour. What reminded me of this was some fantastic chaps I met at this years SUPerG conference in Phoenix (a must attend conference if you ever get the chance). They were from a large University somewhere in the world and for the purposes of this discussion we'll call them Bill and Ted. Now, both Bill and Ted work way harder than I ever used to when I was at University and know a lot more but they did have one failing and that was an unhealthy addiction to tcsh. I just have one thing to say about that. Boys, if you're reading make sure you run this on all your systems:
Whilst my example above is a bit of light hearted humour at the end of a long day it does use a feature of DTrace known as a process destructive action. DTrace is an observation technology and, generally, isn't about changing the state of a running process or kernel. However, there are some actions which change state in a controlled and predicatable manner and stop() is one of them. This action will leave the process stopped as if stopped via /proc (you'll see a 'T' against its state in a ps(1) listing). As you have the ability to create complex predicates in D you can decide to only stop() a process under obscure and rare conditions which can be extremely difficult to do with debugging technologies from the days of yore.
For more information on destructive actions check out the answerbook . In case you haven't checked out the answerbook before I'd suggest you go and check it out now. It is an awesome piece of technical literature written by the DTrace engineers themselves. Shibby.
Still, now I'm big and responsible I would never do anything like that and could never condone such behaviour. What reminded me of this was some fantastic chaps I met at this years SUPerG conference in Phoenix (a must attend conference if you ever get the chance). They were from a large University somewhere in the world and for the purposes of this discussion we'll call them Bill and Ted. Now, both Bill and Ted work way harder than I ever used to when I was at University and know a lot more but they did have one failing and that was an unhealthy addiction to tcsh. I just have one thing to say about that. Boys, if you're reading make sure you run this on all your systems:
#!/usr/sbin/dtrace -qws
proc:::exec-success
/execname == "tcsh"/
{
printf("pid %d: Let them sweat...\n", pid);
stop();
}
Give them a while and prun(1) them. They'll soon switch to a proper shell, namely 'ksh'.Whilst my example above is a bit of light hearted humour at the end of a long day it does use a feature of DTrace known as a process destructive action. DTrace is an observation technology and, generally, isn't about changing the state of a running process or kernel. However, there are some actions which change state in a controlled and predicatable manner and stop() is one of them. This action will leave the process stopped as if stopped via /proc (you'll see a 'T' against its state in a ps(1) listing). As you have the ability to create complex predicates in D you can decide to only stop() a process under obscure and rare conditions which can be extremely difficult to do with debugging technologies from the days of yore.
For more information on destructive actions check out the answerbook . In case you haven't checked out the answerbook before I'd suggest you go and check it out now. It is an awesome piece of technical literature written by the DTrace engineers themselves. Shibby.
