Hi, Henry! :-)
On Fri, 20 Feb 2004, Henry Baragar wrote:
>On Fri, 20 Feb 2004 08:57:46 +0100 (CET), Andreas Aardal Hanssen
><[EMAIL PROTECTED]> wrote:
>> The problem with moving the directories is that svscan is stupid! If it
>Lets not confuse simple (and reliable) with stupid! I can't think of any
>way to make svscan smarter without sacrificing at least one of:
>reliability, administrative ease or code verifiability.
>My $.02:-)
Well there are several smart ways to design a system. The kind that
produces numerous support requests with a non-trivial fix for what seems
to be logical behavior, is in my opinion stupid. ;-) Stupid stupid stupid!
>What would you have svscan do? Create a dummy logging process that
>throws away the logging information (the stdout of the main process)
>until it finds a ./log/run file? I do not desire this.
Today it throws it away until you deinstall the service. And the lost
output is reported by svscanboot (which writes to argv[]!), and is only
visible if the admin lists the processes with "ps".
>If svscan does not create a dummy process, then either svscan has to
>handle the logging information itself or it has to kill off the main
>process when it finds a ./log/run/file. Neither of these alternatives is
>acceptable.
Off the top of my head:
1) every time the service starts, <path>/log could be stat'ed. If it's
there, start the logging service. If it's missing or if <path> itself
is missing, remove the service rather than having stale <defunct>
processes hanging around.
That would also solve the common problem where one wants to add a log
handler _after_ the service has been installed, without having to do the
completely unlogical "cd /service/imap && mv /service/imap /tmp && svc -dx
. && rm -rf /tmp/imap".
And these extremely annoying times after some hacking where suddenly two
instances of qmail start up at the same time! Has anyone seen this before?
2) if there is a service entry that is not a symlink, refuse to start it
and report an error if the user does a svc -u on it.
Explicitly requiring symlinking instead of "recommending it" would remove
the race condition of creating a log service completely. The only case
left is the one where the log directory is created after the service is
installed.
>I used to desire a smarter svscan, but came to a realization I am much
>better off by taking a little bit more care when adding a new service. I
>also have come to the realization that almost every time I wish DJB's
>software did things a different way, I find that the con's of the desired
>change outweigh the pro's.
DjB software is, in a sense, great! It's reliable, it's secure, and it's
fairly easy to set up if you read the docs. But it is not intuitive in any
way. You _have to_ read the docs _completely_, and most admins learn the
hard way by guessing how it works, only to experience a complete disaster.
It's like the level of qmail guruism is proportional to how many times
you've messed up qmail ;-).
Good design is crafted after the user. What would the user try to do in
this case? And then the alternatives should either be made so that they
work, or they should be made _impossible_. Wonder if a door is pulled or
pushed? Allow _both_. Does turning the volume up to level 15 make your
stereo explode? Make the knob stop at _14_. Superglue and a knife,
whatever. ;-)
Ofcourse qmail admins back up their queues with "tar cfz ....", they
assume that's got to be okay (hey, it works for all other databases and
mail systems I know of), but then when they rollback a backup they get
lots of completely useless junk in their logs about inodes and other
hoodlum. The admin wasn't stupid in this case - he was being creative and
using his experience! And that just doesn't work with DjB software.
I'm blowing off steam here, because I believe strongly that very much of
the software DjB writes is designed perfectly technically, but it is
written for robots and not humans!
Andy :-)
Very many things in our world are very ridiculously badly designed!
--
Andreas Aardal Hanssen | http://www.andreas.hanssen.name/gpg
Author of Binc IMAP | "It is better not to do something
http://www.bincimap.org/ | than to do it poorly."
