A long time ago. When I moved to x64 I used both ctdlmigrate and the other method. I had a lot of difficulty, and it wasn't consistently re-creatable - that is - after I did it, I tried to do it again, and it failed. I never figured out what exactly I did that got it to work the time it did - but once was enough to get it moved over - and now I have lots of copies of it on x64 drives. 

When you're ready to have me attempt a clone using AppImage of The Sanitarium - I'll give it a shot. I'm actually really excited about AppImage and the changes taking place with Citadel right now. 
The fact that I've been running Citadel pretty successfully for a couple of years now, I think - suggests that it already was pretty low down the ladder of skills necessary to run Citadel - but yes - the easier it is to put up a Citadel - the better, for sure. 


Thu Apr 01 2021 17:32:11 EDT from IGnatius T Foobar
Production is an i5 NUC. I've got 4 of that particular model. Dell
optiplex 3020 Micro - and two 3040s that have the next gen i5 CPU. 

Ok, so you're on 64-bit x86. Did you use ctdlmigrate to move from ARM? I ended up making a lot of changes to that recently when I tried to run it with a clone of Uncensored as the source machine; it choked badly on my database.

There are new AppImage builds available as of today.
https://www.citadel.org/appimage.html

These include all of the new import/export module code, but ironically I haven't yet put in a *way* to run ctdlmigrate from the AppImage. This will inevitably be added before I start running it myself, because my source system is 32-bit and I want to put an end to that.

The new version *can* be called with "./citadel-xxxxxxxxxx.appimage database_cleanup" to invoke the database_cleanup.sh script on the database, using the correct version of Berkeley DB packaged with the AppImage. This will be very useful for people who did horrifying things to their systems and need to clean up.

Speaking of horrifying things ... hopefully they will happen less frequently.
I've made the server shutdown sequence far more violent towards everything *except* closing the databases. Now when a signal is received, it goes straight for the database close operation -- screw the open connections and everything else it's doing. Its primary and only objective at that point is to cleanly close the databases. It now happens extremely quickly, too ... no more waiting 30 seconds for all threads to complete their work -- after which citserver exits even if the databases were not closed. Corrupting data is bad.

Yes, we're trying to get as far down the ladder as we can with regards to how much skill you need to run Citadel. We'll never get to the bottom.

 

Reply via email to