[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: (ITS#4324) PANIC: fatal region error detected;
This is a multi-part message in MIME format.
--------------010306010708040803050003
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
I confirm. That's the same behavior using db 4.2.52
empty DB_CONFIG
runs OK
slapcat, then PANIC fatal region..
or man slapd-bdb:
"The options set using this directive will only be written to the
DB_CONFIG file if no such file existed at server
startup time. "
That's great, but then, if a slapcat is done: bingo..(I don't understand
why, as db_recover is OK using the old 'same DB_CONFIG, slapd is running
OK but slapcat complains and make slapd crash..)
So the man is incorrect or these options have only a sense using slapadd
and not slapd?.
Thanks
Dom
lalot@univ-aix.fr a écrit :
>This is a multi-part message in MIME format.
>--------------090907080009010306020903
>Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>Content-Transfer-Encoding: 8bit
>
>Sorry,
>
>That was:
>ii libdb4.3 4.3.27-2 Berkeley v4.3
>Database Libraries [runtime]
>
>hyc@symas.com a écrit :
>
>
>
>>lalot@univ-aix.fr wrote:
>>
>>
>>
>>
>>>Full_Name: LALOT Dominique
>>>Version: 2.3.17
>>>OS: Linux 2.6
>>>URL: ftp://ftp.openldap.org/incoming/
>>>Submission from: (NULL) (193.50.125.9)
>>>
>>>
>>>To keep DB_CONFIG out of order, I just remove it in slapd init script.
>>>
>>>
>>>
>>>
>>>
>>Don't do that.
>>
>>
>>
>>
>The reason is:
>as slapd.conf is now (thanks) managing set-flags for bdb, it appears
>that it's only working if the DB_CONFIG does not exists. If it exists,
>nothing is done
>
>As I want to put the flags only in slapd.conf, I decided to remove the
>DB_CONFIG. (I believe that's not stupid, but I can be wrong..). I would
>like to say: take my flags, recover and start..)
>And also what I discovered running slapd in such case (empty DB_CONFIG),
>then running slapd should happened elsewhere.
>
>I agree that in some cases, I could revover with other flags and then
>starting, but most of the time, the DB_CONFIG will be the same. In fact
>I would like to use slapadd with DB_TXN_NOSYNC that everybody should use?.
>Between a production situation and an upload, the only difference I need
>is DB_TXN_NOSYNC, and I don't want to play with scripts copying a
>DB_CONFIG then removing etc..
>
>That's not evident to explain to a non specialist what to do in such
>case. So the simplest it is, the best it is. There is no way to say in
>slapadd with backend bdb that DB_TXN_NOSYNC should the default behavior?.
>As slapadd gracefully stop and you are starting from a plain ldif file
>that should be the case!. But I immagine that some people run it with a
>running slapd and a partial ldif.. we lack an option in slapadd!.
>in slapadd (open base with DB_CONFIG, if no base and records, reopen
>withs flags to DB_TXN_NOSYNC )
>
>Just an idea..
>
>Dominique
>
>I'll make a test in db 4.2.52
>
>
>
>>>init script:
>>> cd /var/ldap/base
>>> /usr/bin/db4.3_recover
>>> /var/ldap/bin/purgedbarchive.pl .
>>> /bin/rm DB_CONFIG # reconstruction via les params de slapd.conf
>>> chown ldap.ldap *
>>> if grep -q ^TLS /etc/openldap/slapd.conf ; then
>>> nice -n -5 ${slapd} -u ldap -g ldap -h 'ldap:/// ldaps:///'
>>>slapd runs OK.
>>>Then slapcat >test
>>>bdb_db_open: DB_CONFIG for suffix dc=univmed,dc=fr has changed.
>>>Performing database recovery to activate new settings.
>>>
>>>and then:
>>>search: 2
>>>result: 80 Internal (implementation specific) error
>>>text: internal error
>>>
>>>bdb is 4.3.15
>>>seems the rm of DB_CONFIG is doing bad things. If I avoid it, it's OK I can do a
>>>slapcat without distburbing slapd
>>>As it's written in the docs that those flags would create a DB_CONFIG (it works
>>>indeed), what happened after in slapcat should not happen?.
>>>(by the way DB_LOG_AUTOREMOVE is not working also (bdb problem?))
>>>
>>>
>>>
>>>
>>>
>>Probably a BDB problem, yes. 4.3.15 was a pre-release version,
>>definitely not suitable for real use.
>>
>>
>>
>>
>>
>
>
>
--
Dominique LALOT
Ingénieur Système Réseau CISCAM Pole Réseau
Université de la Méditerranée http://annuaire.univmed.fr/showuser.php?uid=lalot
--------------010306010708040803050003
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
I confirm. That's the same behavior using db 4.2.52<br>
empty DB_CONFIG<br>
runs OK<br>
slapcat, then PANIC fatal region..<br>
<br>
or man slapd-bdb:<br>
"The options set using this directive will only be written to the
DB_CONFIG file if no such file existed at server<br>
startup time. "<br>
That's great, but then, if a slapcat is done: bingo..(I don't
understand why, as db_recover is OK using the old 'same DB_CONFIG,
slapd is running OK but slapcat complains and make slapd crash..)<br>
So the man is incorrect or these options have only a sense using
slapadd and not slapd?.<br>
<br>
Thanks<br>
<br>
Dom<br>
<br>
<a class="moz-txt-link-abbreviated" href="mailto:lalot@univ-aix.fr";>lalot@univ-aix.fr</a> a écrit :
<blockquote cite="mid200601111510.k0BFAEbE032507@boole.openldap.org"
type="cite">
<pre wrap="">This is a multi-part message in MIME format.
--------------090907080009010306020903
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Sorry,
That was:
ii libdb4.3 4.3.27-2 Berkeley v4.3
Database Libraries [runtime]
<a class="moz-txt-link-abbreviated" href="mailto:hyc@symas.com";>hyc@symas.com</a> a écrit :
</pre>
<blockquote type="cite">
<pre wrap=""><a class="moz-txt-link-abbreviated" href="mailto:lalot@univ-aix.fr";>lalot@univ-aix.fr</a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Full_Name: LALOT Dominique
Version: 2.3.17
OS: Linux 2.6
URL: <a class="moz-txt-link-freetext" href="ftp://ftp.openldap.org/incoming/";>ftp://ftp.openldap.org/incoming/</a>
Submission from: (NULL) (193.50.125.9)
To keep DB_CONFIG out of order, I just remove it in slapd init script.
</pre>
</blockquote>
<pre wrap="">Don't do that.
</pre>
</blockquote>
<pre wrap=""><!---->The reason is:
as slapd.conf is now (thanks) managing set-flags for bdb, it appears
that it's only working if the DB_CONFIG does not exists. If it exists,
nothing is done
As I want to put the flags only in slapd.conf, I decided to remove the
DB_CONFIG. (I believe that's not stupid, but I can be wrong..). I would
like to say: take my flags, recover and start..)
And also what I discovered running slapd in such case (empty DB_CONFIG),
then running slapd should happened elsewhere.
I agree that in some cases, I could revover with other flags and then
starting, but most of the time, the DB_CONFIG will be the same. In fact
I would like to use slapadd with DB_TXN_NOSYNC that everybody should use?.
Between a production situation and an upload, the only difference I need
is DB_TXN_NOSYNC, and I don't want to play with scripts copying a
DB_CONFIG then removing etc..
That's not evident to explain to a non specialist what to do in such
case. So the simplest it is, the best it is. There is no way to say in
slapadd with backend bdb that DB_TXN_NOSYNC should the default behavior?.
As slapadd gracefully stop and you are starting from a plain ldif file
that should be the case!. But I immagine that some people run it with a
running slapd and a partial ldif.. we lack an option in slapadd!.
in slapadd (open base with DB_CONFIG, if no base and records, reopen
withs flags to DB_TXN_NOSYNC )
Just an idea..
Dominique
I'll make a test in db 4.2.52
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">init script:
cd /var/ldap/base
/usr/bin/db4.3_recover
/var/ldap/bin/purgedbarchive.pl .
/bin/rm DB_CONFIG # reconstruction via les params de slapd.conf
chown ldap.ldap *
if grep -q ^TLS /etc/openldap/slapd.conf ; then
nice -n -5 ${slapd} -u ldap -g ldap -h '<a class="moz-txt-link-freetext" href="ldap:///";>ldap:///</a> ldaps:///'
slapd runs OK.
Then slapcat >test
bdb_db_open: DB_CONFIG for suffix dc=univmed,dc=fr has changed.
Performing database recovery to activate new settings.
and then:
search: 2
result: 80 Internal (implementation specific) error
text: internal error
bdb is 4.3.15
seems the rm of DB_CONFIG is doing bad things. If I avoid it, it's OK I can do a
slapcat without distburbing slapd
As it's written in the docs that those flags would create a DB_CONFIG (it works
indeed), what happened after in slapcat should not happen?.
(by the way DB_LOG_AUTOREMOVE is not working also (bdb problem?))
</pre>
</blockquote>
<pre wrap="">Probably a BDB problem, yes. 4.3.15 was a pre-release version,
definitely not suitable for real use.
</pre>
</blockquote>
<pre wrap=""><!---->
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Dominique LALOT
Ingénieur Système Réseau CISCAM Pole Réseau
Université de la Méditerranée <a class="moz-txt-link-freetext" href="http://annuaire.univmed.fr/showuser.php?uid=lalot";>http://annuaire.univmed.fr/showuser.php?uid=lalot</a>
</pre>
</body>
</html>
--------------010306010708040803050003--