pete@fidata.fi (Petri Helenius) (04/19/91)
Is it: A) already implemented B) planned to be implemented that C-news software be capable of removing stale locks on the fly? It should check the existence of the lock owner process and the if it's not existent, remove that lock and wait for 5 seconds and try to lock it again. This should be a feature #defineable to off, because people run news with nfs-mounted servers and there this could cause a mass trashing. Our site is working well and this is not a problem for our machines but our upstream site gets stale locks from time to time and this cuts our newsfeed quite badly. -- -- Petri Helenius, Fimeko-Data Oy Phone +358-0-458 2421, Telefax +358-0-458 2425, Mobile: +358-49-410 863 Internet pete@fidata.fi, Snail: Hollantilaisentie 36, 00330 HKI, FINLAND Looking for Unix(r) FAX-system ? Mail queries to unifax@fidata.fi
henry@zoo.toronto.edu (Henry Spencer) (04/19/91)
In article <PETE.91Apr18203829@fidata.fi> pete@fidata.fi writes: > Is it: >A) already implemented >B) planned to be implemented > that C-news software be capable of removing stale locks on the fly? Neither. This is documented in doc/interface and notebook/bdiffs. Failure of a locking protocol indicates that something is badly wrong. Blindly removing the lock and charging onward can be a terrible mistake. We prefer to alert the administrator (via "newswatch") and let him sort it out. A side issue here is that one reason for having a lock persist for a long time is that the administrator is working on the news system. >It should check the existence of the lock owner process... There is no portable way to do this. Especially in the presence of network file systems. >our upstream site gets stale locks from time to time and this cuts our >newsfeed quite badly. They need to investigate *why* they are getting stale locks. C News does not do that. Something is wrong. -- And the bean-counter replied, | Henry Spencer @ U of Toronto Zoology "beans are more important". | henry@zoo.toronto.edu utzoo!henry
peter@taronga.hackercorp.com (Peter da Silva) (04/20/91)
henry@zoo.toronto.edu (Henry Spencer) writes: > They need to investigate *why* they are getting stale locks. C News does > not do that. Something is wrong. We get stale locks when the network file system loses a connection to the news host machine. I'm not sure what we can do about it other than have a human to occasionally give an enema to the news system. Suggestions would be appreciated. -- (peter@taronga.uucp.ferranti.com) `-_-' 'U`
henry@zoo.toronto.edu (Henry Spencer) (04/21/91)
In article <Q7F3W5C@taronga.hackercorp.com> peter@taronga.hackercorp.com (Peter da Silva) writes: >We get stale locks when the network file system loses a connection to the >news host machine. I'm not sure what we can do about it other than have >a human to occasionally give an enema to the news system... Our recommendation these days is that news processing should run on the machine which has the disks, unless you have a network file system that provides correct Unix filesystem semantics. In particular, doing the processing over an NFS connection is just too trouble-prone, due to NFS's propensity for random misbehavior and semantic botches. Reading news over NFS is no problem -- NFS works acceptably as a read-only medium -- but manipulating files over it is a mistake. -- And the bean-counter replied, | Henry Spencer @ U of Toronto Zoology "beans are more important". | henry@zoo.toronto.edu utzoo!henry
peter@taronga.hackercorp.com (Peter da Silva) (04/21/91)
urlichs@smurf.sub.org (Matthias Urlichs) writes: > If that network file system connection isn't reliable enough, it seems that > there's a danger of something breaking in a bad way I'm aware of this. We only do batching remotely: we rexec (similar to rsh) rnews for incoming batches. The reason for doing the batching remotely is to minimise the loss if a network connection drops: the worst that can happen is a duplicate batch and a batch lock hanging around until someone notices. Doing it the other way (for example, rexecing uux) leads to lost batches. -- (peter@taronga.hackercorp.com) `-_-' 'U`
peter@taronga.hackercorp.com (Peter da Silva) (04/21/91)
henry@zoo.toronto.edu (Henry Spencer) writes: > processing over an NFS connection is just too trouble-prone, due to NFS's > propensity for random misbehavior and semantic botches. Reading news > over NFS is no problem -- NFS works acceptably as a read-only medium -- > but manipulating files over it is a mistake. That's OK. I wouldn't touch NFS with a ten foot pole. I'm using Intel's OpenNET NFA which handles everything, including locking, named pipes, everything except shared memory. In this case we have modems on one machine and the News disks on another, and it's better to have duplicates and occasional locks hanging than losing batches. "networked file systems" is not yet equivalent to "NFS". Thank the deity of your choice for that. -- (peter@taronga.hackercorp.com) `-_-' 'U`
news@ideal.id.dk (Nick Sandru (news adm)) (04/22/91)
peter@taronga.hackercorp.com (Peter da Silva) writes: >We get stale locks when the network file system loses a connection to the >news host machine. I'm not sure what we can do about it other than have >a human to occasionally give an enema to the news system. Suggestions >would be appreciated. >-- > (peter@taronga.uucp.ferranti.com) > `-_-' > 'U` I made a script which cleans locks older than a preset interval (12 - 24 hours) and old articles which may have been left out by an aborted expire. It worked fine during the last 5 - 6 months Long Haired Nick -- | Nick Sandru (alias Long Haired Nick) | Backpacker's First Law: | Hoje Topholm 37 | e-mail: | "The thing you need lies either | DK-3390 Hundested | ns@iddth.id.dk | in the bottom of your backpack, | Denmark | news@iddth.id.dk | or in a closet at your home..."