I said "No." once, but it was in a code review, and there was a lot of context involved. It generated a pretty big backlash until I went to the trouble of explaining all of it. In retrospect, it worked out perfectly, because without the backlash, people might not have realized what had been going on.<p>I was responsible for keeping a LAMP stack running which ran a bunch of tests written by various other people in the larger department. Usually the benchmark would be C++, and that would be kicked off by a shell script, and that shell script would be kicked off by a Python program. Obviously this is pretty crazy already, but this one guy found a way to make it worse.<p>One day I noticed this machine was running out of disk space. It was also getting bogged down and was starting to swap since something was chewing CPU and memory. I found a benchmark program (one of the C++ binaries) running, and since it never shut down properly, it kept these giant log files open. Since they were still open, the log rotator couldn't reclaim the space.<p>I filed a bug with the test owner: please make this test not leave these processes behind. He didn't seem to know how, so I just said that you should make sure you've stopped anything you started. He didn't know how to do that either and booked an appointment in my calendar to see me in person (yes, really).<p>On that day, we chatted, and I told him that syscalls like fork() return the PID of what you started. You can just hang onto it and whack it later. If that process doesn't fork itself to become a daemon (which this one didn't), odds are it will be the value you want when the time comes. If it does fork or whatever, you might be able to get something done with process groups. I had to explain fork, kill, setpgrp, setsid and all of that to someone who was supposedly employed as a systems tester.<p>A couple of days later, he sent me a proposal for a fix. It amounted to this:<p><pre><code> ps aux | grep bin_name | grep -v grep | awk ... | xargs kill -9
</code></pre>
I should point out that this machine would usually run multiple instances of the same test on different machines at the same time. They'd all have the same bin_name, and they all ran as the same user. At best, the script would kill itself. If we weren't so lucky, it would also bring down anything else which happened to match "bin_name", even if it was completely unrelated.<p>Even though I had shown him the low-level way to do the right thing, he fell back on this scripting monkey approach. I said that was unacceptable, and left him to figure it out.<p>Months passed. I'm not exaggerating here. It was something like four months later when I heard back from him. He posted a comment to the (still living) code review asking if things were okay now. I loaded it up to see what he had done.<p>Nothing had changed. It was the same "ps ... xargs kill -9" cruft he wrote originally. He didn't even try to change things. Maybe he was trying to sneak it past me and wanted to see if I'd forgotten, or didn't care, or what.<p>Well, given that his question was "is this okay now", my answer to the review was just: "no.". I was no longer interested in elaborating and spoon-feeding him.<p>He obviously didn't like this, because a few minutes later I had mails from both his boss and my boss saying how I needed to be more constructive and all of this.<p>I wasn't about to take this lying down, so I found all of our old communications where I tried to teach him how to do his own job: job control stuff fork, kill, and the like. I mentioned all of the back and forth we had and the time I had taken to explain it in person. I even dug up the example code I had written to demonstrate exactly what a session leader or process group winds up doing in practice.<p>I pasted all of this into the code review, making it public record for the entire company to see. The managers backed off and apologized to me.<p>A couple of weeks later, he disappeared into some other department.