headers
mark.heather | 1 Sep 2003 14:27

lock between nnrpd and expireover

(First posting to inn-workers <at> isc.org)
I cant see this covered in previous postings so will raise as a new query...

I have recently migrated from an older version of inn to inn2.4 on seperate servers (Solaris 2.6). Using
cnfs for storage and tradindexed for overview method.

All works fine with no reported feed or client problems.

However, the following error fills up my news.daily report each night :

expireover: tradindexed: cannot lock group entry at 65544: Resource temporarily unavailable
expireover: tradindexed: cannot unlock group entry at 65544: Resource temporarily unavailable
expireover: tradindexed: cannot lock group entry at 65616: Resource temporarily unavailable
expireover: tradindexed: cannot unlock group entry at 65616: Resource temporarily unavailable
expireover: tradindexed: cannot lock group entry at 65688: Resource temporarily unavailable
and so on for several megabytes.

Truss'ing the expireover process, the process is trying to get a lock on the file
./news/spool/overview/groups.index but all the nnrpd processes also have a lock on this file. This
causes the lock acquisition fail and the error message generated.

I can't see what would cause it to fail. It might be that there are some compile time options that are the root
cause, but at the minute I can't explain it.

Perhaps I need to throttle INN first and then expireover. It could be that INN is holding a exclusive lock
whilst the nnrpd's are only holding minor locks.

Many thanks

Mark Heather
(Continue reading)

Permalink | Reply | 2 comments |
headers
Travis Farmer | 1 Sep 2003 15:59

Duplicate matches in readers.conf, and limit binaries to only binary groups

ok, two questions.
first, and I suspect I know the answer, but I wanted to confirm it before I
broke the configuration.

will an authenticated user be able to match more than one auth/access pair
and take the settings from each. now, first, perhaps my method of using an
auth, and an access field for each match is "unclean" so to speak, but it
seems to work, and does not pose a performance problem, as of yet.
here are some examples (in the layout I use, but exact settings not in
effect).
----------------
auth "public" {
        hosts: "*"
        auth: "ckpasswd -f /etc/news/nnrp.passwd"
        default: "public"
}
access "public" {
        users: "*"
        newsgroups: "local.notices"
        access: "R"
}

auth "administrator" {
        hosts: "*"
        auth: "ckpasswd -f /etc/news/nnrp.passwd"
}
access "administrator" {
        users: "admin"
        newsgroups: "*"
        access: "RPA"
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jeffrey M. Vinocur | 1 Sep 2003 19:06

Re: Duplicate matches in readers.conf, and limit binaries to only binary groups

On Mon, 1 Sep 2003, Travis Farmer wrote:

> will an authenticated user be able to match more than one auth/access pair
> and take the settings from each. now, first, perhaps my method of using an
> auth, and an access field for each match is "unclean" so to speak, but it
> seems to work, and does not pose a performance problem, as of yet.

There's absolutely no point to the three auth groups you have.  (I wonder 
sometimes if this would've been more clear if we put auth groups and 
access groups in two config files -- think of it that way if it helps 
you.)  

Only the first auth group with an appropriate hosts: line will be used.  
Similarly, only one access group will be used -- there's presently no
support in readers.conf for taking the "union" of all matching access
groups (but if you need this functionality, it's pretty easy to do with 
the Python hooks).

> access "public" {
>         users: "*"
>         newsgroups: "local.notices"
>         access: "R"
> }

Better to use "read: local.notices" and "post: !*" here and get rid of the 
access: line entirely.

