[Citadel Development] Re: citadel-1617821022-x64.appimage
Thank you for the heads up. I am also setting up my virtualization environment so I can do full testing. On 4/30/21 8:41 AM, IGnatius T Foobar wrote: Just a heads up to mention that crash reporting (particularly in AppImage builds) is still the #1 priority. The previous bunch of commits were just some brainless sweeping of the floor to keep me occupied while multitasking.
[Citadel Development] Re: citadel-1617821022-x64.appimage
Just a heads up to mention that crash reporting (particularly in AppImage builds) is still the #1 priority. The previous bunch of commits were just some brainless sweeping of the floor to keep me occupied while multitasking.
[Citadel Development] Re: citadel-1617821022-x64.appimage
All right, exit code 139 means the server exited on signal 11, which means that the AppImage supervisor did the wrong thing. It should have restarted the server instead of exiting. I will correct the restart-on-crash problem, but since we also need to find out *where* yours is crashing, we have to add some backtrace magic into it. Sit tight and we will do that!
[Citadel Development] Re: citadel-1617821022-x64.appimage
Good day This is the network configuration of the VM, I need to give myself time to install a second interface (dmz): source /etc/network/interfaces.d/* # The loopback network interface auto lo iface lo inet loopback # The primary network interface allow-hotplug ens18 iface ens18 inet static address 192.168.16.33/21 gateway 192.168.16.99 # dns-* options are implemented by the resolvconf package, if installed dns-nameservers 8.8.8.8 dns-search ***hidden**.com - - - - - first attempt, (all executed as root) ctdlvisor: Welcome to the Citadel System, brought to you using AppImage. ctdlvisor: LD_LIBRARY_PATH = /tmp/.mount_citadelDLXpp/usr/lib ctdlvisor: PATH = /tmp/.mount_citadelDLXpp/usr/bin ctdlvisor: APPDIR = /tmp/.mount_citadelDLXpp ctdlvisor: data directory = /usr/local/citadel ctdlvisor: HTTP port = 80 ctdlvisor: HTTPS port = 443 ctdlvisor: citserver running on pid=5216 ctdlvisor: webcit (HTTP) running on pid=5217 ctdlvisor: webcit (HTTPS) running on pid=5218 ctdlvisor: executing /tmp/.mount_citadelDLXpp/usr/local/webcit/webcit ctdlvisor: executing /tmp/.mount_citadelDLXpp/usr/local/citadel/citserver with data directory /usr/local/citadel ctdlvisor: executing /tmp/.mount_citadelDLXpp/usr/local/webcit/webcit* ctdlvisor: pid=5216 exited, status=139, exitcode=0 ctdlvisor: citserver exited normally - ending AppImage session ctdlvisor: pid=5217 exited, status=15, exitcode=0 ctdlvisor: pid=5218 exited, status=15, exitcode=0 ctdlvisor: pid=-1 exited, status=15, exitcode=0 ctdlvisor: exit code 0* second attempt, ctdlvisor: Welcome to the Citadel System, brought to you using AppImage. ctdlvisor: LD_LIBRARY_PATH = /tmp/.mount_citade5YTQho/usr/lib ctdlvisor: PATH = /tmp/.mount_citade5YTQho/usr/bin ctdlvisor: APPDIR = /tmp/.mount_citade5YTQho ctdlvisor: data directory = /usr/local/citadel ctdlvisor: HTTP port = 80 ctdlvisor: HTTPS port = 443 ctdlvisor: citserver running on pid=5238 ctdlvisor: webcit (HTTP) running on pid=5239 ctdlvisor: webcit (HTTPS) running on pid=5240 ctdlvisor: executing /tmp/.mount_citade5YTQho/usr/local/webcit/webcit ctdlvisor: executing /tmp/.mount_citade5YTQho/usr/local/webcit/webcit ctdlvisor: executing /tmp/.mount_citade5YTQho/usr/local/citadel/citserver with data directory /usr/local/citadel *ctdlvisor: pid=5238 exited, status=139, exitcode=0** **ctdlvisor: citserver exited normally - ending AppImage session** **ctdlvisor: pid=5239 exited, status=15, exitcode=0** **ctdlvisor: pid=5240 exited, status=15, exitcode=0** **ctdlvisor: pid=-1 exited, status=15, exitcode=0** **ctdlvisor: exit code 0* and third attempt (after restarting the VM) ctdlvisor: Welcome to the Citadel System, brought to you using AppImage. ctdlvisor: LD_LIBRARY_PATH = /tmp/.mount_citade7DmEXm/usr/lib ctdlvisor: PATH = /tmp/.mount_citade7DmEXm/usr/bin ctdlvisor: APPDIR = /tmp/.mount_citade7DmEXm ctdlvisor: data directory = /usr/local/citadel ctdlvisor: HTTP port = 80 ctdlvisor: HTTPS port = 443 ctdlvisor: citserver running on pid=424 ctdlvisor: executing /tmp/.mount_citade7DmEXm/usr/local/citadel/citserver with data directory /usr/local/citadel ctdlvisor: webcit (HTTP) running on pid=425 ctdlvisor: webcit (HTTPS) running on pid=426 ctdlvisor: executing /tmp/.mount_citade7DmEXm/usr/local/webcit/webcit ctdlvisor: executing /tmp/.mount_citade7DmEXm/usr/local/webcit/webcit *ctdlvisor: pid=424 exited, status=139, exitcode=0 ctdlvisor: citserver exited normally - ending AppImage session ctdlvisor: pid=425 exited, status=15, exitcode=0 ctdlvisor: pid=426 exited, status=15, exitcode=0 ctdlvisor: pid=-1 exited, status=15, exitcode=0 ctdlvisor: exit code 0* Regards On 4/21/21 12:44 PM, IGnatius T Foobar wrote: >And yes, when trying to send messages it fails; I can send messages to >the "admin" account itself. Damn. I did a fresh install of Debian 10, minimal with no extra software added, on the exact virtual hardware you described in your last post. I still can't get it to fail. Can you please post the output of the AppImage when it crashes? I want to look at the exit codes to see if it's exiting on its own or crashing out from a signal. If it's a segfault then we'll have to find a way to get it to print a backtrace.
[Citadel Development] Re: citadel-1617821022-x64.appimage
>And yes, when trying to send messages it fails; I can send messages to >the "admin" account itself. Damn. I did a fresh install of Debian 10, minimal with no extra software added, on the exact virtual hardware you described in your last post. I still can't get it to fail. Can you please post the output of the AppImage when it crashes? I want to look at the exit codes to see if it's exiting on its own or crashing out from a signal. If it's a segfault then we'll have to find a way to get it to print a backtrace.
[Citadel Development] Re: citadel-1617821022-x64.appimage
Hi Art. The results I reported a couple of days ago are with the DB itself that creates the test. At this time I have not backed up the DB in production for use. I will do it these days in the evening, as I have to stop my server to be able to copy it. # uname -a Linux em2 4.19.0-16-*amd64* #1 SMP Debian 4.19.181-1 (2021-03-19) x86_64 GNU/Linux This is a VM running on Proxmox On 4/15/21 3:36 PM, IGnatius T Foobar wrote: Ok, so you're using stock Debian 10 (64-bit x86, I assume) and the AppImage declares that it is compatible. You are attaching it to a copy of an existing database. Local mail works fine, but any attempt to deliver Internet mail results in a server crash. Do I have it clear now?
[Citadel Development] Re: citadel-1617821022-x64.appimage
Ok, so you're using stock Debian 10 (64-bit x86, I assume) and the AppImage declares that it is compatible. You are attaching it to a copy of an existing database. Local mail works fine, but any attempt to deliver Internet mail results in a server crash. Do I have it clear now?
[Citadel Development] Re: citadel-1617821022-x64.appimage
The appimage is compatible # lsb_release -a No LSB modules are available. Distributor ID: Debian Description: Debian GNU/Linux 10 (buster) Release: 10 Codename: buster # ./citadel-1617821022-x64.appimage test /tmp/.mount_citadeSJ4RAB/usr/local/citadel/citserver: *binary compatibility confirmed* And yes, when trying to send messages it fails; I can send messages to the "admin" account itself. On 4/15/21 12:12 PM, IGnatius T Foobar wrote: >And although I discovered my mistake and now this VM works as I know it >should, in my test it still fails to use the "test" of the AppImage, if >I try to send some mail it just closes the App. That's progress. :) So let me see if I understand correctly. If you run the appimage in "test" mode, it declares that it is not compatible. If you run it in "run" mode, it starts the server, but crashes when you try to send mail. Is that correct? If so, please tell me the exact name and version of the Linux distribution you are running, so I can try to re-create the problem.
[Citadel Development] Re: citadel-1617821022-x64.appimage
>And although I discovered my mistake and now this VM works as I know it >should, in my test it still fails to use the "test" of the AppImage, if >I try to send some mail it just closes the App. That's progress. :) So let me see if I understand correctly. If you run the appimage in "test" mode, it declares that it is not compatible. If you run it in "run" mode, it starts the server, but crashes when you try to send mail. Is that correct? If so, please tell me the exact name and version of the Linux distribution you are running, so I can try to re-create the problem.
[Citadel Development] Re: citadel-1617821022-x64.appimage
I misread the message about missing commands in Debian (that was during installation, not after installation). And although I discovered my mistake and now this VM works as I know it should, in my test it still fails to use the "test" of the AppImage, if I try to send some mail it just closes the App. Note: this VM does not have direct Internet access, it uses a gateway for now. On 4/14/21 10:59 AM, s3cr3to wrote: Greetings Art The results of your tests continue to baffle me. I agree with you, this VM is really weird. I have reinstalled the VM with debian-10.7.0-amd64-DVD.iso and the problems are still occurring, I think I found a post (I didn't save it) where people report similar problems where commands are missing even though debian says they are installed. I just downloaded debian-10.9.0-amd64-netinst.iso and I hope now the things that strangely are not working will work. As soon as I have a working VM I'll let you know; I still need to bring me the backup of the Citadel server in production. Regards On 4/10/21 11:32 AM, IGnatius T Foobar wrote: The results of your tests continue to baffle me. But I am happy to see it, because if I can fix it for you, that means there are others who would have had the same result, and we are preventing all those support requests from happening. If you have the patience, I would be VERY grateful to have you continue running these tests, even though they continue to fail for now. Just be sure to run each one on a *fresh* clone of your production system, in case the previous test corrupted the existing copy. The next release will not fix the problem, but instead I am going to include a "test" mode that simply attempts to open the database and tell you a few things about the system it discovered and what it thinks is in there. Sound good to you?
[Citadel Development] Re: citadel-1617821022-x64.appimage
Greetings Art The results of your tests continue to baffle me. I agree with you, this VM is really weird. I have reinstalled the VM with debian-10.7.0-amd64-DVD.iso and the problems are still occurring, I think I found a post (I didn't save it) where people report similar problems where commands are missing even though debian says they are installed. I just downloaded debian-10.9.0-amd64-netinst.iso and I hope now the things that strangely are not working will work. As soon as I have a working VM I'll let you know; I still need to bring me the backup of the Citadel server in production. Regards On 4/10/21 11:32 AM, IGnatius T Foobar wrote: The results of your tests continue to baffle me. But I am happy to see it, because if I can fix it for you, that means there are others who would have had the same result, and we are preventing all those support requests from happening. If you have the patience, I would be VERY grateful to have you continue running these tests, even though they continue to fail for now. Just be sure to run each one on a *fresh* clone of your production system, in case the previous test corrupted the existing copy. The next release will not fix the problem, but instead I am going to include a "test" mode that simply attempts to open the database and tell you a few things about the system it discovered and what it thinks is in there. Sound good to you?
[Citadel Development] Re: citadel-1617821022-x64.appimage
Thanks Art. I'm going to have to reinstall this VM, for some reason I don't know; it's showing strange behavior; things that should work don't: I don't have fdisks, lvm2 commands, and things that a fresh install should have. Regards On 4/13/21 12:08 PM, IGnatius T Foobar wrote: >So, it won't help if I add another virtual disk with more storage if I >can't change the /tmp dump path. Rigth? Correct. I've removed the misleading guidance from the help text. The intermediate dumps must be on /tmp and this cannot be changed. If you add another virtual disk it would have to be mounted on /tmp
[Citadel Development] Re: citadel-1617821022-x64.appimage
>So, it won't help if I add another virtual disk with more storage if I >can't change the /tmp dump path. Rigth? Correct. I've removed the misleading guidance from the help text. The intermediate dumps must be on /tmp and this cannot be changed. If you add another virtual disk it would have to be mounted on /tmp
[Citadel Development] Re: citadel-1617821022-x64.appimage
So, it won't help if I add another virtual disk with more storage if I can't change the /tmp dump path. Rigth? On 4/12/21 2:55 PM, IGnatius T Foobar wrote: >For the latter, how should I run the database_cleanup to get it to take >the working path? database_cleanup always stores its intermediate dumps to /tmp. I really should change the help text which suggests otherwise.
[Citadel Development] Re: citadel-1617821022-x64.appimage
>For the latter, how should I run the database_cleanup to get it to take >the working path? database_cleanup always stores its intermediate dumps to /tmp. I really should change the help text which suggests otherwise.
[Citadel Development] Re: citadel-1617821022-x64.appimage
That's fine with me, let me finish with a good workload that has piled up. I will restore the "clean" snapshot (with the old data backup intact from the production server.), update it and try to put an extra disk in it: For the latter, how should I run the database_cleanup to get it to take the working path? On 4/10/21 11:32 AM, IGnatius T Foobar wrote: The results of your tests continue to baffle me. But I am happy to see it, because if I can fix it for you, that means there are others who would have had the same result, and we are preventing all those support requests from happening. If you have the patience, I would be VERY grateful to have you continue running these tests, even though they continue to fail for now. Just be sure to run each one on a *fresh* clone of your production system, in case the previous test corrupted the existing copy. The next release will not fix the problem, but instead I am going to include a "test" mode that simply attempts to open the database and tell you a few things about the system it discovered and what it thinks is in there. Sound good to you?
[Citadel Development] Re: citadel-1617821022-x64.appimage
The results of your tests continue to baffle me. But I am happy to see it, because if I can fix it for you, that means there are others who would have had the same result, and we are preventing all those support requests from happening. If you have the patience, I would be VERY grateful to have you continue running these tests, even though they continue to fail for now. Just be sure to run each one on a *fresh* clone of your production system, in case the previous test corrupted the existing copy. The next release will not fix the problem, but instead I am going to include a "test" mode that simply attempts to open the database and tell you a few things about the system it discovered and what it thinks is in there. Sound good to you?
[Citadel Development] Re: citadel-1617821022-x64.appimage
Hi Art. I answer each point. 1. I need to add another disk because I don't have enough space to run the database_cleanup. *But how I should specify a location*? The usage lacks of that info: *usage*: /home/sys1/citadel-1617821022-x64.appimage [-h data_directory] [-p http_port] [-s https_port] command command must be one of: run, test, install, database_cleanup Citadel Database Cleanup --- Thi... WARNING #1: MAKE A BACKUP... WARNING #2: citserver must NOT be running while you do this. (*I executed the command: **systemctl stop citadel*) WARNING #3: Please try... WARNING #4: You must have an amount of free space on your disk that is at least twice the size of your database, see the following output: (for substantially better performance *you should specify a location* that is on another disk than /usr/local/citadel/data) Filesystem Size Used Avail Use% Mounted on udev 2.0G 0 2.0G 0% /dev tmpfs 395M 5.4M 390M 2% /run /dev/mapper/em2--vg-root 182G 92G 81G 54% / tmpfs 2.0G 0 2.0G 0% /dev/shm tmpfs 5.0M 0 5.0M 0% /run/lock tmpfs 2.0G 0 2.0G 0% /sys/fs/cgroup /dev/sda1 472M 49M 399M 11% /boot tmpfs 395M 0 395M 0% /run/user/1000 you will need 91G of free space. We will attempt to look for a Citadel database in /usr/local/citadel/data Do you want to continue? *NO* root@em2:/home/sys1# df -h Filesystem Size Used Avail Use% Mounted on udev 2.0G 0 2.0G 0% /dev tmpfs 395M 5.4M 390M 2% /run */dev/mapper/em2--vg-root 182G 92G 81G 54% /* tmpfs 2.0G 0 2.0G 0% /dev/shm tmpfs 5.0M 0 5.0M 0% /run/lock tmpfs 2.0G 0 2.0G 0% /sys/fs/cgroup /dev/sda1 472M 49M 399M 11% /boot tmpfs 395M 0 395M 0% /run/user/1000 2. Yes this is the database location: root@em2:/home/sys1# ls -l /usr/local/citadel/ total 13708 srwx-- 1 root root 0 Apr 8 13:26 citadel-admin.socket -rwxr-xr-x 1 root root 10428392 Apr 7 14:04 citadel.appimage -rw-rw-rw- 1 root root 0 Apr 8 13:26 citadel.lock srwxrwsrwx 1 root root 0 Apr 8 13:26 citadel.socket -rw--- 1 root root 6127616 Apr 7 14:14 core drwx-- 2 root root 4096 Apr 8 04:03 data drwx-- 2 root root 4096 Apr 7 14:04 files drwx-- 2 root root 4096 Apr 7 14:04 keys srwxrwsrwx 1 root root 0 Apr 8 13:26 lmtp.socket srwxrwsrwx 1 root root 0 Apr 8 13:26 lmtp-unfiltered.socket drwx-- 2 root root 4096 Apr 7 14:04 messages root@em2:/home/sys1# ls -l /usr/local/citadel/data/ total 95209548 -rw--- 1 root root 380760064 Apr 8 04:03 cdb.00 -rw--- 1 root root 176128 Apr 8 13:26 cdb.01 -rw--- 1 root root 688128 Apr 8 13:26 cdb.02 -rw--- 1 root root 16384 Apr 8 13:26 cdb.03 -rw--- 1 root root 3809280 Apr 8 04:03 cdb.04 -rw--- 1 root root 516096 Apr 8 04:03 cdb.05 -rw--- 1 root root 24576 Apr 7 14:04 cdb.06 -rw--- 1 root root 60178432 Jan 25 19:00 cdb.07 -rw--- 1 root root 97038852096 Apr 8 04:03 cdb.08 -rw--- 1 root root 8192 Jan 25 20:01 cdb.09 -rw--- 1 root root 3518464 Apr 8 04:03 cdb.0a -rw--- 1 root root 16384 Apr 8 04:00 cdb.0b -rw--- 1 root root 8192 Jan 25 20:01 cdb.0c -rw--- 1 root root 8192 Apr 8 04:03 cdb.0d -rw--- 1 root root 71 Jan 25 20:01 DB_CONFIG -rw--- 1 root root 10485760 Apr 8 13:26 log.153721 The process runs with this info: root@em2:/home/sys1# ps -eaf|grep cit root 385 1 0 13:26 ? 00:00:00 /usr/local/citadel/citadel.appimage run -h /usr/local/citadel -p 80 -s 443 root 393 382 0 13:26 ? 00:00:00 citserver -x9 -h /usr/local/citadel root 394 382 0 13:26 ? 00:00:00 webcit -x9 -h/tmp/.mount_citadefpzQwJ/usr/local/webcit -p 80 uds /usr/local/citadel root 395 382 0 13:26 ? 00:00:00 webcit -x9 -h/tmp/.mount_citadefpzQwJ/usr/local/webcit -s -p 443 uds /usr/local/citadel 3. Yes I tested it with "admin+citadel" even today, and the message is "ADMIN NOT FOUND." The database has information, since it does not give me an error when I try with my username and password, it simply does not show error and does not change from the login page. Any commands I can run from the terminal to check further? It seems that "sendcommand" no longer exists. Regards! On 4/8/21 8:58 AM, IGnatius T Foobar wrote: >1. What effect would it have if I run
[Citadel Development] Re: citadel-1617821022-x64.appimage
>1. What effect would it have if I run *database_cleanup* with my >backup+data in the DB? Yes, I'd try database_cleanup just to see what it does. Also, I have to ask: is the copy of your database actually in /usr/local/citadel or is it somewhere else? You should also try logging in as "admin" with password "citadel". If that works, it means you're operating with an empty database instead of the one you think you're using.
[Citadel Development] Re: citadel-1617821022-x64.appimage
Greetings Art I manage to run the AppImage, but I can't login * Using my correct username and password, it does not show any message and does not change the page. * If I try to use invalid credentials, an error message tells me that the user does not exist or the password is invalid. This is my results: Checking to make sure Citadel is not already running... OK Checking this AppImage compatibility with your host system... /tmp/.mount_citadeK8ysof/usr/local/citadel/citserver: binary compatibility confirmed OK In what directory will you run Citadel? [/usr/local/citadel] Checking this operating system for systemd... OK Checking for old startup files. OK Ready to install /home/sys1/citadel-1617821022-x64.appimage in /usr/local/citadel Copying the AppImage... Creating the systemd unit file... OK Enabling the service... Created symlink /etc/systemd/system/multi-user.target.wants/citadel.service → /etc/systemd/system/citadel.service. OK Starting the service... OK Installation has completed. Please continue by browsing to http://em2:80 Using the command *test* looks good! root@em2:/home/sys1# ./citadel-1617821022-x64.appimage test /tmp/.mount_citadeOJ2v6t/usr/local/citadel/citserver: binary compatibility confirmed root@em2:/home/sys1# ./citadel-1617821022-x64.appimage -h /usr/local/citadel test /tmp/.mount_citadeLbqqNJ/usr/local/citadel/citserver: binary compatibility confirmed Questions: 1. What effect would it have if I run *database_cleanup* with my backup+data in the DB? root@em2:/home/sys1# ./citadel-1617821022-x64.appimage --help getopt: unrecognized option '--help' /home/sys1/citadel-1617821022-x64.appimage: usage: /home/sys1/citadel-1617821022-x64.appimage [-h data_directory] [-p http_port] [-s https_port] command command must be one of: run, test, install, database_cleanup Regards On 4/7/21 12:50 PM, IGnatius T Foobar wrote: [ http://easyinstall.citadel.org/citadel-1617821022-x64.appimage ] This version of the AppImage uses the same version of Berkeley DB as the one used in Easy Install. This means if you've tried the AppImage before but it choked on an existing database, now is the time to try again! I'll update the ARM version soon.
