> > The command exits with a non-zero return code, and the application > > invoking it is required to cope with the error and try a different > > method of signaling a problem. If it doesn't cope, the message is lost. > > Goodbye system logs. cron runs stuff like this: > <cronjob> 2>&1 | mail ...
No argument there. Note comments on smarthost reliability. > > Remember the basic assumption was that he *didn't* want to run a full > > MTA all the time. Starting with that assumption, you have to give up > > some of the niceties of a full MTA daemon, like queuing and automated > > retries, because there isn't any process there to DO the queuing or > > retries. If immediate delivery fails, your application has to make the > > call on what to do about it -- the MTA isn't there to defer things for > > you. > Indeed. _I_ wouldn't accept the consequences. I want my logs, especially > when something went wrong. Which is why I use a central logging host, and do all the logging produced by clients to that remote host. If a client tanks, I don't want to have to dig through the remains; I want the diagnostics somewhere central and easily located, and better yet, preparsed and ready to go, suitably edited and processed for analysis. I don't log anything on clients locally. If the client is so horked that it can't send syslog output, it's not going to give me anything useful to help fix it anyway, and I've done the up-front network engineering to ensure that UDP packets don't get dropped (I wish syslog-ng would stabilize...TCP would be good...). Crash logs on the console get recorded where I have easy facilities to do so (yay, VM spooling system!), but everything else goes to the logging host. > I don't think you want your logwatch report written to syslog, do you? I > don't. There are other detailed reports too, no doubt. See above. I want that stuff in a central place, not scattered about. All that analysis gets done on the log host, not on the clients. > As I understand it, SMTP is a store-and-forward proposition, Since some > MUAs (and in particular the mail command) cannot handle failure, then > the MTA _must_ accept the initial submission. No, it doesn't *have* to. It's *desirable*, but an implementation that does not queue is completely conformant to the SMTP protocol spec if it does not do so. The SMTP protocol is connection-oriented like all the other TCP services -- no store and forward assumption at all. Queueing is a feature that is implemented by particular applications that provide the protocol support, but is not required by the spec. Is queuing useful? Sure. Is it required? No. I will agree that *if* you are using mail as a transport for other semantic data (since Unix never really developed the idea of a real sender-initiated file transfer capability like NJE, thus used mail/uucp to substitute), then you want mail to queue, but that's a implementation detail/decision, not a requirement. I think we are looking at two different philosophies of how to do system management here. I'm from the "collect it all in one place and analyze it there" school, you're from the more distributed analysis school. Neither are wrong; they just start from different assumptions. ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
