Closed #232.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/232#event-3160168125___
Rpm-maint mailing list
Making BDB more reliable would require using transactions there, but this would
be an incompatible change, which is the last thing we want to do at this point
when we're basically just about to deprecate BDB. Which means we cannot do
anything about this, on Berkeley DB backend, unfortunately.
In the process of testing dcrpm, when I execute the command line lsof - F p
/var/lib/rpm/.dbenv.lock, lsof displays the PIDs of all processes, including 1,
instead of only displaying the PIDs of the .dbenv.lock file;
It may have been generated after I installed typing (Python module)
Yes, it should work just fine. We actually have packaging for dcrpm at
https://github.com/facebookincubator/rpm-backports/tree/master/rpms/dcrpm that
we use on CentOS 7 (and macOS) with no issues.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly
@jaymzh I see that dcrpm used typing(begin python-3.5 as a new feature added)
, but my project is running on centos 7.5 1804 and using the python 2.7.5
version, Is typing(dcrpm) compatible with Python 2.7.5?
--
You are receiving this because you are subscribed to this thread.
Reply to this
You could instead run it as nonroot: `su -c "rpm -q " nobody` (or
possibly `su -c "rpm -q " -s /bin/bash nobody` if nobody's shell is
not a real shell).
Or you can make sure [dcrpm](https://github.com/facebookincubator/dcrpm) runs
in a regular basis to detect and correct your RPM db... but
Can not avoid it?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/232#issuecomment-557374397___
Rpm-maint mailing list
@jaymzh Yes, the processes running as root account.
`the memmap() the DB read-write, and write it back out when they are done...
hence if then something changes at the same time, one of those process can
write back old pages.`
`# ls -lthra /var/lib/rpm
total 70M
-rw-r--r--. 1 root root0
@jianwei1216 Are the processes running as root? If so, the memmap() the DB
read-write, and write it back out when they are done... hence if then something
changes at the same time, one of those process can write back old pages.
--
You are receiving this because you are subscribed to this
Recently, I have encountered similar problems in my CentOS 7 environment.
`[root@controller-3 ~]# uname -a
Linux controller-3 3.10.0-862.el7.x86_64 #1 SMP Fri Apr 20 16:44:24 UTC 2018
x86_64 x86_64 x86_64 GNU/Linux
[root@controller-3 ~]# cat /etc/redhat-release
CentOS Linux release 7.5.1804
Guesses are worthless, particularly when you haven't the time to identify your
problem.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
I'd be very surprised if this wasn't a cause of many of our problems in Linux
too. I suspect a common case is someone querying the DB (`rpm -qa`) when an
transaction happens, and then theoretically-read-only operation ends up writing
stale data back, but I haven't actually had the time to sit
Um, *this* issue is about RPM behavior on OS X and a sandbox policy prohibiting
writes.
Open an issue with details with details about your Facebook problems if you
wish.
The output of db_stat showing the state of locks is usually the starting point
to identifying the root cause.
--
You are
Hence this Issue was filed. :)
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/232#issuecomment-365676303___
Rpm-maint mailing
@jayzmh: the issue with dcrpm is the costly detection and possibly imperfect
analysis of "bad actors" not how often db_recover is run. dcrpm is treating a
symptom rather than solving the root cause of whatever problem exists.
--
You are receiving this because you are subscribed to this
Note that we don't run db_recover unless we detect an issue. dcrpm works by
trying to detect common issues and issue the nicest possible recovery - from
db_recover to other finding held locks by bad actors to other things.
--
You are receiving this because you are subscribed to this thread.
@pmatilai: yup, DB_RECOVER requires configuring Berkeley DB when opening
correctly in order to use.
Hint: execing dbXY_recover on an idle database (already protected by an
exclusive write lock) fixes stale locks. Performing that operation when needed,
not every 15 minutes with a Facebook fork
> DB_RECOVER requires DB_INIT_TXN, which is incompatible with DB_INIT_CDB that
> rpm.org still uses. And enabling TXN on BDB runs into all sorts of fun with
> BDB log file paths across chroots, requires additional infra in the code etc
> and whatnot. All solvable issues no doubt, but it piles
On a related note... our fix-the-rpm-db program has been opensourced:
https://github.com/facebookincubator/dcrpm
We run it every 15 minutes as a pre-script to configuration management.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it
> I can also easily back port the core fix to the problem reported here,
> implemented years ago @rpm5.org:
>
> when DB_RUNRECOVERY is returned opening a BDB dbenv, then do the recovery
> by setting a flag, and repeating the open one time, thereby running recovery.
DB_RECOVER requires
@smorad: db-4.8.30 SHOULD be fine (but there really isn't any reason not to
upgrade to more recent versions on OS X: I have direct personal/devel
experience on OS X with all versions of BDB since db-4.5.x, been there, done
that, WORKSFORME).
--
You are receiving this because you are
We are running `berkeley-db4-4.8.30-0.3`. It may be that a later release of bdb
will contain a fix for this, as I see that we are now 2 major versions behind
bdb stable.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
After looking at current rpm.org sources, RPM still initializes with ts->dbmode
= DB_RDONLY, and then reopens the rpmdb with O_RW in rpmtsSetup(). That opens
a (minor and mostly irrelevant wrto RPM on OS X) race window.
There is still the ability to disable fsync (or replace with fdatasync)
Here are the patches in libdb-5.3.28-20: the patches are trackable to bug
reports and appear to have been fixed by "upstream"
`# License clarification patch
#
http://devel.trisquel.info/gitweb/?p=package-helpers.git;a=blob;f=helpers/DA
There's an endless row of bugs where BDB environment getting corrupted, some
of which have been BDB bugs (several found just in the last couple of years)
that have been patched in Fedora/RHEL libdb but upstream BDB 5.x does not have,
dunno about 6.x but there you run into the licensing side.
So corruption in this case means that any rpm operation that reads or writes to
BDB will fail, because the db fails to open. In our case, all rpm operations
are done as root. As you can see, this is reproducible as root:
```
[root@redacted ~]# for i in {1..30}; do /bin/rpm -qa &>/dev/null & done
> Let me preface this by saying we are doing something unorthodox: we are
> running RPM 4.12.90 on MacOS 10.12.
You're not the only one who does this. I do it as well. That said, I knew
vaguely about this issue, but I couldn't pin down what caused it. :)
--
You are receiving this because you
Note also that simply removing __db.00N files to "fix" problems can lead to
other "corruption" problems, particularly when other accesses are running
simultaneously.
The better fix for what you are calling "corruption" is to use "db_recover"
with/without the -e option.
BDB has a notification
The term "corruption" is highly unspecific: please avoid, and/or supply more
specific details.
Yes, somewhat counter intuitively, the "read-only" operation of rpm -qa is
writing to disk: at a minimum, shared read locks (and rpm-4.x.y also is trying
to create an advisory file lock).
The
Let me preface this by saying we are doing something unorthodox: we are running
RPM 4.12.90 on MacOS 10.12.
It turns out that on Linux, querying and writing to the database can cause
corruption. On MacOS, just querying in parallel can cause it. We can replicate
it by doing `for i in {1..30};
30 matches
Mail list logo