> access "administrator" {
>         users: "admin"
>         newsgroups: "*"
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jeffrey M. Vinocur | 1 Sep 2003 19:08

Re: lock between nnrpd and expireover

On Mon, 1 Sep 2003 mark.heather <at> btinternet.com wrote:

> expireover: tradindexed: cannot lock group entry at 65544: Resource temporarily unavailable
> 
> Truss'ing the expireover process, the process is trying to get a lock on the file
./news/spool/overview/groups.index but all the nnrpd processes also have a lock on this file. This
causes the lock acquisition fail and the error message generated.

Huh.

> I can't see what would cause it to fail. It might be that there are some
> compile time options that are the root cause, but at the minute I can't
> explain it.

Did you do anything really strange with the compile options?

> Perhaps I need to throttle INN first and then expireover. It could be
> that INN is holding a exclusive lock whilst the nnrpd's are only holding
> minor locks.

It shouldn't -- you're running expireover in the usual way (via 
news.daily), right?

--

-- 
Jeffrey M. Vinocur
jeff <at> litech.org
Permalink | Reply | 0 comments |
headers
Russ Allbery | 1 Sep 2003 19:47
Picon
Favicon
Gravatar

Re: lock between nnrpd and expireover

mark heather <mark.heather <at> btinternet.com> writes:

> I have recently migrated from an older version of inn to inn2.4 on
> seperate servers (Solaris 2.6). Using cnfs for storage and tradindexed
> for overview method.

> All works fine with no reported feed or client problems.

> However, the following error fills up my news.daily report each night :

> expireover: tradindexed: cannot lock group entry at 65544: Resource temporarily unavailable
> expireover: tradindexed: cannot unlock group entry at 65544: Resource temporarily unavailable
> expireover: tradindexed: cannot lock group entry at 65616: Resource temporarily unavailable
> expireover: tradindexed: cannot unlock group entry at 65616: Resource temporarily unavailable
> expireover: tradindexed: cannot lock group entry at 65688: Resource temporarily unavailable
> and so on for several megabytes.

> Truss'ing the expireover process, the process is trying to get a lock on
> the file ./news/spool/overview/groups.index but all the nnrpd processes
> also have a lock on this file. This causes the lock acquisition fail and
> the error message generated.

Each nnrpd process only locks the region of the file corresponding to the
current group, and expireover locks the region of the file corresonding to
the group that it's currently expiring.  So they shouldn't have that sort
of contention.  Plus, even if the locks do contend, expireover should
block waiting for the lock, not have fcntl return EAGAIN (which appears to
be what's happening).

I must admit I've not tested this specifically on Solaris 2.6, but I
(Continue reading)

Permalink | Reply | 0 comments |
headers
Philippe NAKACHE | 2 Sep 2003 11:01

invalid peername

Bonjour,

J'ai un message d'erreur du type invalid peername "nom du NG" dans news.err.

Quelq'un sait il à quoi cela correpond ??

Merci d'avance,

Philippe NAKACHE
Permalink | Reply | 10 comments |
headers
Jeffrey M. Vinocur | 2 Sep 2003 12:10

Re: invalid peername

On Tue, 2 Sep 2003, Philippe NAKACHE wrote:

> J'ai un message d'erreur du type invalid peername "nom du NG" dans news.err.

You can't have spaces in peer entries (in the newsfeeds file).

If "nom du NG" is what you want to call your peer, try "nom-du-NG" 
instead.

--

-- 
Jeffrey M. Vinocur
jeff <at> litech.org
Permalink | Reply | 9 comments |
headers
Philippe NAKACHE | 2 Sep 2003 12:48

RE: invalid peername

No, "nom du NG" is a newsgroup

-----Message d'origine-----
De : Jeffrey M. Vinocur [mailto:jeff <at> puck.litech.org]De la part de
Jeffrey M. Vinocur
Envoye : mardi 2 septembre 2003 12:11
A : Philippe NAKACHE
Cc : inn-workers <at> isc.org
Objet : Re: invalid peername

On Tue, 2 Sep 2003, Philippe NAKACHE wrote:

> J'ai un message d'erreur du type invalid peername "nom du NG" dans
news.err.

You can't have spaces in peer entries (in the newsfeeds file).

If "nom du NG" is what you want to call your peer, try "nom-du-NG"
instead.

--
Jeffrey M. Vinocur
jeff <at> litech.org
Permalink | Reply | 8 comments |
headers
Pavel V. Knyazev | 2 Sep 2003 13:04
Picon

Re: invalid peername

Montrez nous un morceau de votre news.err.
Il n'y a pas de télépats ici :-\
Peername est le nom de votre peer, pas le nom de newsgroup.

Jeff, "nom du NG" is "name of NG".
I don't know what is NG, probably newsgroup?

--
Pavel V. Knyazev

----- Original Message ----- 
From: "Philippe NAKACHE" <pnakache <at> wanadoo.com>
To: "Jeffrey M. Vinocur" <jeff <at> litech.org>
Cc: <inn-workers <at> isc.org>
Sent: Tuesday, September 02, 2003 4:48 PM
Subject: RE: invalid peername

> No, "nom du NG" is a newsgroup
>
> -----Message d'origine-----
> De : Jeffrey M. Vinocur [mailto:jeff <at> puck.litech.org]De la part de
> Jeffrey M. Vinocur
> Envoye : mardi 2 septembre 2003 12:11
> A : Philippe NAKACHE
> Cc : inn-workers <at> isc.org
> Objet : Re: invalid peername
>
>
> On Tue, 2 Sep 2003, Philippe NAKACHE wrote:
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jeffrey M. Vinocur | 2 Sep 2003 13:27

RE: invalid peername

On Tue, 2 Sep 2003, Philippe NAKACHE wrote:

> No, "nom du NG" is a newsgroup

Well, you have a peer name (the first field of an entry in 
$pathetc/newsgroups) with an invalid character.  The only valid characters 
are letters, numbers, '-', '_', and '.'.

Please send the actual error message exactly if you still have trouble.

--

-- 
Jeffrey M. Vinocur
jeff <at> litech.org
Permalink | Reply | 6 comments |

Gmane