Please wait...
0 files
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.
No doubt this is a hacky solution and one that we intend to solve a more elegant way in the future.
Thanks again for the explanation. Good to know, not all is grim for the future!
I've been messing with various BBS's to have on one of the systems at my VCF table this year and, remembering Citadel of long ago, thought maybe I'd give it a shot.
I have a SPARCstation 20 running Solaris 7 and found source for Citadel-UX 5.52 and 6.14, both have various build issues and wondered if there might happen to be some other versions of the source around somewhere. Whatever the latest source release was in the 5.x and 6.x trees might help in building this museum piece.
/TIA
Subject: Re: Old Citadel version source for VCF table
I have a SPARCstation 20 running Solaris 7 and found source for
Citadel-UX 5.52 and 6.14, both have various build issues and
wondered if there might happen to be some other versions of the
source around somewhere. Whatever the latest source release was
in the 5.x and 6.x trees might help in building this museum
piece.
What is the experience you are trying to re-create? During the Solaris 7 era we still had the full multiuser experience on both text and web. It was a lot clunkier than it is today but it was similar in spirit.
I'm going to assume that the current version either won't build on Solaris 7 without a lot of modifications or might produce an experience too modern for your purpose. But guess what ... you can just clone the git repository, roll back to whatever year you want to experience, and build from that. If you go back to a year when Solaris 7 was current, you should be able to build everything, because Solaris was fully supported by Citadel back then.
I don't remember what version of Solaris I ran Citadel on, but I had a SPARCstation IPX and later an AXi, and regularly built Citadel on both of them.
Subject: Re: Old Citadel version source for VCF table
Nothing specifically really other than a text mode BBS, there are many DOS and other options, not many for Solaris (which is one of the machines I have on hand). The only real requirement is that I’m trying to target the year 1999 and have it there at the table so anyone can use it
Version 6 has more Yacc issues than I care to tackle, but after fixing a couple small bugs in the 5.52 version, and adjusting make options, I have it built and working.
Running the docker image on arch/podman 5.5.1 (unpriviledged) seems to crash rather happily, after some light use:
Just in case, this output is of any use, meanthile I'll try a complete reboot:
Jun 26 18:16:58 podhost systemd-coredump[72142]: Process 71754 (citserver) of user 666 terminated abnormally with signal 11/SEGV, processing...
Jun 26 18:16:58 podhost systemd[1]: Started Process Core Dump (PID 72142/UID 0).
Jun 26 18:16:58 podhost systemd-coredump[72143]: Process 71754 (citserver) of user 666 dumped core.
Stack trace of thread 268:
#0 0x000077723f430ad9 n/a (/lib/x86_64-linux-gnu/libc-2.31.so + 0x16aad9)
#1 0x000077723b453630 n/a (n/a + 0x0)
ELF object binary architecture: AMD x86-64
Jun 26 18:16:58 podhost systemd[1]: systemd-coredump@1-72142-0.service: Deactivated successfully.
Jun 26 18:16:58 podhost citadel[614]: ctdlvisor: pid=265 exited, status=139, exitcode=0
Jun 26 18:16:58 podhost citadel[614]: ctdlvisor: citserver crashed on signal 11
Jun 26 18:16:58 podhost citadel[614]: ctdlvisor: citserver running on pid=274
Jun 26 18:16:58 podhost citadel[614]: ctdlvisor: executing citserver
Jun 26 18:17:40 podhost systemd-coredump[72187]: Process 72149 (citserver) of user 666 terminated abnormally with signal 11/SEGV, processing...
Jun 26 18:17:40 podhost systemd[1]: Started Process Core Dump (PID 72187/UID 0).
Jun 26 18:17:40 podhost systemd-coredump[72188]: Process 72149 (citserver) of user 666 dumped core.
Stack trace of thread 275:
#0 0x00007915a0fdaad9 n/a (/lib/x86_64-linux-gnu/libc-2.31.so + 0x16aad9)
#1 0x000079159e009630 n/a (n/a + 0x0)
ELF object binary architecture: AMD x86-64
Jun 26 18:17:40 podhost citadel[614]: ctdlvisor: pid=274 exited, status=139, exitcode=0
Jun 26 18:17:40 podhost citadel[614]: ctdlvisor: citserver crashed on signal 11
Jun 26 18:17:40 podhost citadel[614]: ctdlvisor: executing citserver
Jun 26 18:17:40 podhost citadel[614]: ctdlvisor: citserver running on pid=280
Jun 26 18:17:40 podhost systemd[1]: systemd-coredump@2-72187-0.service: Deactivated successfully.
Jun 26 18:18:28 podhost systemd-coredump[72202]: Process 72192 (citserver) of user 666 terminated abnormally with signal 11/SEGV, processing...
Jun 26 18:18:28 podhost systemd[1]: Started Process Core Dump (PID 72202/UID 0).
Jun 26 18:18:29 podhost systemd-coredump[72203]: Process 72192 (citserver) of user 666 dumped core.
Stack trace of thread 281:
#0 0x00007f8ad0c30ad9 n/a (/lib/x86_64-linux-gnu/libc-2.31.so + 0x16aad9)
#1 0x00007f8acdc5d630 n/a (n/a + 0x0)
ELF object binary architecture: AMD x86-64
Jun 26 18:18:29 podhost citadel[614]: ctdlvisor: pid=280 exited, status=139, exitcode=0
Jun 26 18:18:29 podhost citadel[614]: ctdlvisor: citserver crashed on signal 11
Jun 26 18:18:29 podhost citadel[614]: ctdlvisor: citserver running on pid=283
Jun 26 18:18:29 podhost systemd[1]: systemd-coredump@3-72202-0.service: Deactivated successfully.
Jun 26 18:18:29 podhost citadel[614]: ctdlvisor: executing citserver
Jun 26 18:19:21 podhost systemd-coredump[72214]: Process 72207 (citserver) of user 666 terminated abnormally with signal 11/SEGV, processing...
Jun 26 18:19:21 podhost systemd[1]: Started Process Core Dump (PID 72214/UID 0).
Jun 26 18:19:21 podhost systemd-coredump[72215]: Process 72207 (citserver) of user 666 dumped core.
Stack trace of thread 284:
#0 0x0000742305acbad9 n/a (/lib/x86_64-linux-gnu/libc-2.31.so + 0x16aad9)
#1 0x0000742302af9620 n/a (n/a + 0x0)
ELF object binary architecture: AMD x86-64
Jun 26 18:19:21 podhost systemd[1]: systemd-coredump@4-72214-0.service: Deactivated successfully.
Jun 26 18:19:21 podhost citadel[614]: ctdlvisor: pid=283 exited, status=139, exitcode=0
Jun 26 18:19:21 podhost citadel[614]: ctdlvisor: citserver crashed on signal 11
Jun 26 18:19:21 podhost citadel[614]: ctdlvisor: executing citserver
Jun 26 18:19:21 podhost citadel[614]: ctdlvisor: citserver running on pid=287
Jun 26 18:19:55 podhost systemd-coredump[72227]: Process 72219 (citserver) of user 666 terminated abnormally with signal 11/SEGV, processing...
Jun 26 18:19:55 podhost systemd[1]: Started Process Core Dump (PID 72227/UID 0).
Jun 26 18:19:55 podhost systemd-coredump[72228]: Process 72219 (citserver) of user 666 dumped core.
Stack trace of thread 289:
#0 0x000077fca9a75ad9 n/a (/lib/x86_64-linux-gnu/libc-2.31.so + 0x16aad9)
#1 0x000077fca62a0630 n/a (n/a + 0x0)
ELF object binary architecture: AMD x86-64
Jun 26 18:19:55 podhost systemd[1]: systemd-coredump@5-72227-0.service: Deactivated successfully.
Jun 26 18:19:55 podhost citadel[614]: ctdlvisor: pid=287 exited, status=139, exitcode=0
Jun 26 18:19:55 podhost citadel[614]: ctdlvisor: citserver crashed on signal 11
Jun 26 18:19:55 podhost citadel[614]: ctdlvisor: citserver running on pid=290
Jun 26 18:19:55 podhost citadel[614]: ctdlvisor: executing citserver
Jun 26 18:20:29 podhost systemd-coredump[72237]: Process 72232 (citserver) of user 666 terminated abnormally with signal 11/SEGV, processing...
Jun 26 18:20:29 podhost systemd[1]: Started Process Core Dump (PID 72237/UID 0).
Jun 26 18:20:29 podhost systemd-coredump[72238]: Process 72232 (citserver) of user 666 dumped core.
Stack trace of thread 292:
#0 0x0000778b2f4faad9 n/a (/lib/x86_64-linux-gnu/libc-2.31.so + 0x16aad9)
#1 0x0000778b2bd7f630 n/a (n/a + 0x0)
ELF object binary architecture: AMD x86-64
Jun 26 18:20:29 podhost systemd[1]: systemd-coredump@6-72237-0.service: Deactivated successfully.
Jun 26 18:20:29 podhost citadel[614]: ctdlvisor: pid=290 exited, status=139, exitcode=0
Jun 26 18:20:29 podhost citadel[614]: ctdlvisor: citserver crashed on signal 11
Jun 26 18:20:29 podhost citadel[614]: ctdlvisor: citserver running on pid=293
Jun 26 18:20:29 podhost citadel[614]: ctdlvisor: executing citserver