jqj@duff.uoregon.edu (JQ Johnson) (04/06/91)
In the recently posted FAQ appears the advice that people should use the (otherwise undocumented?) LOCKF option when building mh 6.7. After I read the FAQ, I looked at the code, found that the option did in fact exist (basically, it means that Unix-style locking uses mandatory lockf() instead of flock()), and rebuilt my mh 6.7.1 distribution for my set of SPARCstations running SunOS 4.1.1. We run with an NFS-shared /var/spool/mail, so lockf() semantics (being global to the NFS system) are in principal better than flock. First thing I noticed was that zotnet/mts/lock.c didn't compile. In SunOS 4.1.1 you need to include <sys/unistd.h> to get the symbol F_ULOCK. OK, easy to add... Almost immediately after rebuilding I started seeing problems; whenever a workstation crashed it would result in a hung lock, forcing me to kill and restart rpc.lockd and rpc.statd on the server for /var/spool/mail. Worse, I presume that /bin/mail (which sendmail calls to do delivery) uses *.lock style locking, so the major potential contention problem on one's maildrop is not addressed with LOCKF-style locking. I've rolled back. Have other people using Suns been using the LOCKF option? With what success? I note that the option uses *mandatory* locks, a feature that Sun strongly deprecates. Bottom line is that I believe that the FAQ is wrong, and that at least on SunOS one should *not* define LOCKF and should use LOK_BELL instead. So, I recommend in mtstailor: lockstyle: 1 -- JQ Johnson Director of Network Services Internet: jqj@oregon.uoregon.edu University of Oregon voice: (503) 346-1746 250E Computing Center BITNET: jqj@oregon Eugene, OR 97403-1212 fax: (503) 346-4397
wohler@sapwdf.UUCP (Bill Wohler) (04/25/91)
[this was posted a while ago, but i don't think it hit the airwaves. --bw] folks, the section in the FAQ about compiling options generated some controversy this month. first, regarding ATZ: From: Tony Landells <ahl@technix.oz.au> Yes; very pretty. How unfortunate that timezone names are so ambiguous, so that EST can be interpreted, at a minimum, as (American) Eastern Standard Time, (Australian) Eastern Standard Time, or (Australian) Eastern Summer Time (and yes, I think it's dumb having the same acronym for both normal and Summer time, but that's a different problem). While the numeric timezones may not look as nice, they are, at least, reasonably unambiguous. I would urge anyone who ever intends/hopes/expects to use e-mail outside the U.S. to NOT use ATZ (sorry Stephen). my feelings were that they are coming out with better, less ambigous timezone names such as PDT8PST and MET-1DST (the two that are close to my heart), although the ATZ implementations i've seen seem to use the older, shorter, ambiguous terms. thus, my question is this: should we modify the FAQ text on ATZ as per above, or modify the sources to use better timezone names? secondly, you've all just read about mr. johnson's experience with LOCKF. was this a singular experience, or is this true on everybody's sun? should the FAQ be amended to include the following: Bottom line is that I believe that the FAQ is wrong, and that at least on SunOS one should *not* define LOCKF and should use LOK_BELL instead. So, I recommend in mtstailor: lockstyle: 1 yer 'umble servant, -- --bw ----- Bill Wohler <wohler@sap-ag.de> <sapwdf!wohler> Heidelberg Red Barons Ultimate Frisbee Team
gildea@EXPO.LCS.MIT.EDU (Stephen Gildea) (04/26/91)
Sounds to me like we should just leave all mention of options out of the FAQ. The MH authors knew what they were doing when they made them options, because what is an obvious setting for one site seems not to be at all appropriate for another. Or perhaps the FAQ should expand on the mh-gen information on options and discuss the pros and cons and general experience people have had with various settings, without making recommendations. The international perspective on ATZ should be added to the mh-gen manual page. < Stephen
kre@cs.mu.oz.au (Robert Elz) (04/27/91)
wohler@sapwdf.UUCP (Bill Wohler) writes: > my feelings were that they are coming out with better, less > ambigous timezone names such as PDT8PST and MET-1DST These things aren't timezone names, they're timezone specifications, ie: they're uses on Sys V type systems in the TZ environment variable to tell the ctime() type library functions what timezone your system is in. > or modify the sources to use better timezone names? You can't do that - rfc822 is very explicit on which timezones are legal in mail headers. There's actually nothing at all ambiguous about a legal rfc822 date header, with or without an ascii timezone name. The problem is that rfc822 is very (VERY) US-centric in this, the rest of the world was just forgotten. If you're not in the US, you MUST use numeric zone specifications (except if you're GMT). As a general principle, it would probably be better if everyone just switched to use the numeric zone names for transmission (its just fine for mail readers to display the zone as a name, using whatever local conventions make sense). kre