How much space do you think I am going to need to dump? It said 57, but I ran
out of space at 85GB, so was it shooting for 114GB or so?
I have a feeling that when I imported my data from the IMAP server it was on,
some of the existing users had many layers and folders within the inbox
>Would a migrate deal with potential DB issues? If I did a migrate to the
new
>server platform, would it clear up the little DB issues? I have something
Honestly, it sounds like if you *don't* dump and load your db soon (either
using the migrate commands or whatever) you're going to have
Also, I am getting this many times in my logs as users log in:
>
>
>Aug 12 23:01:07 smcit citserver[599]: msgbase: CtdlFetchMessage(15796750, 1)
>Failed!
>
>Aug 12 23:01:07 smcit citserver[599]: msgbase: CtdlFetchMessage(15796750, 1)
>Failed!
>
>
>
>Aug 12 23:01:07 smcit citserver[599]:
Would a migrate deal with potential DB issues? If I did a migrate to the new
server platform, would it clear up the little DB issues? I have something
funny going on for a while about the BASEROOM being changed somehow by one of
my IMAP users and how they named the folder. I think I am still
Checking my logs, I get a lot of entries like this (emphasis added):
>
>
>Aug 12 17:21:14 smcit webcit[1200]: SSL started
>
>Aug 12 17:21:14 smcit webcit[1200]: GET /dotgoto?room=_MAIL_ HTTP/1.1
>
>*Aug 12 17:21:15 smcit webcit[1200]: ConditionalWholistExpanded() returns 0*
>
>
I tried the export, as it only said I needed 57GB to run it, and it ended up
filling my drive at 85 GB. Does it actually need 114GB to export a DB of
57GB?
> Sat Aug 12 2017 07:34:04 PM EDT from IGnatius T Foobar @ Uncensored
>Subject: Re: DB corruption
>
>I'm so sorry about the timing on
I'm so sorry about the timing on this, I only seem to have a couple of short
bursts of energy each day and I don't know when I will get them. If you can
get db_recover et al to run clean, you should be good, but if you have the
ability to do a full export, do the export.
Not sure if it was the right thing to do, but I just moved those log files
which were not current and were causing issues to a different directory, and
then ran db_recover etc again. Seemed fine. We will see.
> Fri Aug 11 2017 07:35:12 PM EDT from bennabiy @ Uncensored Subject: DB
>corruption
Yes, the DB_CONFIG file is a function of Berkeley DB, not Citadel. If that
file is found in the data/ directory, you can use it to "redirect" both the
database files and the log files to other locations. You are correct in
observing
that there is no way to move the configuration of database
All right, nothing interesting there. :(
Here is a directory listing of /usr/local/citadel
>
>
>/usr/local/citadel# ls -lah
>
>total 4.7M
>
>drwxr-xr-x 15 citadel citadel 4.0K Feb 15 03:02 .
>
>drwxr-xr-x 13 root root 4.0K Feb 1 17:30 ..
>
>-rwxr-xr-x 1 citadel staff 100K Jan 26 18:00 aidepost
>
>-rwxr-xr-x 1
>citserver is not crashing, but it loses or forgets its port number, (I noted
>that you had this same thing happen, but I can reproduce it almost every
time
>citserver is restarted) and it does not remember the setting about not
>denying self service registration. I have rooms which are
http://www.citadel.org/doku.php/documentation:appproto:system_config lists
>
>
>
>CONF (get or set global CONFiguration options)
>
>
>
>
>Retrieves or sets various system-wide configuration and policy options. This
>command is only available to Admins.
>
>The six forms of this command
Looking in the source, I see you use PUTVAL rather than the documented SETVAL. What is the difference?
According to the code, PUTVAL is correct; SETVAL is not. Did I write it as SETVAL somewhere? If so please point out where and I'll fix it!
Looking in the source, I see you use PUTVAL rather than the documented
SETVAL. What is the difference?
> Sun Feb 12 2017 12:21:30 EST from bennabiy @ Uncensored Subject: DB
>frontend for configuration troubleshooting
>
>
>
>I tried to set the registration setting:
>
>CONF
15 matches
Mail list logo
