On Mon, Sep 15, 2014 at 7:26 PM, Richard Pieri <richard.pi...@gmail.com> wrote: > On 9/13/2014 9:28 AM, Edward Ned Harvey (blu) wrote: >> But if you want to create something new, the ability to daemonize >> any-random-command is a really nice convenience factor; you just >> write any simple console application or shell script, and it behaves >> exactly the same on your command terminal as it does when you make it >> a service under systemd. >
>> An active system will notice mysqld died, recognize that it's not >> supposed to do that right now, and restart it. I know SMF will try > > Which is a stupid way to run in production. There's a reason why the > daemon died. That reason needs to be identified so that corrective steps > can be taken. Blind restarts can obfuscate this information, can cause > damage to data, and can exacerbate existing damage. I tend to think that way as well, but I have been noticing what I think is a trend away from debugging problems and towards just doing reinstalls/restarts. I think the rise of virtualization (particularly in the cloud) has driven this. As the tools make it easier and easier to spin up a new VM, why bother to figure out what caused the old one to fail, just reinitalize a new one and keep going. I remember some talk I went to recently about a tool to spin up anonymous(?) VMs where once the VM exited all storage was lost. So if you wanted the ability to debug a VM after it was shutdown, you had to be sure to log anything that might be relevant onto some kind of external storage server. And this, of course, assumes you knew ahead of time what would be relevant. While I think VMs and configuration management systems are great, I don't think they can eliminate the need to sometimes look at the actual details of a system. Unfortunately, I think the skills to do this are no longer being developed among new people. Hopefully, I'll be wrong and it won't matter when all the old timers are gone. Bill Bogstad _______________________________________________ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss