Subject: Re: Initial web access pops 503 error.
It's a weird one because nothing unusual is happening here, it's just trying to display the site's greeting banner (hello).
What is the contents of ./messages/hello ? Is it there? Is it corrupted?
Subject: Re: Initial web access pops 503 error.
Ok, I'm really struggling with this one because it's crashing while doing something very clean and simple, which may suggest a problem elsewhere.
I've added a few more diagnostics to that area of the system. Also it will now print a simple stack trace to the syslog at the moment it crashes. Please upgrade to version 1013 and see if the behavior changes any.
Also if you find you need to run it in the debugger, the command to produce the output we need is "thread apply all bt" after it crashes.
I am running on Debian Bullseye/Sid.
As far as the messages folder... It's empty, I'm guessing that's not right.
I reloaded with Easyinstall and apparently it's still listing the server version as 1011. Very odd though, the server stayed up for hours without a problem until I opened Webcit in my browser, which came up to my personal mail room and then errored saying it couldn't stay connected to the Citadel server. Of course checking the logs immediately showed a citserver crash. I've listed the stack trace from the logs and the surrounding logs below:
May 23 20:25:08 nadia webcit[615]: webcit[615]: SSL_accept (sock=5) success, usi
ng TLS_AES_128_GCM_SHA256 on TLSv1.3 (128 of 128 bits)
May 23 20:25:08 nadia webcit[615]: SSL_accept (sock=5) success, using TLS_AES_12
8_GCM_SHA256 on TLSv1.3 (128 of 128 bits)
May 23 20:25:08 nadia webcit[615]: webcit[615]: Ending SSL/TLS
May 23 20:25:08 nadia webcit[615]: Ending SSL/TLS
May 23 20:25:08 nadia webcit[615]: webcit[615]: SSL_accept (sock=13) success, us
ing TLS_AES_128_GCM_SHA256 on TLSv1.3 (128 of 128 bits)
May 23 20:25:08 nadia webcit[615]: webcit[615]: SSL_accept (sock=8) success, usi
ng TLS_AES_128_GCM_SHA256 on TLSv1.3 (128 of 128 bits)
May 23 20:25:08 nadia webcit[615]: SSL_accept (sock=13) success, using TLS_AES_1
28_GCM_SHA256 on TLSv1.3 (128 of 128 bits)
May 23 20:25:08 nadia webcit[615]: SSL_accept (sock=8) success, using TLS_AES_12
8_GCM_SHA256 on TLSv1.3 (128 of 128 bits)
May 23 20:25:08 nadia webcit[615]: webcit[615]: SSL_accept (sock=6) success, usi
ng TLS_AES_128_GCM_SHA256 on TLSv1.3 (128 of 128 bits)
May 23 20:25:08 nadia webcit[615]: webcit[615]: SSL_accept (sock=6) success, usi
ng TLS_AES_128_GCM_SHA256 on TLSv1.3 (128 of 128 bits)
May 23 20:25:08 nadia webcit[615]: SSL_accept (sock=6) success, using TLS_AES_12
8_GCM_SHA256 on TLSv1.3 (128 of 128 bits)
May 23 20:25:08 nadia citserver[9135]: citserver[9135]: SIGSEGV received in thre
ad 140169230857984 at address 0xb79be820
May 23 20:25:08 nadia citserver[9135]: SIGSEGV received in thread 14016923085798
4 at address 0xb79be820
May 23 20:25:08 nadia webcit[615]: webcit[615]: Ending SSL/TLS
May 23 20:25:08 nadia webcit[615]: Ending SSL/TLS
May 23 20:25:08 nadia webcit[615]: webcit[615]: Ending SSL/TLS
May 23 20:25:08 nadia webcit[615]: Ending SSL/TLS
May 23 20:25:08 nadia webcit[615]: webcit[615]: SSL_accept (sock=9) success, usi
ng TLS_AES_128_GCM_SHA256 on TLSv1.3 (128 of 128 bits)
May 23 20:25:08 nadia webcit[615]: webcit[615]: SSL_accept (sock=10) success, us
ing TLS_AES_128_GCM_SHA256 on TLSv1.3 (128 of 128 bits)
May 23 20:25:08 nadia webcit[615]: SSL_accept (sock=10) success, using TLS_AES_1
28_GCM_SHA256 on TLSv1.3 (128 of 128 bits)
May 23 20:25:08 nadia webcit[615]: SSL_accept (sock=9) success, using TLS_AES_12
8_GCM_SHA256 on TLSv1.3 (128 of 128 bits)
May 23 20:25:08 nadia webcit[615]: webcit[615]: Ending SSL/TLS
May 23 20:25:08 nadia webcit[615]: webcit[615]: Ending SSL/TLS
May 23 20:25:08 nadia webcit[615]: Ending SSL/TLS
May 23 20:25:08 nadia webcit[615]: Ending SSL/TLS
May 23 20:25:08 nadia citserver[9135]: citserver[9135]: Stack frame #0: /usr/loc
al/citadel/citserver(+0x36f0a) [0x55c470fbaf0a]
May 23 20:25:08 nadia citserver[9135]: Stack frame #0: /usr/local/citadel/citser
ver(+0x36f0a) [0x55c470fbaf0a]
May 23 20:25:08 nadia citserver[9135]: citserver[9135]: Stack frame #1: /lib/x86
_64-linux-gnu/libpthread.so.0(+0x14420) [0x7f7bb7bbb420]
May 23 20:25:08 nadia citserver[9135]: Stack frame #1: /lib/x86_64-linux-gnu/lib
pthread.so.0(+0x14420) [0x7f7bb7bbb420]
May 23 20:25:08 nadia citserver[9135]: citserver[9135]: Stack frame #2: /lib/x86
_64-linux-gnu/libc.so.6(+0x188947) [0x7f7bb7992947]
May 23 20:25:08 nadia citserver[9135]: Stack frame #2: /lib/x86_64-linux-gnu/lib
c.so.6(+0x188947) [0x7f7bb7992947]
May 23 20:25:08 nadia citserver[9135]: citserver[9135]: Stack frame #3: /lib/x86
_64-linux-gnu/libc.so.6(+0x78d15) [0x7f7bb7882d15]
May 23 20:25:08 nadia citserver[9135]: Stack frame #3: /lib/x86_64-linux-gnu/lib
c.so.6(+0x78d15) [0x7f7bb7882d15]
May 23 20:25:08 nadia citserver[9135]: citserver[9135]: Stack frame #4: /lib/x86
_64-linux-gnu/libc.so.6(+0x8bf9a) [0x7f7bb7895f9a]
May 23 20:25:08 nadia citserver[9135]: Stack frame #4: /lib/x86_64-linux-gnu/lib
c.so.6(+0x8bf9a) [0x7f7bb7895f9a]
May 23 20:25:08 nadia citserver[9135]: citserver[9135]: Stack frame #5: /usr/loc
al/citadel/citserver(+0x1d0a1) [0x55c470fa10a1]
May 23 20:25:08 nadia citserver[9135]: Stack frame #5: /usr/local/citadel/citser
ver(+0x1d0a1) [0x55c470fa10a1]
May 23 20:25:08 nadia citserver[9135]: citserver[9135]: Stack frame #6: /usr/loc
al/citadel/citserver(+0x473c9) [0x55c470fcb3c9]
May 23 20:25:08 nadia citserver[9135]: Stack frame #6: /usr/local/citadel/citser
ver(+0x473c9) [0x55c470fcb3c9]
May 23 20:25:08 nadia citserver[9135]: citserver[9135]: Stack frame #7: /usr/loc
al/citadel/citserver(+0x3876e) [0x55c470fbc76e]
May 23 20:25:08 nadia citserver[9135]: citserver[9135]: Stack frame #8: /usr/loc
al/citadel/citserver(+0x3e843) [0x55c470fc2843]
May 23 20:25:08 nadia citserver[9135]: citserver[9135]: Stack frame #9: /usr/loc
al/citadel/citserver(+0x3810f) [0x55c470fbc10f]
May 23 20:25:08 nadia citserver[9135]: citserver[9135]: Stack frame #10: /lib/x8
6_64-linux-gnu/libpthread.so.0(+0x8609) [0x7f7bb7baf609]
May 23 20:25:08 nadia citserver[9135]: citserver[9135]: Stack frame #11: /lib/x8
6_64-linux-gnu/libc.so.6(clone+0x43) [0x7f7bb7929353]
May 23 20:25:08 nadia citserver[9135]: Stack frame #7: /usr/local/citadel/citser
ver(+0x3876e) [0x55c470fbc76e]
May 23 20:25:08 nadia citserver[9135]: Stack frame #8: /usr/local/citadel/citser
ver(+0x3e843) [0x55c470fc2843]
May 23 20:25:08 nadia citserver[9135]: Stack frame #9: /usr/local/citadel/citser
ver(+0x3810f) [0x55c470fbc10f]
May 23 20:25:08 nadia citserver[9135]: Stack frame #10: /lib/x86_64-linux-gnu/li
bpthread.so.0(+0x8609) [0x7f7bb7baf609]
May 23 20:25:08 nadia citserver[9135]: Stack frame #11: /lib/x86_64-linux-gnu/li
bc.so.6(clone+0x43) [0x7f7bb7929353]
May 23 20:25:08 nadia webcit[615]: webcit[615]: StrBuf_ServGetln(): Server conne
ction broken: Success
May 23 20:25:08 nadia webcit[615]: StrBuf_ServGetln(): Server connection broken:
Success
May 23 20:25:08 nadia webcit[615]: webcit[615]: HTTP: 200 [0.171787] GET /image?
name=hello
May 23 20:25:08 nadia webcit[615]: webcit[615]: Ending SSL/TLS
May 23 20:25:08 nadia webcit[615]: HTTP: 200 [0.171787] GET /image?name=hello
May 23 20:25:08 nadia webcit[615]: Ending SSL/TLS
May 23 20:25:08 nadia systemd[1]: citadel.service: Main process exited, code=kil
led, status=11/SEGV
May 23 20:25:08 nadia systemd[1]: citadel.service: Failed with result 'signal'.
May 23 20:25:09 nadia webcit[615]: webcit[615]: SSL_accept (sock=7) success, usi
ng TLS_AES_128_GCM_SHA256 on TLSv1.3 (128 of 128 bits)
May 23 20:25:09 nadia webcit[615]: SSL_accept (sock=7) success, using TLS_AES_12
8_GCM_SHA256 on TLSv1.3 (128 of 128 bits)
May 23 20:25:09 nadia webcit[615]: webcit[615]: Ending SSL/TLS
May 23 20:25:09 nadia webcit[615]: Ending SSL/TLS
May 23 20:25:09 nadia webcit[615]: webcit[615]: SSL_accept (sock=10) success, us
ing TLS_AES_128_GCM_SHA256 on TLSv1.3 (128 of 128 bits)
May 23 20:25:09 nadia webcit[615]: webcit[615]: SSL_accept (sock=9) success, usi
ng TLS_AES_128_GCM_SHA256 on TLSv1.3 (128 of 128 bits)
May 23 20:25:09 nadia webcit[615]: SSL_accept (sock=10) success, using TLS_AES_1
28_GCM_SHA256 on TLSv1.3 (128 of 128 bits)
May 23 20:25:09 nadia webcit[615]: SSL_accept (sock=9) success, using TLS_AES_12
8_GCM_SHA256 on TLSv1.3 (128 of 128 bits)
May 23 20:25:09 nadia webcit[615]: webcit[615]: Ending SSL/TLS
May 23 20:25:09 nadia webcit[615]: webcit[615]: Ending SSL/TLS
May 23 20:25:09 nadia webcit[615]: Ending SSL/TLS
May 23 20:25:09 nadia webcit[615]: Ending SSL/TLS
May 23 20:25:09 nadia systemd[1]: citadel.service: Scheduled restart job, restar
t counter is at 2.
May 23 20:25:09 nadia systemd[1]: Stopped Citadel Server.
Citserver has not crashed since my last message after installing the newer version, even with Webcit up. Not sure what changed.
Subject: Re: Initial web access pops 503 error.
The upgrade to 1103 worked for me.
Thanks
Subject: Re: Initial web access pops 503 error.
I use Citadel as a container.
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
0abf2ea2b684 citadeldotorg/citadel "/usr/local/bin/ctdl…" 4 months ago Up 2 hours citadel
I'm unsure how it happened, and unfortunately, I'm unable to provide you with an explanatory log. Last night, inbox rules suddenly stopped working for all defined users. The log for the last processed inbox rule is below. No rules have worked for 7 hours. No changes have been made to Citadel.
Is there anything you can direct me to? Thank you very much in advance for your valuable help.
{"log":"citserver[7]: inbox_do_msg: stop processing\n","stream":"stderr","time":"2025-06-19T07:02:51.33862326Z"}
{"log":"citserver[7]: inbox_do_msg: delete 8693757 from inbox\n","stream":"stderr","time":"2025-06-19T07:02:51.338935481Z"}
{"log":"citserver[7]: msgbase: CtdlDeleteMessages(0000000050.Mail, 1 msgs, )\n","stream":"stderr","time":"2025-06-19T07:02:51.338969635Z"}
{"log":"citserver[7]: msgbase: AdjRefCount() msg 8693757 ref count delta -1, is now 0\n","stream":"stderr","time":"2025-06-19T07:02:51.339721978Z"}
{"log":"citserver[7]: msgbase: deleting message \u003c8693757\u003e\n","stream":"stderr","time":"2025-06-19T07:02:51.339749945Z"}
{"log":"citserver[7]: msgbase: 1 message(s) deleted\n","stream":"stderr","time":"2025-06-19T07:02:51.342082159Z"}
{"log":"citserver[7]: user_ops: 185 maps to ****-vipsupport.inr01\n","stream":"stderr","time":"2025-06-19T07:02:51.342455597Z"}
{"log":"citserver[7]: user_ops: 74 maps to *****-inrkyc\n","stream":"stderr","time":"2025-06-19T07:02:51.342626661Z"}
{"log":"citserver[7]: msgbase: CtdlFetchMessage(373, 1)\n","stream":"stderr","time":"2025-06-19T07:02:51.34264403Z"}
{"log":"citserver[7]: do_inbox_processing_for_user: for ****-inrkyc, messages newer than 8681597\n","stream":"stderr","time":"2025-06-19T07:02:51.342941165Z"}
{"log":"citserver[7]: pop3: NOOP\n","stream":"stderr","time":"2025-06-19T07:02:51.34296413Z"}
{"log":"citserver[7]: inbox_do_msg: processing message #8694707 which is higher than 8681597, we are in 0000000074.Mail\n","stream":"stderr","time":"2025-06-19T07:02:51.342970663Z"}
{"log":"citserver[7]: inbox_do_msg: processing rule: 0 , field: all\n","stream":"stderr","time":"2025-06-19T07:02:51.342975083Z"}
{"log":"citserver[7]: inbox_do_msg: this is an always-on rule\n","stream":"stderr","time":"2025-06-19T07:02:51.342979319Z"}
{"log":"citserver[7]: inbox_do_msg: rule activated\n","stream":"stderr","time":"2025-06-19T07:02:51.342983816Z"}
{"log":"citserver[7]: internet_addressing: directory key is \u003cnifi03@****.com\u003e\n","stream":"stderr","time":"2025-06-19T07:02:51.34344315Z"}
{"log":"citserver[7]: internet_addressing: directory alias \u003cnifi03@****.com\u003e to \u003c****-nifi03\u003e\n","stream":"stderr","time":"2025-06-19T07:02:51.343472501Z"}
{"log":"citserver[7]: Recipient #0 of type 2 is \u003c***-nifi03\u003e\n","stream":"stderr","time":"2025-06-19T07:02:51.343489341Z"}
{"log":"citserver[7]: internet_addressing: validate_recipients() = 1 local, 0 room, 0 SMTP, 0 error\n","stream":"stderr","time":"2025-06-19T07:02:51.343514387Z"}
{"log":"citserver[7]: msgbase: CtdlFetchMessage(8694707, 1)\n","stream":"stderr","time":"2025-06-19T07:02:51.343523033Z"}
Subject: Re: Inbox rules stop working suddenly
I'm unsure how it happened, and unfortunately, I'm unable to provide
you with an explanatory log. Last night, inbox rules suddenly stopped
working for all defined users. The log for the last processed inbox
rule is below. No rules have worked for 7 hours. No changes have been
made to Citadel.
First things first: are the rules failing to run and all mail goes to inbox without processing, or has mail delivery stopped entirely?
Those are good logs by the way, how did you get them exported from the container?
Hello,
I've managed to connect thunderbird to the calender, using the documented URL: http://<server>/groupdav/calendar/calendar.ics
However, I am struggeling to find a corresponding url for the contacts
/groupdav/Contacts/ does not work, thunderbird does ask for the password, but afterwards reports a "failed to connect" error, when trying to add a caldav addressbook. Contrary to what I could find, it does not matter, wether I provide the port with the server address or not. Also a newly created address room cannot be found
For news, thunderbird reports, it has connected to the news server, but it does not find any groups to possibly subscribe to.
Since there is no dedicated news option for new rooms, I would have expected the public rooms to be available. At least those, that have been created by that particular user. Or how would I create a news group, in case this is the more appropiate question
Thanks
Another beginners question: Is there a way to use the text mode client when running the docker image? The client itself is part of the image, but so far there seems to be no way of remotely accessing it.Well, besides "podman exec -it citadel /usr/local/bin/citadel". Obviously not a feasible option.
Neither telnet nor ssh seem to be installed and I am not aware of any remote text client. Hopefully I am just missing the last one?
Has anyone tried this yet? Any hints I might have missed in the documentation?
Thanks
First of all, thank you very much for your answer. I found the source of the problem and prevented it from recurring. Whatever the PutEmail function used by the Apache NiFi application to send mail was doing, it was avoiding the message processing ID from being added to new messages. You can print the debug log with the "-X 9" parameter when starting the container to get the logs. The emails were falling into the Inbox without any rules working. Sending and receiving mail was working normally. Only the Inbox rules were not working.
Hi!
I use Citadel 2 years ago, but recently, I can't send emails to mailboxes hosted on O2Switch (error 421 with no further explanation).
I can communicate with any mailbox on any host (GMail, Outlook, Orange, etc.) but not with them (I can receive emails from them from two domains hosted with them, but not vice versa).
And for their part, they have no problem communicating with anyone...
Could someone help me? Because this type of problem is really stumping me...
Thanks in advance
Hello!
But recently, I can't send emails to mailboxes hosted on O2Switch (error 421 with no further explanation).
I can communicate with any mailbox on any host (GMail, Outlook, Orange, etc.) but not with them (I can receive emails from them from two domains hosted with them, but not vice versa).
And for their part, they have no problem communicating with anyone, and don't see any SMTP connections...
Could someone help me? Because this type of problem is really stumping me...
Thanks in advance
Hello!
But recently, I can't send emails to mailboxes hosted on O2Switch (error 421 with no further explanation).
I can communicate with any mailbox on any host (GMail, Outlook, Orange, etc.) but not with them (I can receive emails from them from two domains hosted with them, but not vice versa).
And for their part, they have no problem communicating with anyone, and don't see any SMTP connections...
Could someone help me? Because this type of problem is really stumping me...
Thanks in advance
Another beginners question: Is there a way to use the text mode client
when running the docker image? The client itself is part of the image,
but so far there seems to be no way of remotely accessing it.Well,
besides "podman exec -it citadel /usr/local/bin/citadel". Obviously not
a feasible option.
This is definitely a tricky one, and something that I had to kind of hack together when I moved this system to the containerized version of Citadel.
I ended up just copying "citadel" and "libcitadel.so.4..." and "citadel.rc" into the host system and running it from there.
No doubt this is a hacky solution and one that we intend to solve a more elegant way in the future.
Subject: Re: URLs for external clients for contacts & news
However, I am struggeling to find a corresponding url for the contacts
Does the Thunderbird client support accessing the contacts list in that way?
To the best of my knowledge it does not.
When you connect Thunderbird to the Citadel calendar you're basically accessing the calendar "as a whole" which is to say, it downloads the whole calendar, then when you make changes it reuploads the whole calendar.
Thunderbird also supports CalDAV and probably CardDAV, which will be fully supported in the not-yet-released WebCit-NG, but unfortunately the current version does not support those protocols.
Subject: Re: URLs for external clients for contacts & news
Di Jun 24 2025 02:27:46 UTC von IGnatius T Foobar Betreff: Re: URLs for external clients for contacts & newsHowever, I am struggeling to find a corresponding url for the contacts
Does the Thunderbird client support accessing the contacts list in that way?
To the best of my knowledge it does not.
When you connect Thunderbird to the Citadel calendar you're basically accessing the calendar "as a whole" which is to say, it downloads the whole calendar, then when you make changes it reuploads the whole calendar.
Thunderbird also supports CalDAV and probably CardDAV, which will be fully supported in the not-yet-released WebCit-NG, but unfortunately the current version does not support those protocols.
Thanks very much. I have just found a post, that claimed to have accomplished just that, so I've assumed, it was simply me. Indeed I was trying to use caldav, as this seemed to be the natural choice. No biggy, I'll stick with LDAP for the time being.