bms@mitisft.Convergent.COM (Bruce Schlobohm) (07/25/90)
Re: SVR3.2 system running elm 2.3 PL4
Has anyone noticed any problems running newalias while other users
are using aliases from the database? A few users have complained about
addressing problems that they have traced back to the sys admin running
newalias during the day. The problems have reportedly stopped since
changing the rules to have newalias only run after hours.
After quick scan of the code, I don't see any interlocking during the
time that newalias is rebuilding the database.
Is this a problem?
Sorry for being a bit sketchy on the exact nature of the addressing problems:
other factors are involved, such as a mail gateway to a non-unix system.
But it does appear to be possible for newalias and elm to collide on the
use of aliases.data/aliases.hash.
--
Bruce Schlobohm
bms@Convergent.COM -or- {pyramid,sri-unix,pacbell}!ctnews!bmsscs@lokkur.dexter.mi.us (Steve Simmons) (07/26/90)
bms@mitisft.Convergent.COM (Bruce Schlobohm) writes: >Has anyone noticed any problems running newalias while other users >are using aliases from the database? A few users have complained about >addressing problems that they have traced back to the sys admin running >newalias during the day. The problems have reportedly stopped since >changing the rules to have newalias only run after hours. I believe your diagnosis (system alias file not locked during modification) is correct. I also believe that a global system alias file *as part of elm* (note that clause) is a bad idea. On BSD-based system I put global aliases into the sendmail aliases, on SysV I use smail and it's alias files. Why? Because some of my users prefer other mailers and we don't force them to use elm. Putting those aliases with the transport agent rather than the user agent makes them accessible in a manner independant of elm, mush, mailtool, mh, fill-in-the-blank. Yes, there are advantages to global elm aliases. But in my book they're outweighed by the disadvantages (aside from the bug you found).