| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 26 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 54:03:20 |
| Calls: | 632 |
| Files: | 1,187 |
| D/L today: |
27 files (19,977K bytes) |
| Messages: | 178,944 |
While injecting articles INN will suddenly use 100% CPU and stop logging
for several minutes. This has happened a few times and usually recovers
on its own after 5-15 minutes.
Sep 4 06:28:38 spool1 innd[43822]: tradspool: could not symlink /usr/ local/news/spool/articles/rec/arts/comics/marvel/xbooks/47149 to /usr/ local/news/spool/articles/rec/arts/comics/info/296: File exists
Sep 4 06:28:38 spool1 innd[43822]: SERVER cant store article: File exists Sep 4 06:33:47 spool1 innd[43822]: tradspool: could not open /usr/local/ news/spool/articles/rec/arts/comics/info/298: File exists
Sep 4 06:33:47 spool1 innd[43822]: SERVER cant store article: File exists Sep 4 06:33:47 spool1 innd[43822]: tradspool: could not symlink /usr/ local/news/spool/articles/rec/arts/comics/marvel/xbooks/47152 to /usr/ local/news/spool/articles/rec/arts/comics/info/300: File exists
Sep 4 06:33:56 spool1 innd[43822]: SERVER throttle File exists writing SMstore file -- throttling
Sep 4 06:33:56 spool1 innd[43822]: SERVER cant store article: File exists
In the past I added newsgroups, which no longer exist in the Big 8, and injected articles to those groups. At the time I did not have control.ctl configured not to process rmgroup commands, and groups got removed through processing checkgroups. It was after re-adding these groups and attempting to inject articles to them I see the issue.
I'm not sure what the 'right' approach is to correcting.
What I see is articles arrive which are cross-posted to one of the
groups that had been removed and re-added, and the X-Ref on the new
article is using an article number that already exists in the
cross-posted group.
Jesse Rehmer <jesse.rehmer@blueworldhosting.com> writes:
While injecting articles INN will suddenly use 100% CPU and stop logging
for several minutes. This has happened a few times and usually recovers
on its own after 5-15 minutes.
Do you use Perl filters? An out-of-control regex would be my first
suspect since they're prone to combinatorial explosion if written poorly.
INN under normal operations should not use much CPU. It's usually
constrained by disk I/O.
Russ Allbery <eagle@eyrie.org> writes:
Jesse Rehmer <jesse.rehmer@blueworldhosting.com> writes:
While injecting articles INN will suddenly use 100% CPU and stop
logging for several minutes. This has happened a few times and usually
recovers on its own after 5-15 minutes.
Do you use Perl filters? An out-of-control regex would be my first
suspect since they're prone to combinatorial explosion if written
poorly.
INN under normal operations should not use much CPU. It's usually
constrained by disk I/O.
Oh, also, I should say explicitly that I don't think these two problems
are related. Conflicting article numbers in tradspool storage should
result in an immediate throttle, and I don't see any obvious reason why
it would cause a CPU spike. It's also not a recoverable problem; I
believe INN always throttles in that situation until an administrator unthrottles it.
Jesse Rehmer <jesse.rehmer@blueworldhosting.com> writes:
While injecting articles INN will suddenly use 100% CPU and stop
logging for several minutes. This has happened a few times and usually
recovers on its own after 5-15 minutes.
Do you use Perl filters? An out-of-control regex would be my first
suspect since they're prone to combinatorial explosion if written
poorly. INN under normal operations should not use much CPU. It's
usually constrained by disk I/O.
On Thu, 04 Sep 2025 10:04:04 -0700, Russ Allbery wrote:
Russ Allbery <eagle@eyrie.org> writes:
Jesse Rehmer <jesse.rehmer@blueworldhosting.com> writes:
While injecting articles INN will suddenly use 100% CPU and stop
logging for several minutes. This has happened a few times and
usually recovers on its own after 5-15 minutes.
Do you use Perl filters? An out-of-control regex would be my first
suspect since they're prone to combinatorial explosion if written
poorly.
INN under normal operations should not use much CPU. It's usually
constrained by disk I/O.
Oh, also, I should say explicitly that I don't think these two problems
are related. Conflicting article numbers in tradspool storage should
result in an immediate throttle, and I don't see any obvious reason why
it would cause a CPU spike. It's also not a recoverable problem; I
believe INN always throttles in that situation until an administrator
unthrottles it.
It didn't throttle for over an hour as seen from the full output of
news.err below. It ran into the error at roughly 5:00am but did not
throttle until 6:33am.
It didn't throttle for over an hour as seen from the full output of
news.err below. It ran into the error at roughly 5:00am but did not
throttle until 6:33am.
Since the issue involves tradspool and Xref problems, would a feasible workaround be to stand up a new box (with CNFS this time) and re-feed
all articles to the new box? Wouldn't that generate new/correct Xref
headers if I don't use xrefslave?
I rarely run expire/expireover on this box, as I don't intend to removeI remember this can be a performance problem with massive imports.
any articles,...
When you delete a group, you need to delete all the files out of the
spool for that group before you re-add the group. That's because
deleting the group removes the entry from the active file, which in turn discards the article number high water mark. When you re-add the group, article numbering starts over at 1, so if you leave stray article files behind in the spool, you will encounter this problem.
Normally nightly expire deletes all the articles for removed groups. I'm guessing that you have this turned off for some reason? INN with
group-based expire (which drives expire based on the overview) only gets
one chance to do that because on the next run of expire it will clean up
all of the overview and then lose track of the files in the file system entirely. Normally this will also trigger deletion of all of the
articles.
What would happen if groups are removed and re-added with CNFS buffers?
When you re-add the groups would you need to immediately rebuild the overview?
Jesse Rehmer <jesse.rehmer@blueworldhosting.com> writes:
What would happen if groups are removed and re-added with CNFS buffers?
When you re-add the groups would you need to immediately rebuild the
overview?
CNFS effectively deletes all of the articles as soon as you rmgroup the group, I think. The data is still in the buffer, but the pointers to it
are removed. So this works as if the group were removed and readded
after deleting all of the articles: Article numbers start at 1 again,
and the old articles aren't accessible.
On Thu, 04 Sep 2025 12:11:47 -0700, Russ Allbery wrote:
CNFS effectively deletes all of the articles as soon as you rmgroup the
group, I think. The data is still in the buffer, but the pointers to it
are removed. So this works as if the group were removed and readded
after deleting all of the articles: Article numbers start at 1 again,
and the old articles aren't accessible.
If this same situation happened with CNFS, where you remove a group then re-add it... would rebuilding the history/overview find those articles if the pointers to them are gone, or would it only find articles that were crossposted to other groups that weren't deleted?
Another scenario... Let's say comp.sys.apple existed with articles crossposted to comp.sys.apple2. I remove comp.sys.apple. The crossposted articles would still be accessible at this point.
If I did *not* rebuild the overview data, and re-add comp.sys.apple and inject articles posted to comp.sys.apple2 that are also crossposted to comp.sys.apple, what happens on CNFS?
I assume that the article would still be stored, but potentially with incorrect Xref information regarding the crossposted group?
If I did *not* rebuild the overview data, and re-add comp.sys.apple and
inject articles posted to comp.sys.apple2 that are also crossposted to
comp.sys.apple, what happens on CNFS?
You get duplicate copies of the articles with new numbers in
comp.sys.apple2.
On Thu, 04 Sep 2025 13:57:44 -0700, Russ Allbery wrote:
You get duplicate copies of the articles with new numbers in
comp.sys.apple2.
Would those duplicate articles create a problem for tools like
makehistory?
If I did *not* rebuild the overview data, and re-add comp.sys.apple and
inject articles posted to comp.sys.apple2 that are also crossposted to
comp.sys.apple, what happens on CNFS?
You get duplicate copies of the articles with new numbers in
comp.sys.apple2.
Russ Allbery <eagle@eyrie.org> wrote:
If I did *not* rebuild the overview data, and re-add comp.sys.apple and >>> inject articles posted to comp.sys.apple2 that are also crossposted to
comp.sys.apple, what happens on CNFS?
You get duplicate copies of the articles with new numbers in
comp.sys.apple2.
Wouldn't they be rejected based on history? They're still in c.s.apple2 after all...
Just thinking loud.