gary@proa.sv.dg.com (Gary Bridgewater) (12/05/90)
In article <1088@ai.cs.utexas.edu> fletcher@cs.utexas.edu (Fletcher Mattox) writes: >Speaking of B news locking, what prevents concurrent instances >of rnews from writing simultaneously to the history file? A quick >look at the code suggests savehist() could be doing this. It happens via lock() and unlock() in ifuncs.c. This locks - using whatever mechanism you have - /usr/lib/news/sys. It's called, generally, by localize() as the article is going to be posted. If you run multiple unbatches / rnews' make sure this locking works. And don't fool with sys (or active) while its running. From experience - don't run any "clean out junk" script that dinks with active while unbatching - unless it locks sys as well. I've been running up to 4 rnews processes at a time for a few weeks - under B - and haven't seen any problems. -- Gary Bridgewater, Data General Corporation, Sunnyvale California gary@sv.dg.com or {amdahl,aeras,amdcad}!dgcad!gary C++ - it's the right thing to do.
fletcher@cs.utexas.edu (Fletcher Mattox) (12/06/90)
In article <660393258.3719@proa.sv.dg.com> gary@proa.sv.dg.com (Gary Bridgewater) writes: >In article <1088@ai.cs.utexas.edu> fletcher@cs.utexas.edu (Fletcher Mattox) writes: >>Speaking of B news locking, what prevents concurrent instances >>of rnews from writing simultaneously to the history file? A quick >>look at the code suggests savehist() could be doing this. > >It happens via lock() and unlock() in ifuncs.c. This locks - using whatever >mechanism you have - /usr/lib/news/sys. >It's called, generally, by localize() as the article is going to be posted. I don't think so. lock() and unlock() are used in three places: 1. to protect the active file in localize(), as you note. 2. to protect the active file in c_newgroup(), when newgroups are created. 3. to protect the sequence file in getident(), to create unique message id. I'm concerned about the call to savehist() from insert(). lock() doesn't protect this, as best I can tell. I think B news history files are routinely getting corrupted, but the damage is minimal because the file is opened for append and probably only the last entry is getting munged. And most folks just don't notice. If true, then the dbm files are subject to the same problem. Like UUNET, I've recently converted to dbz. I'm wondering if dbz's hashing scheme might be more sensitive to this kind of corruption than dbm's was. I.e. could an ill-timed store() screw the entire data base? Unless someone can show me where concurrent writes to the history file are prevented, I'll add the code to do that.
rees@pisa.ifs.umich.edu (Jim Rees) (12/07/90)
In article <15491@cs.utexas.edu>, fletcher@cs.utexas.edu (Fletcher Mattox) writes:
I'm concerned about the call to savehist() from insert().
lock() doesn't protect this, as best I can tell.
The history file can't get corrupted by multiple instantiations of i/rnews,
since it only gets appended to. The expire program makes a copy then
renames, so that isn't a problem either.
The dbm files are another matter. Many years ago I fixed my inews to lock
the dbm files, more out of paranoia than out of any evidence of corruption.
I don't know if my fixes ever made it into the "official" sources. I don't
run B news any more.gary@proa.sv.dg.com (Gary Bridgewater) (12/07/90)
In article <15491@cs.utexas.edu> fletcher@cs.utexas.edu (Fletcher Mattox) writes: >I'm concerned about the call to savehist() from insert(). >lock() doesn't protect this, as best I can tell. Mea culpa. -- Gary Bridgewater, Data General Corporation, Sunnyvale California gary@sv.dg.com or {amdahl,aeras,amdcad}!dgcad!gary C++ - it's the right thing to do.