[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
RE: RPM locks on Solaris 9 question
- From: "Dennis McRitchie" <dmcr Princeton EDU>
- To: <rpm-list redhat com>
- Subject: RE: RPM locks on Solaris 9 question
- Date: Thu, 11 Sep 2003 13:05:01 -0400
Jeff,
Re your suggestion to nuke "--enable-posixmutexes", I had followed your lead
from rpm.spec and had run configure with the non-linux options to produce my
build:
CFLAGS="$RPM_OPT_FLAGS" ./configure --prefix=%{__prefix} $WITH_PYTHON \
--without-javaglue
So "--enable-posixmutexes" was not set for my build. Would you expect it to
behave the way it does below in that case?
Thanks,
Dennis
-----Original Message-----
From: Dennis McRitchie [mailto:dmcr@princeton.edu]
Sent: Thursday, September 11, 2003 11:33 AM
To: rpm-list@redhat.com
Subject: RE: RPM locks on Solaris 9 question
Hi Jeff,
I deleted the macros file and ran "rpm --initdb" again. Got the same error,
even though there were now files in the rpm db directory. Here is the
relevant output from truss. rpm is finding __db.001, but fails when doing a
mmap64 on it. It shouldn't be a permissions problem since the same files can
be accessed when locking is disabled via the "private" clause. As you can
see, this build of rpm was configured with a "--prefix=/psr/solaris9".
Does this output suggest anything to you?
Thanks,
Dennis
vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
stat64("/psr/solaris9/var/lib/rpm", 0xFFBFF7B8) = 0
d=0x03E80003 i=13016 m=0040755 l=2 u=44976 g=36 sz=96
at = Sep 10 19:55:15 EDT 2003 [ 1063238115 ]
mt = Sep 10 15:57:28 EDT 2003 [ 1063223848 ]
ct = Sep 10 15:57:28 EDT 2003 [ 1063223848 ]
bsz=8192 blks=0 fs=nfs
mmap(0x00000000, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANON, -1, 0) =
0xF
EE90000
mmap(0x00000000, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANON, -1, 0) =
0xF
EE80000
access("/psr/solaris9/var/lib/rpm", 2) = 0
access("/psr/solaris9/var/lib/rpm/__db.001", 0) = 0
getuid() = 44976 [44976]
getuid() = 44976 [44976]
getgid() = 36 [36]
getgid() = 36 [36]
stat64("/psr/solaris9/var/lib/rpm/DB_CONFIG", 0xFFBFF4D8) Err#2 ENOENT
open64("/psr/solaris9/var/lib/rpm/DB_CONFIG", O_RDONLY) Err#2 ENOENT
stat64("/psr/solaris9/var/lib/rpm/__db.001", 0xFFBFF530) = 0
d=0x03E80003 i=13047 m=0100644 l=1 u=44976 g=36 sz=8192
at = Sep 10 19:55:23 EDT 2003 [ 1063238123 ]
mt = Sep 10 15:45:57 EDT 2003 [ 1063223157 ]
ct = Sep 10 15:45:57 EDT 2003 [ 1063223157 ]
bsz=8192 blks=16 fs=nfs
open64("/psr/solaris9/var/lib/rpm/__db.001", O_RDWR) = 3
fcntl(3, F_SETFD, 0x00000001) = 0
ioctl(3, 0x2000664C, 0x00000001) = 0
fstat64(3, 0xFFBFF5A8) = 0
d=0x03E80003 i=13047 m=0100644 l=1 u=44976 g=36 sz=8192
at = Sep 10 19:55:23 EDT 2003 [ 1063238123 ]
mt = Sep 10 15:45:57 EDT 2003 [ 1063223157 ]
ct = Sep 10 15:45:57 EDT 2003 [ 1063223157 ]
bsz=8192 blks=16 fs=nfs
close(3) = 0
open64("/psr/solaris9/var/lib/rpm/__db.001", O_RDWR) = 3
fcntl(3, F_SETFD, 0x00000001) = 0
ioctl(3, 0x2000664C, 0x00000001) = 0
mmap64(0x00000000, 8192, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0) Err#11
EAGAIN
fstat64(2, 0xFFBFE568) = 0
d=0x00000002 i=210914885 m=0100644 l=1 u=44976 g=36 sz=267331
at = Sep 11 11:04:19 EDT 2003 [ 1063292659 ]
mt = Sep 11 11:04:29 EDT 2003 [ 1063292669 ]
ct = Sep 11 11:04:29 EDT 2003 [ 1063292669 ]
bsz=8192 blks=528 fs=tmpfs
rpmdbwrite(2, " r p m d b", 5) = 5
: write(2, " : ", 2) = 2
mmap: write(2, " m m a p : ", 6) = 6
Resource temporarily unavailablewrite(2, 0xFEFA58E7, 32)
= 32
R e s o u r c e t e m p o r a r i l y u n a v a i l a b l e
write(2, "\n", 1) = 1
close(3) = 0
error: write(2, " e r r o r : ", 7) = 7
db4 error(11) from dbenv->open: Resource temporarily unavailable
write(2, 0x0002E9A0, 65) = 65
d b 4 e r r o r ( 1 1 ) f r o m d b e n v - > o p e n :
R e s o u r c e t e m p o r a r i l y u n a v a i l a b l e
\n
error: write(2, " e r r o r : ", 7) = 7
cannot open Packages index using db3 - Resource temporarily unavailable (11)
write(2, 0x0002E9F0, 77) = 77
c a n n o t o p e n P a c k a g e s i n d e x u s i n g
d b 3 - R e s o u r c e t e m p o r a r i l y u n a v
a i l a b l e ( 1 1 )\n
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-----Original Message-----
From: rpm-list-admin@redhat.com [mailto:rpm-list-admin@redhat.com]On
Behalf Of Jeff Johnson
Sent: Wednesday, September 10, 2003 4:46 PM
To: rpm-list@redhat.com
Subject: Re: RPM locks on Solaris 9 question
Dennis McRitchie wrote:
>Hi Jeff,
>
>I saw your post (pasted below) on another forum about how to resolve a
>"Resource temporarily unavailable" error and have a couple of related
>questions.
>
>I just successfully built and installed rpm 4.2 on Solaris 9 (I gave up on
>debugedit though). When I typed in:
>$ rpm --initdb
>
>
--initdb is mostly a noop these days, might be useful for debugging this
particular
problem, as it creates an environment, opens a database, then closes.
I dunno off hand how many files are created, but file creation will need
write
access to /var/lib/rpm, usually root iss required.
>I got:
>rpmdb: mmap: Resource temporarily unavailable
>error: db4 error(11) from dbenv->open: Resource temporarily unavailable
>error: cannot open Packages index using db3 - Resource temporarily
>unavailable (11)
>
>
Hmmm, something in Berkeley DB (or rpm's config thereof) is breaking.
Throw truss on that, see if you can't find what syscall is failing.
>
>Then I tried:
>$ rpm --rebuilddb
>
>and got:
>rpmdb: mmap: Resource temporarily unavailable
>error: db4 error(11) from dbenv->open: Resource temporarily unavailable
>error: cannot open Packages index
>
>Both before and after these commands, there were no files in /var/lib/rpm.
>So I followed your final piece of advice below and created a macros file
with:
>%__dbi_cdb create cdb mpool mp_mmapsize=16Mb mp_size=1Mb private
>
>
private disables locking in Berkeley DB, uses malloc'd memory iirc.
>and then retried:
>$ rpm --initdb
>
>This time it worked and __db.001 and Packages were created in var/lib/rpm.
>
>My questions are:
>1) What are the implications of disabling concurrent access locks, and
>re-enabling fcntl(2)
>lock on packages? This build of rpm and all related files are on a mounted
>file system. If multiple users (mounting this file system from different
>machines) were to try to install packages on their local systems at the
same
>time, would this be a problem?
>
You can probably live with no rpmdb locking, rpm-4.0.[34] essentially had no
locking
and the world did not darken ;-)
Most database access is readonly, your likeliest failure is a segfault from
reading
a data structure that was being written by concurrent install. Still,
figgering the
mmap problem is better, it can't be that hard to fix. Try running the tcl
test scripts,
see if that has the same problem.
>2) If I were to subsequently upgrade to kernel+NPTL and glibc+NPTL, then
>what do I need to do to go back to concurrent access locks? Just remove the
>newly created macros file?
>
>
>
Hmmm, you've switched platforms here somehow. Removing the macros file will
use the default configuration, which uses concurrent locks.
rpm cares about NPTL only through Berkeley DB, there are 2 occurences
of --enable-posixmutexes
used to configure Berkely DB. Nuke those, and don't worry about NPTL. You
will lose unified
thread/process locks and you won't care.
Note that you must build on a NPTL system with --enable-posixmutexes,
there's a test
deep in Berkely DB configure that needs to be run on a NPTL enabled build
system.
HTH
73 de Jeff
_______________________________________________
Rpm-list mailing list
Rpm-list@redhat.com
https://www.redhat.com/mailman/listinfo/rpm-list
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
[]