Hi Mike,

Happy Easter holiday to you too!

Because of holiday, the troubleshooting process had been paused and shall resume again.

The ESXi host had no mac binding arrangements -- I had other VMs running both adapters which can successfully use DHCP and static external IP separately

May try traceroute approach later.

Sun Apr 05 2026 07:26:39 AM UTC from Motobike Subject: Re: New Citadel Installation not receiving mail nor response to external SMTP check

Hi Alan,

first, happy easter to you and your family. 

Is there any MAC boundary to the old Maschine inside ESx ? 

If telnet works on internal lan and not from outside, so must be a routing fail from the firewall or antoher service. Also check for persisten custom routes. 

You also can do a traceroute from inside and from outside. Maybe this gives you some more informations. 

 

Greetings

Mike

 

 

Hi Alan,

first, happy easter to you and your family. 

Is there any MAC boundary to the old Maschine inside ESx ? 

If telnet works on internal lan and not from outside, so must be a routing fail from the firewall or antoher service. Also check for persisten custom routes. 

You also can do a traceroute from inside and from outside. Maybe this gives you some more informations. 

Greetings

Mike

Mi Apr 01 2026 02:09:39 UTC von alanlau Betreff: Re: New Citadel Installation not receiving mail nor response to external SMTP check

Thanks Mike for help.

1. DNS - noted

2. Installation -- inside our own premise on VMWare host.  Host with 2 LAN card, one for LAN and another for WAN.  WAN adapter had external IP independent from LAN.

3. Since new server not working on existing Domain name and IP, it is now running simulatenously together with current server but with different LAN and WAN IP for troubleshooting

4. Telnet -- already test within own LAN as well as externally (from my home and at another office) -- both can successfully telnet port 25 of new server, on both WAN IP (24 & 28 when trying to switch).

 

Existing server setup: Citadel on Ubuntu 18.04 VM on VMWare, WAN IP xxx.xxx.xxx.28.  Server had been running since 2018 and having maintenence issue therefore prepared to be replaced.

New server now prepared: Citadel on Debian 13 VM on VMWare, WAN IP xxx.xxx.xxx.24.  Completely new install and not migration.  Both server on SAME vmware host with same network adapter, both LAN and WAN.

 

Problem: after shutdown existing server, and replace the new server to IP ending with 28, it does not receive external mail nor passing MXTOOLBOX server test.  However when placing back to IP ending with 24, MXTOOLBOX test (using IP) works.  Returning the existing server back online will have everything working fine.

 

Tue Mar 31 2026 10:04:57 AM UTC from Motobike Subject: Re: New Citadel Installation not receiving mail nor response to external SMTP check

Hi Alan,

 

i think, i need some more details about your setup. 

The DNS entrys doenst need to change. 

Your Citadel installation is on premise / selfhosted inside your own network?

If the new server have a different IP Address, maybe it wouldnt work. Do you checked your Firewall ports and port routing ? 

If you Citadel is inside your network, can you telnet from a different computer to your Citadel Server ?

 

For more details about your setup you can mail me if you want. Maybe there  informations not for everyones eyes, but the solution is good for all. 

 

Greetings 

Mike

michael@g00r00.com

 

 

Forget to mention both Ubutnu and Debian had no Firewall enabled.  

External IPs also running without Firewall equipment/UTM until everything had solved.

Thanks Mike for help.

1. DNS - noted

2. Installation -- inside our own premise on VMWare host.  Host with 2 LAN card, one for LAN and another for WAN.  WAN adapter had external IP independent from LAN.

3. Since new server not working on existing Domain name and IP, it is now running simulatenously together with current server but with different LAN and WAN IP for troubleshooting

4. Telnet -- already test within own LAN as well as externally (from my home and at another office) -- both can successfully telnet port 25 of new server, on both WAN IP (24 & 28 when trying to switch).

Existing server setup: Citadel on Ubuntu 18.04 VM on VMWare, WAN IP xxx.xxx.xxx.28.  Server had been running since 2018 and having maintenence issue therefore prepared to be replaced.

New server now prepared: Citadel on Debian 13 VM on VMWare, WAN IP xxx.xxx.xxx.24.  Completely new install and not migration.  Both server on SAME vmware host with same network adapter, both LAN and WAN.

Problem: after shutdown existing server, and replace the new server to IP ending with 28, it does not receive external mail nor passing MXTOOLBOX server test.  However when placing back to IP ending with 24, MXTOOLBOX test (using IP) works.  Returning the existing server back online will have everything working fine.

Tue Mar 31 2026 10:04:57 AM UTC from Motobike Subject: Re: New Citadel Installation not receiving mail nor response to external SMTP check

Hi Alan,

 

i think, i need some more details about your setup. 

The DNS entrys doenst need to change. 

Your Citadel installation is on premise / selfhosted inside your own network?

If the new server have a different IP Address, maybe it wouldnt work. Do you checked your Firewall ports and port routing ? 

If you Citadel is inside your network, can you telnet from a different computer to your Citadel Server ?

 

For more details about your setup you can mail me if you want. Maybe there  informations not for everyones eyes, but the solution is good for all. 

 

Greetings 

Mike

michael@g00r00.com

 

 

Hi Alan,

i think, i need some more details about your setup. 

The DNS entrys doenst need to change. 

Your Citadel installation is on premise / selfhosted inside your own network?

If the new server have a different IP Address, maybe it wouldnt work. Do you checked your Firewall ports and port routing ? 

If you Citadel is inside your network, can you telnet from a different computer to your Citadel Server ?

For more details about your setup you can mail me if you want. Maybe there  informations not for everyones eyes, but the solution is good for all. 

Greetings 

Mike

michael@g00r00.com

Di Mär 31 2026 09:09:38 UTC von alanlau Betreff: Re: New Citadel Installation not receiving mail nor response to external SMTP check

Hi Mike,

My server is running on VMs.  Since my new server is not working last week, I had reinstate the old server VM back to use the original Domain and IP, and I had the new server VM continue running but use another IP.

If running on another IP, it response to MXTOOLBOX mail server test.

If put the new server back to my original IP, it doesn't.

Had used your command to check the common ports  (24/456/587 etc) are all listening by Citadel only.

Will it be any relations to DNS setting that binded to the original old server? Such as MAC address binding?  

 

Mon Mar 30 2026 06:37:27 AM UTC from Motobike Subject: Re: New Citadel Installation not receiving mail nor response to external SMTP check

Hi Alan,

please try to figure out, whats going on.

 

Check Services on Ports:

ss -tulpn

Also you can swtich port inside Citadel to antoher MTA Port and check, if you can Telnet it. Do you import Setting from an old Citadel installation ? 

I checked lates Debian and Ubuntu Version with Citadel and had no problems. 

 

Sorry the previous message typo - ports 25/465/587 

Hi Mike,

My server is running on VMs.  Since my new server is not working last week, I had reinstate the old server VM back to use the original Domain and IP, and I had the new server VM continue running but use another IP.

If running on another IP, it response to MXTOOLBOX mail server test.

If put the new server back to my original IP, it doesn't.

Had used your command to check the common ports  (24/456/587 etc) are all listening by Citadel only.

Will it be any relations to DNS setting that binded to the original old server? Such as MAC address binding?  

Mon Mar 30 2026 06:37:27 AM UTC from Motobike Subject: Re: New Citadel Installation not receiving mail nor response to external SMTP check

Hi Alan,

please try to figure out, whats going on.

 

Check Services on Ports:

ss -tulpn

Also you can swtich port inside Citadel to antoher MTA Port and check, if you can Telnet it. Do you import Setting from an old Citadel installation ? 

I checked lates Debian and Ubuntu Version with Citadel and had no problems. 

 

Hi Alan,

please try to figure out, whats going on.

Check Services on Ports:

ss -tulpn

Also you can swtich port inside Citadel to antoher MTA Port and check, if you can Telnet it. Do you import Setting from an old Citadel installation ? 

I checked lates Debian and Ubuntu Version with Citadel and had no problems. 

My Settings:

Mo Mär 30 2026 01:25:28 UTC von alanlau Betreff: Re: New Citadel Installation not receiving mail nor response to external SMTP check

I just writing here to report that my previous new Debian installation for Citadel wasn't working as expected, with same result that unable to receive external message nor response to MXTOOLBOX server test.

When I first preparing it I used another IP for both internal and external network and it works fine.  However when I change back to my original email domain's IP address it just not responding.

Even though it's not responding to MXTOOLBOX server test, it does response to telnet port 25.  

I had no choice but put the old server back and everything fine again.  I am still investigating the reason....

Great ;)

Problem solved. But i will test it on a new Ubuntu installation and figure out, what the problem is. 

Hve a nice day

Greetings 

Mike

Mi Mär 25 2026 01:32:16 UTC von alanlau Betreff: Re: New Citadel Installation not receiving mail nor response to external SMTP check

Hi Mike,

Successfully tested on Debian 13 and works like a charm.

Therefore I concluded it MUST be ubuntu's problem, or at least its on OS setting I'm not awared of.

I had prepared a native Debian 13 and using native installation by Easyinstall script.

Tue Mar 24 2026 05:38:54 PM UTC from Motobike Subject: Re: New Citadel Installation not receiving mail nor response to external SMTP check

Hi, its not that different to Ubuntu. Its the same base. 

So i think you dont have any problems to use it. How you install citadel on Ubuntu ? As a Docker Container or nativ ? you need to chown right on Ubuntu. 

The problem is not the OS itself. 

 

But if you can telnet citdael on port 25, it might be not a OS problem. i think its a administrativ right problem for citadel or the service.

you checked the status for citadel service ?

 

systemctl status citadel.service

 

Greetings Mike

 

D

Hi Mike,

Successfully tested on Debian 13 and works like a charm.

Therefore I concluded it MUST be ubuntu's problem, or at least its on OS setting I'm not awared of.

I had prepared a native Debian 13 and using native installation by Easyinstall script.

Tue Mar 24 2026 05:38:54 PM UTC from Motobike Subject: Re: New Citadel Installation not receiving mail nor response to external SMTP check

Hi, its not that different to Ubuntu. Its the same base. 

So i think you dont have any problems to use it. How you install citadel on Ubuntu ? As a Docker Container or nativ ? you need to chown right on Ubuntu. 

The problem is not the OS itself. 

 

But if you can telnet citdael on port 25, it might be not a OS problem. i think its a administrativ right problem for citadel or the service.

you checked the status for citadel service ?

 

systemctl status citadel.service

 

Greetings Mike

 

D

Hi, its not that different to Ubuntu. Its the same base. 

So i think you dont have any problems to use it. How you install citadel on Ubuntu ? As a Docker Container or nativ ? you need to chown right on Ubuntu. 

The problem is not the OS itself. 

But if you can telnet citdael on port 25, it might be not a OS problem. i think its a administrativ right problem for citadel or the service.

you checked the status for citadel service ?

systemctl status citadel.service

Greetings Mike

Di Mär 24 2026 01:22:45 UTC von alanlau Betreff: Re: New Citadel Installation not receiving mail nor response to external SMTP check

Thanks for suggestion, and it confirmed one of my suspicion: its the OS broke it instead of Citadel  ;>

Since I'm not too familier on Debian I may need some time to test this configuration and will come up again once I am able to test it.

 

Mon Mar 23 2026 08:10:30 AM UTC from Motobike Subject: Re: New Citadel Installation not receiving mail nor response to external SMTP check

Yeah,

i know the Problem. I got such problem with Ubuntu too. I think, the UFW is turned off. I fixed the incoming MTA and use Postfix -> rspamD -> SMTP Citadel 2025. For more compatibility, try a normal Debian installation for a Citadel only installation. 

Oherwise check what the logs say..

tail -f /var/log/syslog 

and trace it to a file to analyse whats going on. 

 

Mike

 

Mo Mär 23 2026 02:32:44 UTC von alanlau Betreff: Re: New Citadel Installation not receiving mail nor response to external SMTP check

Hi Mike,

I used to run the mentioned MX test by MXTOOLBOX and having the result of server not responding.

All DNS records were not changed as with the existing old Citadel server.  Everything works fine on old one, but just not the case if I directly replace a new Citadel with it.

I install and tested the new server on both Ubuntu 22.04 and 24.04, as I wonder it is the OS lead to not responding instead of Citadel.

Any idea on it?

 

 

Thanks for suggestion, and it confirmed one of my suspicion: its the OS broke it instead of Citadel  ;>

Since I'm not too familier on Debian I may need some time to test this configuration and will come up again once I am able to test it.

Mon Mar 23 2026 08:10:30 AM UTC from Motobike Subject: Re: New Citadel Installation not receiving mail nor response to external SMTP check

Yeah,

i know the Problem. I got such problem with Ubuntu too. I think, the UFW is turned off. I fixed the incoming MTA and use Postfix -> rspamD -> SMTP Citadel 2025. For more compatibility, try a normal Debian installation for a Citadel only installation. 

Oherwise check what the logs say..

tail -f /var/log/syslog 

and trace it to a file to analyse whats going on. 

 

Mike

 

Mo Mär 23 2026 02:32:44 UTC von alanlau Betreff: Re: New Citadel Installation not receiving mail nor response to external SMTP check

Hi Mike,

I used to run the mentioned MX test by MXTOOLBOX and having the result of server not responding.

All DNS records were not changed as with the existing old Citadel server.  Everything works fine on old one, but just not the case if I directly replace a new Citadel with it.

I install and tested the new server on both Ubuntu 22.04 and 24.04, as I wonder it is the OS lead to not responding instead of Citadel.

Any idea on it?

 

Yeah,

i know the Problem. I got such problem with Ubuntu too. I think, the UFW is turned off. I fixed the incoming MTA and use Postfix -> rspamD -> SMTP Citadel 2025. For more compatibility, try a normal Debian installation for a Citadel only installation. 

Oherwise check what the logs say..

tail -f /var/log/syslog 

and trace it to a file to analyse whats going on. 

Mike

Mo Mär 23 2026 02:32:44 UTC von alanlau Betreff: Re: New Citadel Installation not receiving mail nor response to external SMTP check

Hi Mike,

I used to run the mentioned MX test by MXTOOLBOX and having the result of server not responding.

All DNS records were not changed as with the existing old Citadel server.  Everything works fine on old one, but just not the case if I directly replace a new Citadel with it.

I install and tested the new server on both Ubuntu 22.04 and 24.04, as I wonder it is the OS lead to not responding instead of Citadel.

Any idea on it?

Hi Mike,

I used to run the mentioned MX test by MXTOOLBOX and having the result of server not responding.

All DNS records were not changed as with the existing old Citadel server.  Everything works fine on old one, but just not the case if I directly replace a new Citadel with it.

I install and tested the new server on both Ubuntu 22.04 and 24.04, as I wonder it is the OS lead to not responding instead of Citadel.

Any idea on it?

Hi, 

you checked the DNS for a A Record and a AAAA Record ?

Some ISP will use AAAA only.

If you can telnet the port 25, it looks fine. Also you can check with mxtoolbox.

Greetings

Mike

Di Mär 17 2026 02:43:59 UTC von alanlau Betreff: New Citadel Installation not receiving mail nor response to external SMTP check

Dear team,

We had been running Citadel since 2008 and now preparing a new Citadel server to replace the old one because of the age and capacity.

We setup and configurared a new VM for Citadel, copied most of the running settings to it, and it works well internally, however it just not responsing to external messages.

That is, it successfully send messages, but not receiving any from outside.

Confirm all necessary ports are opened.

Running MX tool SMTP check on internet shows the server is not responding.

However if we telnet the server IP address, it responses.  

May I ask whether there are missing configuration we needed?

Alan Lau

 

Tue Mar 17 2026 08:51:47 AM UTC from alanlau Subject: Re: Received not sent

Harry are you asking me about your question?

As long as you described, it looks like your account in Citadel was created with "Permission to send internet mail" option checked.

If you are not your Citadel administrator, you will need to found him to open that option for you.

Just my 2 cents

Alan

Sorry I mean "not checked" instead of "checked"

Thanks Alan for the help.

Harry

Tue Mar 17 2026 08:53:54 UTC from alanlau Subject: Re: Received not sent

 

Tue Mar 17 2026 08:51:47 AM UTC from alanlau Subject: Re: Received not sent

Harry are you asking me about your question?

As long as you described, it looks like your account in Citadel was created with "Permission to send internet mail" option checked.

If you are not your Citadel administrator, you will need to found him to open that option for you.

Just my 2 cents

Alan

Sorry I mean "not checked" instead of "checked"

Tue Mar 17 2026 08:51:47 AM UTC from alanlau Subject: Re: Received not sent

Harry are you asking me about your question?

As long as you described, it looks like your account in Citadel was created with "Permission to send internet mail" option checked.

If you are not your Citadel administrator, you will need to found him to open that option for you.

Just my 2 cents

Alan

Sorry I mean "not checked" instead of "checked"

Harry are you asking me about your question?

As long as you described, it looks like your account in Citadel was created with "Permission to send internet mail" option checked.

If you are not your Citadel administrator, you will need to found him to open that option for you.

Just my 2 cents

Alan

Dear team,

We had been running Citadel since 2008 and now preparing a new Citadel server to replace the old one because of the age and capacity.

We setup and configurared a new VM for Citadel, copied most of the running settings to it, and it works well internally, however it just not responsing to external messages.

That is, it successfully send messages, but not receiving any from outside.

Confirm all necessary ports are opened.

Running MX tool SMTP check on internet shows the server is not responding.

However if we telnet the server IP address, it responses.  

May I ask whether there are missing configuration we needed?

Alan Lau

Hi Alan,

Harry received an email from the internet but did not have permission to send a reply. Who can give me permission? What port numbes are is used for Citadel emails in and out?

Thanks for your help.

Harry

Dear team,

We had been running Citadel since 2008 and now preparing a new Citadel server to replace the old one because of the age and capacity.

We setup and configurared a new VM for Citadel, copied most of the running settings to it, and it works well internally, however it just not responsing to external messages.

That is, it successfully send messages, but not receiving any from outside.

Confirm all necessary ports are opened.

Running MX tool SMTP check on internet shows the server is not responding.

However if we telnet the server IP address, it responses.  

May I ask whether there are missing configuration we needed?

Alan Lau

Hi,

User harry could not reply to an email and was shown this message: 

You do not have permission to send Internet mail.

Please let me send email.

Cheers,

Harry

My solution is this:

[Unit]

Description=Citadel WebCit HTTP Redirect

After=citadel.target

[Service]

ExecStart=/usr/local/webcit/webcit \

    -p80 \

    -R https://%H \

    uds /usr/local/citadel

KillMode=process

Restart=always

RestartSec=3

[Install]

WantedBy=multi-user.target

Di Jan 27 2026 20:04:40 UTC von Motobike Betreff: Re: First Room

Hi Ignatius,

do you habe a quick hint for me, how to redirect the webcit http service to https ?

webcit -x1 -p 80 -g ? 

Also i have question to your http to telnet webservice. What Tool are you using ?

 

Citadel is now fully stable running for 1 year. It was the best dession for all my needs :)

o/

Mike

Do Mai 01 2025 09:26:51 UTC von Motobike Betreff: Re: First Room

Hi Ignatius,

but where will it be defined ? First start citadel, it will defined in a config that starts webcit with parameters X. 

 

Do Feb 13 2025 23:38:47 UTC von IGnatius T Foobar Betreff: Re: First Room

What you mean with [other options] ?

WebCit is normally called with options to specify the port number it's listening on, whether to enable HTTPS, and the directory where Citadel Server can be found.

For example, here are the commands we are using to start WebCit here:

webcit -x1 -s -p 443 -g /dotgoto?room='Welcome to UNCENSORED!' uds /citadel-data
webcit -x1 -p 80 -g /dotgoto?room='Welcome to UNCENSORED!' uds /citadel-data

(Most sites will have two, one for HTTP and one for HTTPS, but if you have Citadel sitting behind a proxy or if you have some other webserver redirecting HTTP to HTTPS you might only have one.)

 

 

Hi Ignatius,

do you habe a quick hint for me, how to redirect the webcit http service to https ?

webcit -x1 -p 80 -g ? 

Also i have question to your http to telnet webservice. What Tool are you using ?

Citadel is now fully stable running for 1 year. It was the best dession for all my needs :)

o/

Mike

Do Mai 01 2025 09:26:51 UTC von Motobike Betreff: Re: First Room

Hi Ignatius,

but where will it be defined ? First start citadel, it will defined in a config that starts webcit with parameters X. 

 

Do Feb 13 2025 23:38:47 UTC von IGnatius T Foobar Betreff: Re: First Room

What you mean with [other options] ?

WebCit is normally called with options to specify the port number it's listening on, whether to enable HTTPS, and the directory where Citadel Server can be found.

For example, here are the commands we are using to start WebCit here:

webcit -x1 -s -p 443 -g /dotgoto?room='Welcome to UNCENSORED!' uds /citadel-data
webcit -x1 -p 80 -g /dotgoto?room='Welcome to UNCENSORED!' uds /citadel-data

(Most sites will have two, one for HTTP and one for HTTPS, but if you have Citadel sitting behind a proxy or if you have some other webserver redirecting HTTP to HTTPS you might only have one.)

 

For things like this, 'reaching out' TOR is brain dead easy.  Just fire up the TOR browser. Done.  ( sure there are other ways, but why futz with it? )   For incoming, its not really hard either, but does limit your audience greatly if its the ONLY route in since fewer people will know about you.

And some of us, well, we have our reasons for doing it.

Sat Jan 24 2026 06:19:22 UTC from ParanoidDelusions

I'm insolent. I can use the onion... I understand it - but I want them to know - and I want to know they know, but don't really care, as long as I stay in my lane. It is a lot of extra effort to use TOR, just to make them MORE interested in what you may or may not be doing. 

I am a "security through opacity" kind of guy. If they can see it - without TOR and VPNs - they don't care. If I start making it difficult to track and watch - then they might pay more attention and something they would otherwise miss - might be caught. 

 

I'm insolent. I can use the onion... I understand it - but I want them to know - and I want to know they know, but don't really care, as long as I stay in my lane. It is a lot of extra effort to use TOR, just to make them MORE interested in what you may or may not be doing. 

I am a "security through opacity" kind of guy. If they can see it - without TOR and VPNs - they don't care. If I start making it difficult to track and watch - then they might pay more attention and something they would otherwise miss - might be caught. 

Without it, its not like things are unusable,  just it would speed access up a little and prevent me from having to re-post when it gets eaten. Just me, not worth effort really, but it might increase traffic too. I'm sure  i am not the only person hiding inside the onion... 

Thu Jan 22 2026 23:40:03 UTC from IGnatius T Foobar

If I put Uncensored on a .onion proxy, would that be beneficial to you?

Regular VPNs work fine.  There are a lot of cheap ones, and some free ones too.  Might be enough for you to hide behind? ( not slamming.. just donno how far you have to hide..)

Not that it matters, and i know you cant support incoming via a TOR out-port since its out of your control, but just to add after some testing and paying better attention:

Logging in seems to work 99% of the time. But sometimes i get a 'not found' which i guess does happen sometimes.  Posting, when it does not work, i finally saw the message today relating to not posting an empty post.  Been taking a copy of the post first, so i can easily redo easily if it bombs. Seems like on the 3rd try it works. 

I know its my problem not yours, but still be neat if you added a TOR proxy to go along with the I2P proxy. ( since i have never had any luck getting to the outside via I2P, tho i read its possible, somehow )

If you are looking to run a citadel server but only have Windows I provide Ubuntu hosting starting at $7/month with first month free to try it out... Get more info at https://citadelhosting.retro-os.live.

Marisa

I would like to know, if the software has a windows version?

You could run it in WSL, or in Docker on Windows.

But there's no native Windows version.

I would like to know, if the software has a windows version?

You could run it in WSL, or in Docker on Windows.

But there's no native Windows version.

Did you share the URL? Is Other BBSs> a thing still? 

Don't assume it's a BBS.  The vast majority of Citadel instances are not.

I would like to know, if the software has a windows version?

Did you share the URL? Is Other BBSs> a thing still? 

Sat Jan 03 2026 17:18:59 UTC from Kurisu

Killer - worked a treat.

Thank ya.

So happy to be running a citadel instance again.

Fri Jan 02 2026 17:05:41 UTC from IGnatius T Foobar

 

Dear All,

Exists or not any way to send emails for a certain domain forcing IPv4 and not using IPv6 as normal?

For any other domains remains unchanged.

Thank you,

Luís Gonçalves. 

Killer - worked a treat.

Thank ya.

So happy to be running a citadel instance again.

Fri Jan 02 2026 17:05:41 UTC from IGnatius T Foobar

You want the "-g" flag, which allows you to pre-fill a location of your choice to use as the landing page.

For example, here we use:

webcit [other flags] -g '/dotgoto?room=Welcome to UNCENSORED!' [other arguments]

This works when you're calling WebCit directly from the host, as you would when running the Easy Install distribution, but it also works when you're running the Docker container: the "-g" flag and its argument are passed through from the caller to both WebCit instances (which is how I run it here).

Minor question, what was the flag to have webcit-http and webcit-https display a particular room (as opposed to defaulting to lobby) like Uncensored does with its wiki page? Had that going fine on a previous Citadel instance which has since been retired and I'd like to do that again for this new one but can't find the information anymore.

Thanks!

Right, and has the SPA been built in such a way as to make the back button do something that makes sense? :D

Wed Dec 31 2025 06:26:39 UTC from IGnatius T Foobar

Will the "Back" button on the browser in the next WebCit
actually work properly, or just be psycho like it is now? :-D

WebCit-NG is going to be a whole different ballgame. Since it's a "one page web app" the semantics are different.

I doubt WebCit-classic is going to get any more love in that department.

Will the "Back" button on the browser in the next WebCit actually work properly, or just be psycho like it is now? :-D

For me its not anger, its facepalm.

And sorry, its the wrong room.

Sun Dec 28 2025 00:55:07 UTC from IGnatius T Foobar

I struggle with Christian compassion. A lot. Charlie Kirk would
be disappointed. 

You're not alone. Not by far. It's one of those things we struggle with -- as believers we want to show Christ-like love and compassion, while as humans we want to choke the living shit out of some asshole who desperately deserves it.

Yeah. I struggle with anger sometimes. We aren't all as far along as Charlie was. But we all receive the same measure of grace if we ask for it. And that's pretty darn cool.

Most of us do, its not the 1980s anymore.   ( really in any industry, not just IT )

I have moved to the attitude of "whatever, let it burn" and go grab a bag of marshmallows.

Fri Dec 26 2025 06:45:41 UTC from ParanoidDelusions

You're nicer than me. I deal with highly educated, industry specific idiots who f'k things up every day and it makes us all pay more. 

You're nicer than me. I deal with highly educated, industry specific idiots who f'k things up every day and it makes us all pay more. I feel like we should be mean those people. 

I struggle with Christian compassion. A lot. Charlie Kirk would be disappointed. 

Thu Dec 25 2025 14:11:44 UTC from Nurb432

It happens sometimes. Newbies don't know. Often times IG will move it. 

 

Right room. How can developer people be so stupid? I can't code - but I'm not dumb enough to dump this in the lobby. 

Maybe it is me. 

It happens sometimes. Newbies don't know. Often times IG will move it. 

Thu Dec 25 2025 07:40:44 UTC from ParanoidDelusions

Well, I feel this wasn't the right room for THAT. 

Glad it didn't somehow crash Uncensored. 

Anyhow - Merry Christmas, and goodnight. ;) 

 

Well, I feel this wasn't the right room for THAT. 

Glad it didn't somehow crash Uncensored. 

Anyhow - Merry Christmas, and goodnight. ;) 

Hello Citadel Team,

I'm reporting a reproducible segmentation fault (SIGSEGV) observed in production, which appears to be caused by a concurrency / thread-safety issue in Citadel under normal usage conditions. I have collected multiple core dumps showing consistent call patterns and triggers.

Deployment: Docker

OS: Linux x86_64 (glibc-based)

Protocols in use:

* IMAPS

* SMTP (inbound + outbound)

* SMTP queue delivery

Sieve: Enabled (email forwarding rules)

No custom patches. No abnormal traffic patterns.

Observed Behaviour

Citadel crashes with SIGSEGV during normal operation. The crashes began after ~26 weeks of stable, uninterrupted operation, without any infrastructure or configuration changes. The only relevant behavioural change before the first crash was the introduction of new Sieve forwarding rules, which increased outbound SMTP activity.

From Core Dumps

The crashes consistently occur when the following operations overlap in time:

Thread A – IMAP FETCH (user reading mail)

imap_fetch_body()

imap_do_fetch_msg()

imap_do_fetch()

imap_command_loop()

Thread B – SMTP DATA (receiving mail)

smtp_data()

smtp_command_loop()

CtdlReadMessageBodyBuf()

StrBufTCP_read_buffered_line_fast()

Thread C – SMTP Forwarding / Queue Delivery

smtp_attempt_delivery()

smtp_do_queue()

smtp_do_queue_full()

curl_easy_perform()

curl_multi_poll()

Additional Concurrent Activity

* TLS handshakes (CtdlStartTLS, imaps_greeting, pop3s_greeting)

* Session cleanup and hooks (PerformSessionHooks, do_housekeeping)

* In some crashes, XMPP hooks are also active

Analysis / Suspected Root Cause

Based on repeated core dump analysis:

• These execution paths share internal buffers/message structures

• Some of these paths appear not to be fully thread-safe

• Increased outbound SMTP concurrency (introduced by Sieve forwarding) significantly raises the likelihood of these paths overlapping

• This results in memory corruption, eventually causing a SIGSEGV (often observed shortly after read(), select(), or buffer handling)

Important notes:

• The Sieve rules themselves are valid and correctly defined

• The issue is not caused by user error or misconfiguration

• Forwarding acts as a trigger, not the root defect

Reproduction Pattern (High-Level)

While not 100% deterministic, the crash frequency increases significantly when:

1. Sieve forwarding is enabled for active mailboxes

2. Inbound SMTP traffic is present

3. Users fetch messages (IMAP FETCH) concurrently

4. SMTP queue delivery runs in parallel (especially to external domains)

Reducing worker thread concurrency significantly reduces or eliminates crashes, which further suggests a concurrency-related issue.

Expected Behaviour

Citadel should be able to safely handle concurrent:

• IMAP FETCH

• SMTP DATA

• SMTP forwarding (Sieve)

• SMTP queue delivery

without memory corruption or segmentation faults.

Questions for the Development Team

1. Is this a known concurrency issue?

2. Has this behaviour been addressed in newer Citadel versions?

3. Are there recommended patches, configuration flags, or build options to mitigate this safely?

4. Would additional debugging data (full core dumps, symbols, logs) be helpful?

Thank you for your time and for maintaining Citadel.

root@tpc-co-cit02:/# gdb /usr/local/citadel/citserver /citadel-data/server1-backup/core.7 

GNU gdb (Debian 10.1-1.7) 10.1.90.20210103-git

Copyright (C) 2021 Free Software Foundation, Inc.

License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software: you are free to change and redistribute it.

There is NO WARRANTY, to the extent permitted by law.

Type "show copying" and "show warranty" for details.

This GDB was configured as "x86_64-linux-gnu".

Type "show configuration" for configuration details.

For bug reporting instructions, please see:

<https://www.gnu.org/software/gdb/bugs/>.

Find the GDB manual and other documentation resources online at:

    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".

Type "apropos word" to search for commands related to "word"...

Reading symbols from /usr/local/citadel/citserver...

(No debugging symbols found in /usr/local/citadel/citserver)

[New LWP 69]

[New LWP 18]

[New LWP 116]

[New LWP 113]

[New LWP 7]

[New LWP 105]

[New LWP 15]

[New LWP 92]

[New LWP 120]

[New LWP 10]

[New LWP 67]

[New LWP 597]

[New LWP 11]

[Thread debugging using libthread_db enabled]

Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Core was generated by `citserver -x9 -h /citadel-data'.

Program terminated with signal SIGSEGV, Segmentation fault.

#0  0x0000561e86ca5f3f in imap_fetch_body ()

[Current thread is 1 (Thread 0x7f280bfff700 (LWP 69))]

(gdb) set pagination off

(gdb) thread apply all bt full

Thread 13 (Thread 0x7f28225c7700 (LWP 11)):

#0  0x00007f2825d27a0f in __GI___poll (fds=0x7f28225bf870, nfds=2, timeout=1000) at ../sysdeps/unix/sysv/linux/poll.c:29

        __arg2 = <optimized out>

        _a3 = 1000

        _a1 = 139810351872112

        resultvar = <optimized out>

        __arg3 = <optimized out>

        __arg1 = <optimized out>

        _a2 = 2

        resultvar = <optimized out>

        sc_cancel_oldtype = <optimized out>

        sc_ret = <optimized out>

#1  0x00007f2825e75bca in ?? () from /usr/lib/x86_64-linux-gnu/libcurl.so.4

No symbol table info available.

#2  0x00007f2825e6abcc in ?? () from /usr/lib/x86_64-linux-gnu/libcurl.so.4

No symbol table info available.

#3  0x00007f2825e6ad56 in curl_multi_poll () from /usr/lib/x86_64-linux-gnu/libcurl.so.4

No symbol table info available.

#4  0x00007f2825e439cf in curl_easy_perform () from /usr/lib/x86_64-linux-gnu/libcurl.so.4

No symbol table info available.

#5  0x0000561e86cc32c5 in smtp_attempt_delivery ()

No symbol table info available.

#6  0x0000561e86cc38f2 in smtp_process_one_msg ()

No symbol table info available.

#7  0x0000561e86cc3f33 in smtp_do_queue ()

No symbol table info available.

#8  0x0000561e86cc3fbf in smtp_do_queue_full ()

No symbol table info available.

#9  0x0000561e86c87e13 in PerformSessionHooks ()

No symbol table info available.

#10 0x0000561e86c73dd5 in do_housekeeping ()

No symbol table info available.

#11 0x0000561e86c8a952 in worker_thread ()

No symbol table info available.

#12 0x00007f2825fd1ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477

        ret = <optimized out>

        pd = <optimized out>

        unwind_buf = {cancel_jmp_buf = {{jmp_buf = {139810351904512, -5926168278360471484, 140734826778382, 140734826778383, 139810351902080, 8396800, 6021948088529373252, 6021962115441018948}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}

        not_first_call = 0

#13 0x00007f2825d33acf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:71

No locals.

#14 0x0000000000000000 in ?? ()

No symbol table info available.

Thread 12 (Thread 0x7f2808ff9700 (LWP 597)):

#0  0x00007f2825d29ec3 in __GI___select (nfds=59, readfds=0x7f2808ff8bf0, writefds=0x0, exceptfds=0x0, timeout=0x7f2808ff8be0) at ../sysdeps/unix/sysv/linux/select.c:41

        __arg3 = 0

        _a5 = 139809926384608

        _a2 = 139809926384624

        __arg4 = 0

        __arg1 = 59

        _a3 = 0

        resultvar = <optimized out>

        __arg5 = 139809926384608

        __arg2 = 139809926384624

        _a4 = 0

        _a1 = 59

        resultvar = <optimized out>

        sc_cancel_oldtype = -514

        sc_ret = <optimized out>

#1  0x0000561e86c8a447 in worker_thread ()

No symbol table info available.

#2  0x00007f2825fd1ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477

        ret = <optimized out>

        pd = <optimized out>

        unwind_buf = {cancel_jmp_buf = {{jmp_buf = {139809926387456, -5926168278360471484, 140734826778382, 140734826778383, 139809926385024, 139809977318912, 6021898356029311044, 6021962115441018948}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}

        not_first_call = 0

#3  0x00007f2825d33acf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:71

No locals.

#4  0x0000000000000000 in ?? ()

No symbol table info available.

Thread 11 (Thread 0x7f2820dbc700 (LWP 67)):

#0  __libc_read (nbytes=8191, buf=0x7f2810130b10, fd=33) at ../sysdeps/unix/sysv/linux/read.c:26

        resultvar = 18446744073709551104

        sc_cancel_oldtype = 0

        __arg3 = <optimized out>

        _a2 = <optimized out>

        sc_ret = <optimized out>

        __value = <optimized out>

        __arg1 = <optimized out>

        _a3 = <optimized out>

        resultvar = <optimized out>

        resultvar = <optimized out>

        __arg2 = <optimized out>

        _a1 = <optimized out>

#1  __libc_read (fd=33, buf=0x7f2810130b10, nbytes=8191) at ../sysdeps/unix/sysv/linux/read.c:24

No locals.

#2  0x00007f2825fffed6 in StrBufTCP_read_buffered_line_fast (Line=0x7f28100fe740, IOBuf=0x7f28000dfb30, Pos=0x7f28000a36e0, fd=0x7f28000a3728, timeout=5, selectresolution=<optimized out>, Error=0x7f2820dba9a0) at lib/stringbuf.c:4317

        pche = <optimized out>

        pos = <optimized out>

        pLF = 0x0

        len = <optimized out>

        rlen = <optimized out>

        retlen = 19

        nSuccessLess = 0

        rfds = {fds_bits = {0, 524288, 126, 32783, 524336, 8192, 35390530551809, 541165879534, 128, 579820586075, 1024, 16, 131072, 4096, 524288, 978326477955633920}}

        pch = <optimized out>

        fdflags = <optimized out>

        IsNonBlock = 0

        tv = {tv_sec = 32767, tv_usec = 7}

#3  0x0000561e86c89cbb in CtdlClientGetLine ()

No symbol table info available.

#4  0x0000561e86c81944 in CtdlReadMessageBodyBuf ()

No symbol table info available.

#5  0x0000561e86cc1847 in smtp_data ()

No symbol table info available.

#6  0x0000561e86cc2227 in smtp_command_loop ()

No symbol table info available.

#7  0x0000561e86c8a8a7 in worker_thread ()

No symbol table info available.

#8  0x00007f2825fd1ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477

        ret = <optimized out>

        pd = <optimized out>

        unwind_buf = {cancel_jmp_buf = {{jmp_buf = {139810326693632, -5926168278360471484, 140734826778382, 140734826778383, 139810326691200, 8396800, 6021951441288218692, 6021962115441018948}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}

        not_first_call = 0

#9  0x00007f2825d33acf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:71

No locals.

#10 0x0000000000000000 in ?? ()

No symbol table info available.

Thread 10 (Thread 0x7f2822dc8700 (LWP 10)):

#0  0x00007f2825d29ec3 in __GI___select (nfds=59, readfds=0x7f2822dc7bf0, writefds=0x0, exceptfds=0x0, timeout=0x7f2822dc7be0) at ../sysdeps/unix/sysv/linux/select.c:41

        __arg3 = 0

        _a5 = 139810360294368

        _a2 = 139810360294384

        __arg4 = 0

        __arg1 = 59

        _a3 = 0

        resultvar = <optimized out>

        __arg5 = 139810360294368

        __arg2 = 139810360294384

        _a4 = 0

        _a1 = 59

        resultvar = <optimized out>

        sc_cancel_oldtype = -514

        sc_ret = <optimized out>

#1  0x0000561e86c8a447 in worker_thread ()

No symbol table info available.

#2  0x00007f2825fd1ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477

        ret = <optimized out>

        pd = <optimized out>

        unwind_buf = {cancel_jmp_buf = {{jmp_buf = {139810360297216, -5926168278360471484, 140734826778382, 140734826778383, 139810360294784, 8396800, 6021946989554616388, 6021962115441018948}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}

        not_first_call = 0

#3  0x00007f2825d33acf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:71

No locals.

#4  0x0000000000000000 in ?? ()

No symbol table info available.

Thread 9 (Thread 0x7f28097fa700 (LWP 120)):

#0  0x00007f2825d29ec3 in __GI___select (nfds=59, readfds=0x7f28097f9bf0, writefds=0x0, exceptfds=0x0, timeout=0x7f28097f9be0) at ../sysdeps/unix/sysv/linux/select.c:41

        __arg3 = 0

        _a5 = 139809934777312

        _a2 = 139809934777328

        __arg4 = 0

        __arg1 = 59

        _a3 = 0

        resultvar = <optimized out>

        __arg5 = 139809934777312

        __arg2 = 139809934777328

        _a4 = 0

        _a1 = 59

        resultvar = <optimized out>

        sc_cancel_oldtype = -514

        sc_ret = <optimized out>

#1  0x0000561e86c8a447 in worker_thread ()

No symbol table info available.

#2  0x00007f2825fd1ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477

        ret = <optimized out>

        pd = <optimized out>

        unwind_buf = {cancel_jmp_buf = {{jmp_buf = {139809934780160, -5926168278360471484, 140734826778382, 140734826778383, 139809934777728, 139810111629120, 6021901655101065284, 6021962115441018948}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}

        not_first_call = 0

#3  0x00007f2825d33acf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:71

No locals.

#4  0x0000000000000000 in ?? ()

No symbol table info available.

Thread 8 (Thread 0x7f280b7fe700 (LWP 92)):

#0  0x00007f2825d29ec3 in __GI___select (nfds=59, readfds=0x7f280b7fdbf0, writefds=0x0, exceptfds=0x0, timeout=0x7f280b7fdbe0) at ../sysdeps/unix/sysv/linux/select.c:41

        __arg3 = 0

        _a5 = 139809968348128

        _a2 = 139809968348144

        __arg4 = 0

        __arg1 = 59

        _a3 = 0

        resultvar = <optimized out>

        __arg5 = 139809968348128

        __arg2 = 139809968348144

        _a4 = 0

        _a1 = 59

        resultvar = <optimized out>

        sc_cancel_oldtype = -514

        sc_ret = <optimized out>

#1  0x0000561e86c8a447 in worker_thread ()

No symbol table info available.

#2  0x00007f2825fd1ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477

        ret = <optimized out>

        pd = <optimized out>

        unwind_buf = {cancel_jmp_buf = {{jmp_buf = {139809968350976, -5926168278360471484, 140734826778382, 140734826778383, 139809968348544, 139810110988112, 6021897259202037828, 6021962115441018948}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}

        not_first_call = 0

#3  0x00007f2825d33acf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:71

No locals.

#4  0x0000000000000000 in ?? ()

No symbol table info available.

Thread 7 (Thread 0x7f2821dbe700 (LWP 15)):

#0  __libc_read (nbytes=63, buf=0x7f27e4122af0, fd=57) at ../sysdeps/unix/sysv/linux/read.c:26

        resultvar = 18446744073709551104

        sc_cancel_oldtype = 0

        __arg3 = <optimized out>

        _a2 = <optimized out>

        sc_ret = <optimized out>

        __value = <optimized out>

        __arg1 = <optimized out>

        _a3 = <optimized out>

        resultvar = <optimized out>

        resultvar = <optimized out>

        __arg2 = <optimized out>

        _a1 = <optimized out>

#1  __libc_read (fd=57, buf=0x7f27e4122af0, nbytes=63) at ../sysdeps/unix/sysv/linux/read.c:24

No locals.

#2  0x00007f2825fffed6 in StrBufTCP_read_buffered_line_fast (Line=0x7f2818078d50, IOBuf=0x7f27ec0fc8b0, Pos=0x7f27e4079ec0, fd=0x7f27e4079f08, timeout=5, selectresolution=<optimized out>, Error=0x7f2821dbc9a0) at lib/stringbuf.c:4317

        pche = <optimized out>

        pos = <optimized out>

        pLF = 0x0

        len = <optimized out>

        rlen = <optimized out>

        retlen = 0

        nSuccessLess = 0

        rfds = {fds_bits = {1, 139810178072704, 511, 7, 0, 8192, 139809775419499, 527, 8240, 128, 755914244609, 532575944816, 2, 511101108331, 16, 0}}

        pch = <optimized out>

        fdflags = <optimized out>

        IsNonBlock = 0

        tv = {tv_sec = 139810343471552, tv_usec = 139810409532778}

#3  0x0000561e86c89cbb in CtdlClientGetLine ()

No symbol table info available.

#4  0x0000561e86c81944 in CtdlReadMessageBodyBuf ()

No symbol table info available.

#5  0x0000561e86cc1847 in smtp_data ()

No symbol table info available.

#6  0x0000561e86cc2227 in smtp_command_loop ()

No symbol table info available.

#7  0x0000561e86c8a8a7 in worker_thread ()

No symbol table info available.

#8  0x00007f2825fd1ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477

        ret = <optimized out>

        pd = <optimized out>

        unwind_buf = {cancel_jmp_buf = {{jmp_buf = {139810343479040, -5926168278360471484, 140734826778382, 140734826778383, 139810343476608, 139810111003408, 6021953643532699716, 6021962115441018948}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}

        not_first_call = 0

#9  0x00007f2825d33acf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:71

No locals.

#10 0x0000000000000000 in ?? ()

No symbol table info available.

Thread 6 (Thread 0x7f280affd700 (LWP 105)):

#0  __libc_read (nbytes=8191, buf=0x7f280018baf0, fd=56) at ../sysdeps/unix/sysv/linux/read.c:26

        resultvar = 18446744073709551104

        sc_cancel_oldtype = 0

        __arg3 = <optimized out>

        _a2 = <optimized out>

        sc_ret = <optimized out>

        __value = <optimized out>

        __arg1 = <optimized out>

        _a3 = <optimized out>

        resultvar = <optimized out>

        resultvar = <optimized out>

        __arg2 = <optimized out>

        _a1 = <optimized out>

#1  __libc_read (fd=56, buf=0x7f280018baf0, nbytes=8191) at ../sysdeps/unix/sysv/linux/read.c:24

No locals.

#2  0x00007f2825fffed6 in StrBufTCP_read_buffered_line_fast (Line=0x7f2800053fc0, IOBuf=0x7f281c090d00, Pos=0x7f281c0f7440, fd=0x7f281c0f7488, timeout=5, selectresolution=<optimized out>, Error=0x7f280affb9a0) at lib/stringbuf.c:4317

        pche = <optimized out>

        pos = <optimized out>

        pLF = 0x0

        len = <optimized out>

        rlen = <optimized out>

        retlen = 20

        nSuccessLess = 0

        rfds = {fds_bits = {0, 262144, 125, 16399, 262192, 4096, 17798344491009, 139810409524331, 64, 545460847195, 512, 8, 131072, 4096, 262144, 978326477955633920}}

        pch = <optimized out>

        fdflags = <optimized out>

        IsNonBlock = 0

        tv = {tv_sec = 16383, tv_usec = 7}

#3  0x0000561e86c89cbb in CtdlClientGetLine ()

No symbol table info available.

#4  0x0000561e86c81944 in CtdlReadMessageBodyBuf ()

No symbol table info available.

#5  0x0000561e86cc1847 in smtp_data ()

No symbol table info available.

#6  0x0000561e86cc2227 in smtp_command_loop ()

No symbol table info available.

#7  0x0000561e86c8a8a7 in worker_thread ()

No symbol table info available.

#8  0x00007f2825fd1ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477

        ret = <optimized out>

        pd = <optimized out>

        unwind_buf = {cancel_jmp_buf = {{jmp_buf = {139809959958272, -5926168278360471484, 140734826778382, 140734826778383, 139809959955840, 139810044056768, 6021893960130283588, 6021962115441018948}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}

        not_first_call = 0

#9  0x00007f2825d33acf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:71

No locals.

#10 0x0000000000000000 in ?? ()

No symbol table info available.

Thread 5 (Thread 0x7f2822f2d980 (LWP 7)):

#0  0x00007f2825cfa241 in __GI___clock_nanosleep (clock_id=0, flags=0, req=0x7fff615b8fd0, rem=0x0) at ../sysdeps/unix/sysv/linux/clock_nanosleep.c:48

        sc_cancel_oldtype = <optimized out>

        sc_ret = <optimized out>

        r = <optimized out>

#1  0x00007f2825cffa23 in __GI___nanosleep (requested_time=0x0, remaining=0x0) at nanosleep.c:27

        ret = <optimized out>

#2  0x0000000000000000 in ?? ()

No symbol table info available.

Thread 4 (Thread 0x7f280a7fc700 (LWP 113)):

#0  __libc_read (nbytes=5, buf=0x7f27f403a183, fd=47) at ../sysdeps/unix/sysv/linux/read.c:26

        resultvar = 18446744073709551104

        sc_cancel_oldtype = 0

        __arg3 = <optimized out>

        _a2 = <optimized out>

        sc_ret = <optimized out>

        __value = <optimized out>

        __arg1 = <optimized out>

        _a3 = <optimized out>

        resultvar = <optimized out>

        resultvar = <optimized out>

        __arg2 = <optimized out>

        _a1 = <optimized out>

#1  __libc_read (fd=47, buf=0x7f27f403a183, nbytes=5) at ../sysdeps/unix/sysv/linux/read.c:24

No locals.

#2  0x00007f28260f35e5 in ?? () from /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1

No symbol table info available.

#3  0x00007f28260ee7fa in ?? () from /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1

No symbol table info available.

#4  0x00007f28260ed6a4 in ?? () from /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1

No symbol table info available.

#5  0x00007f28260edc73 in BIO_read () from /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1

No symbol table info available.

#6  0x00007f2826346771 in ?? () from /usr/lib/x86_64-linux-gnu/libssl.so.1.1

No symbol table info available.

#7  0x00007f282634a982 in ?? () from /usr/lib/x86_64-linux-gnu/libssl.so.1.1

No symbol table info available.

#8  0x00007f28263482c0 in ?? () from /usr/lib/x86_64-linux-gnu/libssl.so.1.1

No symbol table info available.

#9  0x00007f282637b499 in ?? () from /usr/lib/x86_64-linux-gnu/libssl.so.1.1

No symbol table info available.

#10 0x00007f2826370f75 in ?? () from /usr/lib/x86_64-linux-gnu/libssl.so.1.1

No symbol table info available.

#11 0x0000561e86c9667f in CtdlStartTLS ()

No symbol table info available.

#12 0x0000561e86c8806f in CtdlModuleStartCryptoMsgs ()

No symbol table info available.

#13 0x0000561e86caf4d1 in imaps_greeting ()

No symbol table info available.

#14 0x0000561e86c8a88a in worker_thread ()

No symbol table info available.

#15 0x00007f2825fd1ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477

        ret = <optimized out>

        pd = <optimized out>

        unwind_buf = {cancel_jmp_buf = {{jmp_buf = {139809951565568, -5926168278360471484, 140734826778382, 140734826778383, 139809951563136, 139810044037136, 6021895056957556804, 6021962115441018948}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}

        not_first_call = 0

#16 0x00007f2825d33acf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:71

No locals.

#17 0x0000000000000000 in ?? ()

No symbol table info available.

Thread 3 (Thread 0x7f2809ffb700 (LWP 116)):

#0  __libc_read (nbytes=5, buf=0x7f27ec0d8873, fd=60) at ../sysdeps/unix/sysv/linux/read.c:26

        resultvar = 18446744073709551104

        sc_cancel_oldtype = 0

        __arg3 = <optimized out>

        _a2 = <optimized out>

        sc_ret = <optimized out>

        __value = <optimized out>

        __arg1 = <optimized out>

        _a3 = <optimized out>

        resultvar = <optimized out>

        resultvar = <optimized out>

        __arg2 = <optimized out>

        _a1 = <optimized out>

#1  __libc_read (fd=60, buf=0x7f27ec0d8873, nbytes=5) at ../sysdeps/unix/sysv/linux/read.c:24

No locals.

#2  0x00007f28260f35e5 in ?? () from /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1

No symbol table info available.

#3  0x00007f28260ee7fa in ?? () from /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1

No symbol table info available.

#4  0x00007f28260ed6a4 in ?? () from /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1

No symbol table info available.

#5  0x00007f28260edc73 in BIO_read () from /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1

No symbol table info available.

#6  0x00007f2826346771 in ?? () from /usr/lib/x86_64-linux-gnu/libssl.so.1.1

No symbol table info available.

#7  0x00007f282634a982 in ?? () from /usr/lib/x86_64-linux-gnu/libssl.so.1.1

No symbol table info available.

#8  0x00007f28263482c0 in ?? () from /usr/lib/x86_64-linux-gnu/libssl.so.1.1

No symbol table info available.

#9  0x00007f282637b499 in ?? () from /usr/lib/x86_64-linux-gnu/libssl.so.1.1

No symbol table info available.

#10 0x00007f2826370f75 in ?? () from /usr/lib/x86_64-linux-gnu/libssl.so.1.1

No symbol table info available.

#11 0x0000561e86c9667f in CtdlStartTLS ()

No symbol table info available.

#12 0x0000561e86c8806f in CtdlModuleStartCryptoMsgs ()

No symbol table info available.

#13 0x0000561e86cb9de7 in pop3s_greeting ()

No symbol table info available.

#14 0x0000561e86c8a88a in worker_thread ()

No symbol table info available.

#15 0x00007f2825fd1ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477

        ret = <optimized out>

        pd = <optimized out>

        unwind_buf = {cancel_jmp_buf = {{jmp_buf = {139809943172864, -5926168278360471484, 140734826778382, 140734826778383, 139809943170432, 139810111553776, 6021900553978824772, 6021962115441018948}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}

        not_first_call = 0

#16 0x00007f2825d33acf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:71

No locals.

#17 0x0000000000000000 in ?? ()

No symbol table info available.

Thread 2 (Thread 0x7f28215bd700 (LWP 18)):

#0  0x0000561e86ccdd8a in xmpp_queue_event ()

No symbol table info available.

#1  0x0000561e86ccc711 in xmpp_logout_hook ()

No symbol table info available.

#2  0x0000561e86c87e13 in PerformSessionHooks ()

No symbol table info available.

#3  0x0000561e86c8bf2e in CtdlUserLogout ()

No symbol table info available.

#4  0x0000561e86c6fe29 in RemoveContext ()

No symbol table info available.

#5  0x0000561e86c70943 in dead_session_purge ()

No symbol table info available.

#6  0x0000561e86c8a94d in worker_thread ()

No symbol table info available.

#7  0x00007f2825fd1ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477

        ret = <optimized out>

        pd = <optimized out>

        unwind_buf = {cancel_jmp_buf = {{jmp_buf = {139810335086336, -5926168278360471484, 140734826778382, 140734826778383, 139810335083904, 8396800, 6021954742507456580, 6021962115441018948}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}

        not_first_call = 0

#8  0x00007f2825d33acf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:71

No locals.

#9  0x0000000000000000 in ?? ()

No symbol table info available.

Thread 1 (Thread 0x7f280bfff700 (LWP 69)):

#0  0x0000561e86ca5f3f in imap_fetch_body ()

No symbol table info available.

#1  0x0000561e86ca6cbd in imap_do_fetch_msg ()

No symbol table info available.

#2  0x0000561e86ca6fda in imap_do_fetch ()

No symbol table info available.

#3  0x0000561e86ca7a77 in imap_fetch ()

No symbol table info available.

#4  0x0000561e86cb1c0b in imap_command_loop ()

No symbol table info available.

#5  0x0000561e86c8a8a7 in worker_thread ()

No symbol table info available.

#6  0x00007f2825fd1ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477

        ret = <optimized out>

        pd = <optimized out>

        unwind_buf = {cancel_jmp_buf = {{jmp_buf = {139809976743680, -5926168278360471484, 140734826778382, 140734826778383, 139809976741248, 8396800, 6021896158079797316, 6021962115441018948}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}

        not_first_call = 0

#7  0x00007f2825d33acf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:71

No locals.

#8  0x0000000000000000 in ?? ()

No symbol table info available.

(gdb) 

Hello Citadel Team,

I'm reporting a reproducible segmentation fault (SIGSEGV) observed in production, which appears to be caused by a concurrency / thread-safety issue in Citadel under normal usage conditions. I have collected multiple core dumps showing consistent call patterns and triggers.

Deployment: Docker

OS: Linux x86_64 (glibc-based)

Protocols in use:

* IMAPS

* SMTP (inbound + outbound)

* SMTP queue delivery

Sieve: Enabled (email forwarding rules)

No custom patches. No abnormal traffic patterns.

Observed Behaviour

Citadel crashes with SIGSEGV during normal operation. The crashes began after ~26 weeks of stable, uninterrupted operation, without any infrastructure or configuration changes. The only relevant behavioural change before the first crash was the introduction of new Sieve forwarding rules, which increased outbound SMTP activity.

From Core Dumps

The crashes consistently occur when the following operations overlap in time:

Thread A – IMAP FETCH (user reading mail)

imap_fetch_body()

imap_do_fetch_msg()

imap_do_fetch()

imap_command_loop()

Thread B – SMTP DATA (receiving mail)

smtp_data()

smtp_command_loop()

CtdlReadMessageBodyBuf()

StrBufTCP_read_buffered_line_fast()

Thread C – SMTP Forwarding / Queue Delivery

smtp_attempt_delivery()

smtp_do_queue()

smtp_do_queue_full()

curl_easy_perform()

curl_multi_poll()

Additional Concurrent Activity

* TLS handshakes (CtdlStartTLS, imaps_greeting, pop3s_greeting)

* Session cleanup and hooks (PerformSessionHooks, do_housekeeping)

* In some crashes, XMPP hooks are also active

Analysis / Suspected Root Cause

Based on repeated core dump analysis:

• These execution paths share internal buffers/message structures

• Some of these paths appear not to be fully thread-safe

• Increased outbound SMTP concurrency (introduced by Sieve forwarding) significantly raises the likelihood of these paths overlapping

• This results in memory corruption, eventually causing a SIGSEGV (often observed shortly after read(), select(), or buffer handling)

Important notes:

• The Sieve rules themselves are valid and correctly defined

• The issue is not caused by user error or misconfiguration

• Forwarding acts as a trigger, not the root defect

Reproduction Pattern (High-Level)

While not 100% deterministic, the crash frequency increases significantly when:

1. Sieve forwarding is enabled for active mailboxes

2. Inbound SMTP traffic is present

3. Users fetch messages (IMAP FETCH) concurrently

4. SMTP queue delivery runs in parallel (especially to external domains)

Reducing worker thread concurrency significantly reduces or eliminates crashes, which further suggests a concurrency-related issue.

Expected Behaviour

Citadel should be able to safely handle concurrent:

• IMAP FETCH

• SMTP DATA

• SMTP forwarding (Sieve)

• SMTP queue delivery

without memory corruption or segmentation faults.

Questions for the Development Team

1. Is this a known concurrency issue?

2. Has this behaviour been addressed in newer Citadel versions?

3. Are there recommended patches, configuration flags, or build options to mitigate this safely?

4. Would additional debugging data (full core dumps, symbols, logs) be helpful?

Thank you for your time and for maintaining Citadel.

root@tpc-co-cit02:/# gdb /usr/local/citadel/citserver /citadel-data/server1-backup/core.7 

GNU gdb (Debian 10.1-1.7) 10.1.90.20210103-git

Copyright (C) 2021 Free Software Foundation, Inc.

License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software: you are free to change and redistribute it.

There is NO WARRANTY, to the extent permitted by law.

Type "show copying" and "show warranty" for details.

This GDB was configured as "x86_64-linux-gnu".

Type "show configuration" for configuration details.

For bug reporting instructions, please see:

<https://www.gnu.org/software/gdb/bugs/>.

Find the GDB manual and other documentation resources online at:

    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".

Type "apropos word" to search for commands related to "word"...

Reading symbols from /usr/local/citadel/citserver...

(No debugging symbols found in /usr/local/citadel/citserver)

[New LWP 69]

[New LWP 18]

[New LWP 116]

[New LWP 113]

[New LWP 7]

[New LWP 105]

[New LWP 15]

[New LWP 92]

[New LWP 120]

[New LWP 10]

[New LWP 67]

[New LWP 597]

[New LWP 11]

[Thread debugging using libthread_db enabled]

Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Core was generated by `citserver -x9 -h /citadel-data'.

Program terminated with signal SIGSEGV, Segmentation fault.

#0  0x0000561e86ca5f3f in imap_fetch_body ()

[Current thread is 1 (Thread 0x7f280bfff700 (LWP 69))]

(gdb) set pagination off

(gdb) thread apply all bt full

Thread 13 (Thread 0x7f28225c7700 (LWP 11)):

#0  0x00007f2825d27a0f in __GI___poll (fds=0x7f28225bf870, nfds=2, timeout=1000) at ../sysdeps/unix/sysv/linux/poll.c:29

        __arg2 = <optimized out>

        _a3 = 1000

        _a1 = 139810351872112

        resultvar = <optimized out>

        __arg3 = <optimized out>

        __arg1 = <optimized out>

        _a2 = 2

        resultvar = <optimized out>

        sc_cancel_oldtype = <optimized out>

        sc_ret = <optimized out>

#1  0x00007f2825e75bca in ?? () from /usr/lib/x86_64-linux-gnu/libcurl.so.4

No symbol table info available.

#2  0x00007f2825e6abcc in ?? () from /usr/lib/x86_64-linux-gnu/libcurl.so.4

No symbol table info available.

#3  0x00007f2825e6ad56 in curl_multi_poll () from /usr/lib/x86_64-linux-gnu/libcurl.so.4

No symbol table info available.

#4  0x00007f2825e439cf in curl_easy_perform () from /usr/lib/x86_64-linux-gnu/libcurl.so.4

No symbol table info available.

#5  0x0000561e86cc32c5 in smtp_attempt_delivery ()

No symbol table info available.

#6  0x0000561e86cc38f2 in smtp_process_one_msg ()

No symbol table info available.

#7  0x0000561e86cc3f33 in smtp_do_queue ()

No symbol table info available.

#8  0x0000561e86cc3fbf in smtp_do_queue_full ()

No symbol table info available.

#9  0x0000561e86c87e13 in PerformSessionHooks ()

No symbol table info available.

#10 0x0000561e86c73dd5 in do_housekeeping ()

No symbol table info available.

#11 0x0000561e86c8a952 in worker_thread ()

No symbol table info available.

#12 0x00007f2825fd1ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477

        ret = <optimized out>

        pd = <optimized out>

        unwind_buf = {cancel_jmp_buf = {{jmp_buf = {139810351904512, -5926168278360471484, 140734826778382, 140734826778383, 139810351902080, 8396800, 6021948088529373252, 6021962115441018948}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}

        not_first_call = 0

#13 0x00007f2825d33acf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:71

No locals.

#14 0x0000000000000000 in ?? ()

No symbol table info available.

Thread 12 (Thread 0x7f2808ff9700 (LWP 597)):

#0  0x00007f2825d29ec3 in __GI___select (nfds=59, readfds=0x7f2808ff8bf0, writefds=0x0, exceptfds=0x0, timeout=0x7f2808ff8be0) at ../sysdeps/unix/sysv/linux/select.c:41

        __arg3 = 0

        _a5 = 139809926384608

        _a2 = 139809926384624

        __arg4 = 0

        __arg1 = 59

        _a3 = 0

        resultvar = <optimized out>

        __arg5 = 139809926384608

        __arg2 = 139809926384624

        _a4 = 0

        _a1 = 59

        resultvar = <optimized out>

        sc_cancel_oldtype = -514

        sc_ret = <optimized out>

#1  0x0000561e86c8a447 in worker_thread ()

No symbol table info available.

#2  0x00007f2825fd1ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477

        ret = <optimized out>

        pd = <optimized out>

        unwind_buf = {cancel_jmp_buf = {{jmp_buf = {139809926387456, -5926168278360471484, 140734826778382, 140734826778383, 139809926385024, 139809977318912, 6021898356029311044, 6021962115441018948}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}

        not_first_call = 0

#3  0x00007f2825d33acf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:71

No locals.

#4  0x0000000000000000 in ?? ()

No symbol table info available.

Thread 11 (Thread 0x7f2820dbc700 (LWP 67)):

#0  __libc_read (nbytes=8191, buf=0x7f2810130b10, fd=33) at ../sysdeps/unix/sysv/linux/read.c:26

        resultvar = 18446744073709551104

        sc_cancel_oldtype = 0

        __arg3 = <optimized out>

        _a2 = <optimized out>

        sc_ret = <optimized out>

        __value = <optimized out>

        __arg1 = <optimized out>

        _a3 = <optimized out>

        resultvar = <optimized out>

        resultvar = <optimized out>

        __arg2 = <optimized out>

        _a1 = <optimized out>

#1  __libc_read (fd=33, buf=0x7f2810130b10, nbytes=8191) at ../sysdeps/unix/sysv/linux/read.c:24

No locals.

#2  0x00007f2825fffed6 in StrBufTCP_read_buffered_line_fast (Line=0x7f28100fe740, IOBuf=0x7f28000dfb30, Pos=0x7f28000a36e0, fd=0x7f28000a3728, timeout=5, selectresolution=<optimized out>, Error=0x7f2820dba9a0) at lib/stringbuf.c:4317

        pche = <optimized out>

        pos = <optimized out>

        pLF = 0x0

        len = <optimized out>

        rlen = <optimized out>

        retlen = 19

        nSuccessLess = 0

        rfds = {fds_bits = {0, 524288, 126, 32783, 524336, 8192, 35390530551809, 541165879534, 128, 579820586075, 1024, 16, 131072, 4096, 524288, 978326477955633920}}

        pch = <optimized out>

        fdflags = <optimized out>

        IsNonBlock = 0

        tv = {tv_sec = 32767, tv_usec = 7}

#3  0x0000561e86c89cbb in CtdlClientGetLine ()

No symbol table info available.

#4  0x0000561e86c81944 in CtdlReadMessageBodyBuf ()

No symbol table info available.

#5  0x0000561e86cc1847 in smtp_data ()

No symbol table info available.

#6  0x0000561e86cc2227 in smtp_command_loop ()

No symbol table info available.

#7  0x0000561e86c8a8a7 in worker_thread ()

No symbol table info available.

#8  0x00007f2825fd1ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477

        ret = <optimized out>

        pd = <optimized out>

        unwind_buf = {cancel_jmp_buf = {{jmp_buf = {139810326693632, -5926168278360471484, 140734826778382, 140734826778383, 139810326691200, 8396800, 6021951441288218692, 6021962115441018948}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}

        not_first_call = 0

#9  0x00007f2825d33acf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:71

No locals.

#10 0x0000000000000000 in ?? ()

No symbol table info available.

Thread 10 (Thread 0x7f2822dc8700 (LWP 10)):

#0  0x00007f2825d29ec3 in __GI___select (nfds=59, readfds=0x7f2822dc7bf0, writefds=0x0, exceptfds=0x0, timeout=0x7f2822dc7be0) at ../sysdeps/unix/sysv/linux/select.c:41

        __arg3 = 0

        _a5 = 139810360294368

        _a2 = 139810360294384

        __arg4 = 0

        __arg1 = 59

        _a3 = 0

        resultvar = <optimized out>

        __arg5 = 139810360294368

        __arg2 = 139810360294384

        _a4 = 0

        _a1 = 59

        resultvar = <optimized out>

        sc_cancel_oldtype = -514

        sc_ret = <optimized out>

#1  0x0000561e86c8a447 in worker_thread ()

No symbol table info available.

#2  0x00007f2825fd1ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477

        ret = <optimized out>

        pd = <optimized out>

        unwind_buf = {cancel_jmp_buf = {{jmp_buf = {139810360297216, -5926168278360471484, 140734826778382, 140734826778383, 139810360294784, 8396800, 6021946989554616388, 6021962115441018948}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}

        not_first_call = 0

#3  0x00007f2825d33acf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:71

No locals.

#4  0x0000000000000000 in ?? ()

No symbol table info available.

Thread 9 (Thread 0x7f28097fa700 (LWP 120)):

#0  0x00007f2825d29ec3 in __GI___select (nfds=59, readfds=0x7f28097f9bf0, writefds=0x0, exceptfds=0x0, timeout=0x7f28097f9be0) at ../sysdeps/unix/sysv/linux/select.c:41

        __arg3 = 0

        _a5 = 139809934777312

        _a2 = 139809934777328

        __arg4 = 0

        __arg1 = 59

        _a3 = 0

        resultvar = <optimized out>

        __arg5 = 139809934777312

        __arg2 = 139809934777328

        _a4 = 0

        _a1 = 59

        resultvar = <optimized out>

        sc_cancel_oldtype = -514

        sc_ret = <optimized out>

#1  0x0000561e86c8a447 in worker_thread ()

No symbol table info available.

#2  0x00007f2825fd1ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477

        ret = <optimized out>

        pd = <optimized out>

        unwind_buf = {cancel_jmp_buf = {{jmp_buf = {139809934780160, -5926168278360471484, 140734826778382, 140734826778383, 139809934777728, 139810111629120, 6021901655101065284, 6021962115441018948}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}

        not_first_call = 0

#3  0x00007f2825d33acf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:71

No locals.

#4  0x0000000000000000 in ?? ()

No symbol table info available.

Thread 8 (Thread 0x7f280b7fe700 (LWP 92)):

#0  0x00007f2825d29ec3 in __GI___select (nfds=59, readfds=0x7f280b7fdbf0, writefds=0x0, exceptfds=0x0, timeout=0x7f280b7fdbe0) at ../sysdeps/unix/sysv/linux/select.c:41

        __arg3 = 0

        _a5 = 139809968348128

        _a2 = 139809968348144

        __arg4 = 0

        __arg1 = 59

        _a3 = 0

        resultvar = <optimized out>

        __arg5 = 139809968348128

        __arg2 = 139809968348144

        _a4 = 0

        _a1 = 59

        resultvar = <optimized out>

        sc_cancel_oldtype = -514

        sc_ret = <optimized out>

#1  0x0000561e86c8a447 in worker_thread ()

No symbol table info available.

#2  0x00007f2825fd1ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477

        ret = <optimized out>

        pd = <optimized out>

        unwind_buf = {cancel_jmp_buf = {{jmp_buf = {139809968350976, -5926168278360471484, 140734826778382, 140734826778383, 139809968348544, 139810110988112, 6021897259202037828, 6021962115441018948}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}

        not_first_call = 0

#3  0x00007f2825d33acf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:71

No locals.

#4  0x0000000000000000 in ?? ()

No symbol table info available.

Thread 7 (Thread 0x7f2821dbe700 (LWP 15)):

#0  __libc_read (nbytes=63, buf=0x7f27e4122af0, fd=57) at ../sysdeps/unix/sysv/linux/read.c:26

        resultvar = 18446744073709551104

        sc_cancel_oldtype = 0

        __arg3 = <optimized out>

        _a2 = <optimized out>

        sc_ret = <optimized out>

        __value = <optimized out>

        __arg1 = <optimized out>

        _a3 = <optimized out>

        resultvar = <optimized out>

        resultvar = <optimized out>

        __arg2 = <optimized out>

        _a1 = <optimized out>

#1  __libc_read (fd=57, buf=0x7f27e4122af0, nbytes=63) at ../sysdeps/unix/sysv/linux/read.c:24

No locals.

#2  0x00007f2825fffed6 in StrBufTCP_read_buffered_line_fast (Line=0x7f2818078d50, IOBuf=0x7f27ec0fc8b0, Pos=0x7f27e4079ec0, fd=0x7f27e4079f08, timeout=5, selectresolution=<optimized out>, Error=0x7f2821dbc9a0) at lib/stringbuf.c:4317

        pche = <optimized out>

        pos = <optimized out>

        pLF = 0x0

        len = <optimized out>

        rlen = <optimized out>

        retlen = 0

        nSuccessLess = 0

        rfds = {fds_bits = {1, 139810178072704, 511, 7, 0, 8192, 139809775419499, 527, 8240, 128, 755914244609, 532575944816, 2, 511101108331, 16, 0}}

        pch = <optimized out>

        fdflags = <optimized out>

        IsNonBlock = 0

        tv = {tv_sec = 139810343471552, tv_usec = 139810409532778}

#3  0x0000561e86c89cbb in CtdlClientGetLine ()

No symbol table info available.

#4  0x0000561e86c81944 in CtdlReadMessageBodyBuf ()

No symbol table info available.

#5  0x0000561e86cc1847 in smtp_data ()

No symbol table info available.

#6  0x0000561e86cc2227 in smtp_command_loop ()

No symbol table info available.

#7  0x0000561e86c8a8a7 in worker_thread ()

No symbol table info available.

#8  0x00007f2825fd1ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477

        ret = <optimized out>

        pd = <optimized out>

        unwind_buf = {cancel_jmp_buf = {{jmp_buf = {139810343479040, -5926168278360471484, 140734826778382, 140734826778383, 139810343476608, 139810111003408, 6021953643532699716, 6021962115441018948}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}

        not_first_call = 0

#9  0x00007f2825d33acf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:71

No locals.

#10 0x0000000000000000 in ?? ()

No symbol table info available.

Thread 6 (Thread 0x7f280affd700 (LWP 105)):

#0  __libc_read (nbytes=8191, buf=0x7f280018baf0, fd=56) at ../sysdeps/unix/sysv/linux/read.c:26

        resultvar = 18446744073709551104

        sc_cancel_oldtype = 0

        __arg3 = <optimized out>

        _a2 = <optimized out>

        sc_ret = <optimized out>

        __value = <optimized out>

        __arg1 = <optimized out>

        _a3 = <optimized out>

        resultvar = <optimized out>

        resultvar = <optimized out>

        __arg2 = <optimized out>

        _a1 = <optimized out>

#1  __libc_read (fd=56, buf=0x7f280018baf0, nbytes=8191) at ../sysdeps/unix/sysv/linux/read.c:24

No locals.

#2  0x00007f2825fffed6 in StrBufTCP_read_buffered_line_fast (Line=0x7f2800053fc0, IOBuf=0x7f281c090d00, Pos=0x7f281c0f7440, fd=0x7f281c0f7488, timeout=5, selectresolution=<optimized out>, Error=0x7f280affb9a0) at lib/stringbuf.c:4317

        pche = <optimized out>

        pos = <optimized out>

        pLF = 0x0

        len = <optimized out>

        rlen = <optimized out>

        retlen = 20

        nSuccessLess = 0

        rfds = {fds_bits = {0, 262144, 125, 16399, 262192, 4096, 17798344491009, 139810409524331, 64, 545460847195, 512, 8, 131072, 4096, 262144, 978326477955633920}}

        pch = <optimized out>

        fdflags = <optimized out>

        IsNonBlock = 0

        tv = {tv_sec = 16383, tv_usec = 7}

#3  0x0000561e86c89cbb in CtdlClientGetLine ()

No symbol table info available.

#4  0x0000561e86c81944 in CtdlReadMessageBodyBuf ()

No symbol table info available.

#5  0x0000561e86cc1847 in smtp_data ()

No symbol table info available.

#6  0x0000561e86cc2227 in smtp_command_loop ()

No symbol table info available.

#7  0x0000561e86c8a8a7 in worker_thread ()

No symbol table info available.

#8  0x00007f2825fd1ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477

        ret = <optimized out>

        pd = <optimized out>

        unwind_buf = {cancel_jmp_buf = {{jmp_buf = {139809959958272, -5926168278360471484, 140734826778382, 140734826778383, 139809959955840, 139810044056768, 6021893960130283588, 6021962115441018948}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}

        not_first_call = 0

#9  0x00007f2825d33acf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:71

No locals.

#10 0x0000000000000000 in ?? ()

No symbol table info available.

Thread 5 (Thread 0x7f2822f2d980 (LWP 7)):

#0  0x00007f2825cfa241 in __GI___clock_nanosleep (clock_id=0, flags=0, req=0x7fff615b8fd0, rem=0x0) at ../sysdeps/unix/sysv/linux/clock_nanosleep.c:48

        sc_cancel_oldtype = <optimized out>

        sc_ret = <optimized out>

        r = <optimized out>

#1  0x00007f2825cffa23 in __GI___nanosleep (requested_time=0x0, remaining=0x0) at nanosleep.c:27

        ret = <optimized out>

#2  0x0000000000000000 in ?? ()

No symbol table info available.

Thread 4 (Thread 0x7f280a7fc700 (LWP 113)):

#0  __libc_read (nbytes=5, buf=0x7f27f403a183, fd=47) at ../sysdeps/unix/sysv/linux/read.c:26

        resultvar = 18446744073709551104

        sc_cancel_oldtype = 0

        __arg3 = <optimized out>

        _a2 = <optimized out>

        sc_ret = <optimized out>

        __value = <optimized out>

        __arg1 = <optimized out>

        _a3 = <optimized out>

        resultvar = <optimized out>

        resultvar = <optimized out>

        __arg2 = <optimized out>

        _a1 = <optimized out>

#1  __libc_read (fd=47, buf=0x7f27f403a183, nbytes=5) at ../sysdeps/unix/sysv/linux/read.c:24

No locals.

#2  0x00007f28260f35e5 in ?? () from /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1

No symbol table info available.

#3  0x00007f28260ee7fa in ?? () from /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1

No symbol table info available.

#4  0x00007f28260ed6a4 in ?? () from /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1

No symbol table info available.

#5  0x00007f28260edc73 in BIO_read () from /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1

No symbol table info available.

#6  0x00007f2826346771 in ?? () from /usr/lib/x86_64-linux-gnu/libssl.so.1.1

No symbol table info available.

#7  0x00007f282634a982 in ?? () from /usr/lib/x86_64-linux-gnu/libssl.so.1.1

No symbol table info available.

#8  0x00007f28263482c0 in ?? () from /usr/lib/x86_64-linux-gnu/libssl.so.1.1

No symbol table info available.

#9  0x00007f282637b499 in ?? () from /usr/lib/x86_64-linux-gnu/libssl.so.1.1

No symbol table info available.

#10 0x00007f2826370f75 in ?? () from /usr/lib/x86_64-linux-gnu/libssl.so.1.1

No symbol table info available.

#11 0x0000561e86c9667f in CtdlStartTLS ()

No symbol table info available.

#12 0x0000561e86c8806f in CtdlModuleStartCryptoMsgs ()

No symbol table info available.

#13 0x0000561e86caf4d1 in imaps_greeting ()

No symbol table info available.

#14 0x0000561e86c8a88a in worker_thread ()

No symbol table info available.

#15 0x00007f2825fd1ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477

        ret = <optimized out>

        pd = <optimized out>

        unwind_buf = {cancel_jmp_buf = {{jmp_buf = {139809951565568, -5926168278360471484, 140734826778382, 140734826778383, 139809951563136, 139810044037136, 6021895056957556804, 6021962115441018948}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}

        not_first_call = 0

#16 0x00007f2825d33acf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:71

No locals.

#17 0x0000000000000000 in ?? ()

No symbol table info available.

Thread 3 (Thread 0x7f2809ffb700 (LWP 116)):

#0  __libc_read (nbytes=5, buf=0x7f27ec0d8873, fd=60) at ../sysdeps/unix/sysv/linux/read.c:26

        resultvar = 18446744073709551104

        sc_cancel_oldtype = 0

        __arg3 = <optimized out>

        _a2 = <optimized out>

        sc_ret = <optimized out>

        __value = <optimized out>

        __arg1 = <optimized out>

        _a3 = <optimized out>

        resultvar = <optimized out>

        resultvar = <optimized out>

        __arg2 = <optimized out>

        _a1 = <optimized out>

#1  __libc_read (fd=60, buf=0x7f27ec0d8873, nbytes=5) at ../sysdeps/unix/sysv/linux/read.c:24

No locals.

#2  0x00007f28260f35e5 in ?? () from /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1

No symbol table info available.

#3  0x00007f28260ee7fa in ?? () from /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1

No symbol table info available.

#4  0x00007f28260ed6a4 in ?? () from /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1

No symbol table info available.

#5  0x00007f28260edc73 in BIO_read () from /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1

No symbol table info available.

#6  0x00007f2826346771 in ?? () from /usr/lib/x86_64-linux-gnu/libssl.so.1.1

No symbol table info available.

#7  0x00007f282634a982 in ?? () from /usr/lib/x86_64-linux-gnu/libssl.so.1.1

No symbol table info available.

#8  0x00007f28263482c0 in ?? () from /usr/lib/x86_64-linux-gnu/libssl.so.1.1

No symbol table info available.

#9  0x00007f282637b499 in ?? () from /usr/lib/x86_64-linux-gnu/libssl.so.1.1

No symbol table info available.

#10 0x00007f2826370f75 in ?? () from /usr/lib/x86_64-linux-gnu/libssl.so.1.1

No symbol table info available.

#11 0x0000561e86c9667f in CtdlStartTLS ()

No symbol table info available.

#12 0x0000561e86c8806f in CtdlModuleStartCryptoMsgs ()

No symbol table info available.

#13 0x0000561e86cb9de7 in pop3s_greeting ()

No symbol table info available.

#14 0x0000561e86c8a88a in worker_thread ()

No symbol table info available.

#15 0x00007f2825fd1ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477

        ret = <optimized out>

        pd = <optimized out>

        unwind_buf = {cancel_jmp_buf = {{jmp_buf = {139809943172864, -5926168278360471484, 140734826778382, 140734826778383, 139809943170432, 139810111553776, 6021900553978824772, 6021962115441018948}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}

        not_first_call = 0

#16 0x00007f2825d33acf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:71

No locals.

#17 0x0000000000000000 in ?? ()

No symbol table info available.

Thread 2 (Thread 0x7f28215bd700 (LWP 18)):

#0  0x0000561e86ccdd8a in xmpp_queue_event ()

No symbol table info available.

#1  0x0000561e86ccc711 in xmpp_logout_hook ()

No symbol table info available.

#2  0x0000561e86c87e13 in PerformSessionHooks ()

No symbol table info available.

#3  0x0000561e86c8bf2e in CtdlUserLogout ()

No symbol table info available.

#4  0x0000561e86c6fe29 in RemoveContext ()

No symbol table info available.

#5  0x0000561e86c70943 in dead_session_purge ()

No symbol table info available.

#6  0x0000561e86c8a94d in worker_thread ()

No symbol table info available.

#7  0x00007f2825fd1ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477

        ret = <optimized out>

        pd = <optimized out>

        unwind_buf = {cancel_jmp_buf = {{jmp_buf = {139810335086336, -5926168278360471484, 140734826778382, 140734826778383, 139810335083904, 8396800, 6021954742507456580, 6021962115441018948}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}

        not_first_call = 0

#8  0x00007f2825d33acf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:71

No locals.

#9  0x0000000000000000 in ?? ()

No symbol table info available.

Thread 1 (Thread 0x7f280bfff700 (LWP 69)):

#0  0x0000561e86ca5f3f in imap_fetch_body ()

No symbol table info available.

#1  0x0000561e86ca6cbd in imap_do_fetch_msg ()

No symbol table info available.

#2  0x0000561e86ca6fda in imap_do_fetch ()

No symbol table info available.

#3  0x0000561e86ca7a77 in imap_fetch ()

No symbol table info available.

#4  0x0000561e86cb1c0b in imap_command_loop ()

No symbol table info available.

#5  0x0000561e86c8a8a7 in worker_thread ()

No symbol table info available.

#6  0x00007f2825fd1ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477

        ret = <optimized out>

        pd = <optimized out>

        unwind_buf = {cancel_jmp_buf = {{jmp_buf = {139809976743680, -5926168278360471484, 140734826778382, 140734826778383, 139809976741248, 8396800, 6021896158079797316, 6021962115441018948}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}

        not_first_call = 0

#7  0x00007f2825d33acf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:71

No locals.

#8  0x0000000000000000 in ?? ()

No symbol table info available.

(gdb) 

First of all I am very new to this, so my apologies in advance.

I've had a longtime project to setup an email server that I'm getting back to.  I was following an older video as guidance in which Citadel had an Administration tab right next to the Advanced tab.  I already have the domain and need to enter that information so that I can create the various email accounts using the Citadel Server.  Without the Advanced tab, I can't find where to enter the domain information.  With so much reference information I can't seem to find what I need, I have no doubt that it's there-somewhere.   Can someone point me in the right direction?

That's correct, actually.  Over the last couple of days we've had some pretty bad network flooding.  I think I've got most of it worked out so try again.

Sorry, IG not LG.. fat fingers. 

Also, i was able to download it a bit ago, yes slowly, but it did finally complete. Id offer to share it out on google or something, but if you are smart, you would not trust me anyway. 

SorSun Nov 23 2025 23:43:28 UTC from Nurb432 Subject: Re: Berkeley DB cannot be downloaded

I don't want to speak for LG as i'm not sure if hes hosting the files via the same network provider as the board, but there have been network issues here of late here on the board, and if my guess is right, it could/would effect that too.

Keep retrying..

I don't want to speak for LG as i'm not sure if hes hosting the files via the same network provider as the board, but there have been network issues here of late here on the board, and if my guess is right, it could/would effect that too.

Keep retrying..

(I hope this is the Citadel Support room)

Hello,

I'm trying to install Citadel on my Rpi3 using your easyinstall script. The script does not complete. During installation it needs a certain Berkeley database file. This download is extremely slow and/or the file cannot be downloaded. When I go to https://easyinstall.citadel.org/db-18.1.40.tar.gz myself using a browser the download also fails.

Any help is appreciated.

Regards Bart

A piece of the script output is:

 Downloading Berkeley DB...
--2025-11-23 14:52:31--  https://easyinstall.citadel.org/db-18.1.40.tar.gz
Resolving easyinstall.citadel.org (easyinstall.citadel.org)... 72.0.224.90
Connecting to easyinstall.citadel.org (easyinstall.citadel.org)|72.0.224.90|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 30745815 (29M) [application/octet-stream]
Saving to: 'db-18.1.40.tar.gz'

db-18.1.40.tar.gz    2%[                 ] 879.74K  --.-KB/s    eta 58m 51sc

Many thanks can now send emails to google accounts without rejection

Thanks again

easydmarc appears to be a scam site that wants to sell you a service, and deliberately shits on your domain to make you buy it.

Instead, try https://dkimvalidator.com

No signup.  It gives you an address to which you send an email.  You send that address an email, then go back to the site and it tells you if that message was properly DKIM signed.

I have deleted the domain and a new DKIM record was generated but  using easydmarc  to test it gives the following result:-

We couldn't find a DKIM record associated with your domain. You need to generate DKIM record to protect your domain against email phishing attacks.

Ok, so I just ran a quick test and confirmed: you can add a bogus domain (example.xxx or whatever) and then go right ahead and delete it, and it'll post the keys for all of your existing domains as well.

After installing Citadel no DKIM was generated.

Is there a way for me to install  a public and private DKIM key in Citadel sever

Again, there is no way to install a user-generated DKIM key into Citadel.  Citadel generates the private key for each domain and stores it in the database.  When it does so, the corresponding public key is posted to the "Aide" room.

If you are missing your key, you can delete and re-create your local domains on this screen:

[ Administration --> Domain Names and Internet Mail Configuration --> Local host aliases ]

When you do so, new DKIM keys will be generated and posted, and you can use those.

After installing Citadel no DKIM was generated.

Is there a way for me to install  a public and private DKIM key in Citadel sever

I made a dump and a load of the database and it start working but I do not have certain about if it is the reason.

Now a question. The contacts not being updated with new email addresses, is it meaning that the emails were not sent?

For information, the emails appeared in the "Sent Itens".

Wed Nov 19 2025 17:15:35 UTC from luisgo Subject: Possible problem with Citadel.

Dear All,

Until now when I sent an email with a new email address that email address was registed in the "Contacts" folder.

It is not happening anymore. I suppose that is happening since last Centos 9 update (with glibc (??) update, one of the Citadel dependencies was updated).

Notice that Thunderbird had also a recent update.

Is it happening with someone else?

Thank you,

Luís Gonçalves. 

 

Dear All,

Until now when I sent an email with a new email address that email address was registed in the "Contacts" folder.

It is not happening anymore. I suppose that is happening since last Centos 9 update (with glibc (??) update, one of the Citadel dependencies was updated).

Notice that Thunderbird had also a recent update.

Is it happening with someone else?

Thank you,

Luís Gonçalves. 

https://citadel.org/sslcertificates.html

Tue Nov 18 2025 14:48:49 UTC from luisgo Subject: Re: DKIM record

/usr/local/citadel/keys/

Tue Nov 18 2025 09:35:10 UTC from johno Subject: DKIM record

I am having a problem getting the DKIM record to be recognised. If i create new public and private keys where can i find the files in a citadel system to install these keys.

 

/usr/local/citadel/keys/

Tue Nov 18 2025 09:35:10 UTC from johno Subject: DKIM record

I am having a problem getting the DKIM record to be recognised. If i create new public and private keys where can i find the files in a citadel system to install these keys.

I am having a problem getting the DKIM record to be recognised. If i create new public and private keys where can i find the files in a citadel system to install these keys.

I forgot.

3GBytes of Citadel Email data and only 2 email users. 

Fri Nov 14 2025 15:29:14 UTC from luisgo Subject: Re: Concerning tha last two posts in Support Room.

I have 3GBytes of RAM (all). 20GBytes Free disk. It is a KVM Centos 9 container. Basically it only runs Apache and Citadel. The Web page is not heavy.

Wed Nov 12 2025 16:07:32 UTC from IGnatius T Foobar Subject: Re: Concerning tha last two posts in Support Room.

So ... all the weird issues you've been having were just constrained system resources? It's interesting, because Citadel isn't very resource hungry.
But this tells us perhaps that we would be well served by detecting that kind of situation and saying something about it.

We already refuse to accept new messages when there is less than 100 MB free on the disk. Perhaps we need to look at memory too.

 

I have 3GBytes of RAM (all). 20GBytes Free disk. It is a KVM Centos 9 container. Basically it only runs Apache and Citadel. The Web page is not heavy.

Wed Nov 12 2025 16:07:32 UTC from IGnatius T Foobar Subject: Re: Concerning tha last two posts in Support Room.

So ... all the weird issues you've been having were just constrained system resources? It's interesting, because Citadel isn't very resource hungry.
But this tells us perhaps that we would be well served by detecting that kind of situation and saying something about it.

We already refuse to accept new messages when there is less than 100 MB free on the disk. Perhaps we need to look at memory too.

Dear All,

Concerning this problem I improved the realibility of Citadel doing the following.

I noticed that the available memory (with "top") was not too much (some tens of Megabytes) and it had a lot of Buffer/Cache Memory. And the Swap has about 200 MBytes or more.

I suspected that when Citadel needed memory was not freed fast enough. Then I remembered that in Apache, I has configured disk cache with some time out to free it.

I disallowed the disk cache in Apache and the time out. I noticed that now I have more free memory (hundreds od Megabytes) and the swap is almost not used. Some times the free memory goes to more than a GByte showing that memory is freed.

Thank you,

Luís Gonçalves.   

Wed Oct 01 2025 06:46:58 UTC from luisgo Subject: Re: Concerning tha last two posts in Support Room.

Specify please what you want to solve the problem. Do you want to have access to my server? Stack trace? How I obtain it?

 

Sat Sep 20 2025 18:08:00 UTC from IGnatius T Foobar Subject: Re: Concerning tha last two posts in Support Room.

Sorry again.

This night happened again. More coredumps. I updated the citadel. It installed and compiled a version but it remained the same version number. Did that attended my problem?

If not a send the new coredumps.

https://luisgo.pro/down/coredumps3.zip

I hope that you solved or are solving this problem.

Let see that if or not happen again.

Unfortunately, your core dumps are not useful to anyone because they are specific to your citserver binary.  I suppose if you include your citserver binary it might be useful, otherwise a stack trace is better.

In your case, we're just seeing so many weird things on your system that don't happen anywhere else.  It's difficult to pin down why.  I would strongly suggest that you give some consideration to moving to the containerized version of the Citadel system.  It is lovingly built for you in a carefully controlled environment.   Perhaps switch to the container version, and if necessary, do a ctdldump/ctdlload on your existing data.

And of course take lots of backups before doing anything.

 

Dear All,

This is happening to me. 

I think that is happening since the last upgrade (some days ago) when I send a message it has the date one hour after I sent.

I only noticed now. I upgraded at 6 Nov, 17H39 Central Europe Time. I can verify in some emails in the "Sent Items" after that (6 Nov) are registered one hour after than when sent. 

Happens with all the emails clients.

Are this happening to someone else?

Thank you,

Luís Gonçalves.

SUMMARY

-------

Citadel Server (Version 1020, build 25289) crashes with SIGSEGV when processing 

emails containing malformed HTML with missing opening angle brackets. The server 

enters an unrecoverable crash loop on startup, requiring manual database 

intervention to restore service.

SEVERITY: CRITICAL

------------------

• Impact: Complete server unavailability (crash loop)

• Reproducibility: 100% reproducible

• Recovery: Requires manual database manipulation

• Root Cause: NULL pointer dereference in libcitadel.so.4

ENVIRONMENT

-----------

Citadel Version: 1020 (build 25289)

libcitadel: libcitadel.so.4 (unnumbered)

OS: Ubuntu 24 (Linux x86_64)

Crash Location: lib/html_to_ascii.c:161

PROBLEM DESCRIPTION

-------------------

When Citadel receives email containing HTML where the opening '<' character is 

missing from a tag, the html_to_ascii() function crashes with a NULL pointer 

dereference. This occurs during full-text indexing at server startup, creating 

a crash loop that prevents the server from running.

WE ARE RECEIVING THESE MALFORMED EMAILS REGULARLY, making this a recurring production issue.

TECHNICAL DETAILS

-----------------

Stack Trace:

    SIGSEGV received at address (nil)

    #0  __strncpy_sse2_unaligned ()

    #1  strncpy (__len=1024, __src=0x0, __dest=...)

    #2  html_to_ascii (...) at lib/html_to_ascii.c:161

        tag_start = 0x0  <-- NULL POINTER

        tag_end = 0x... ">Hello,</p>..."

    #3  fixed_output (...) at server/msgbase.c:1185

    #4  mime_decode (...) at lib/mime_parser.c:224

    ...

    #10 ft_index_message (msgnum=..., op=1) 

        at server/modules/fulltext/serv_fulltext.c:88

Root Cause:

In html_to_ascii() at line 161:

1. Function finds tag_end pointing to a '>' character

2. Attempts to find the matching '<' character for tag_start

3. When the '<' is missing, tag_start remains NULL

4. Calls strncpy(tag, tag_start, 1024) with NULL source pointer

5. SEGMENTATION FAULT (sigsegv)

Malformed HTML Example (triggers crash):

    p>Hello,</p>

    <p>I have information that is privileged...</p>

Should be:

    <p>Hello,</p>

    <p>I have information that is privileged...</p>

Note: The HTML is otherwise well-formed - only the opening '<' is missing.

STEPS TO REPRODUCE

------------------

1. Send email to Citadel with HTML body starting with text followed by '>' 

   (missing opening '<')

2. Restart Citadel server or wait for full-text indexing

3. Server crashes during message indexing

4. Server enters crash loop - crashes on every restart attempt

5. systemd reports: "citadel.service: Failed with result 'core-dump'"

EXPECTED BEHAVIOR

-----------------

Server should handle malformed HTML gracefully by either:

• Skipping malformed tags and continuing processing

• Logging warning and indexing message without HTML conversion

• Failing safely without crashing

ACTUAL BEHAVIOR

---------------

• Server crashes with SIGSEGV

• Enters unrecoverable crash loop

• Cannot start until problematic message is manually removed

• Service completely unavailable

IMPACT ASSESSMENT

-----------------

Business Impact: SEVERE

• Complete service outage - no email access during crash loop

• Manual intervention required - cannot auto-recover

• Data loss risk - requires database manipulation to fix

• Recurring issue - we have recently started to receive these malformed emails regularly

WORKAROUND

----------

The only current workaround is to manually delete the full-text index files:

    systemctl stop citadel

    rm -f /usr/local/citadel/data/cdb.0c    # Full-text index database

    rm -f /usr/local/citadel/data/cdb.0d    # Index control file

    systemctl start citadel

This forces Citadel to rebuild the full-text index from scratch. During the 

rebuild process, the indexer appears to handle the malformed message differently 

(possibly with better error handling) and skips it, allowing the server to start.

However, this workaround:

• Requires root access

• Causes service downtime

• Forces complete index rebuild (time-consuming on large databases)

• Temporarily loses full-text search capability during rebuild

• Only works until the next malformed email arrives

• Is NOT a sustainable solution when receiving these emails regularly

ATTEMPTED SOLUTIONS

-------------------

  Berkeley DB recovery (db_recover -c) - Did not resolve crash

  Citadel database cleanup script (database_cleanup.sh) - Performed full 

  Berkeley DB dump/load of ALL database files (cdb.00 through cdb.0d), removed 

  old databases and transaction logs, successfully reloaded everything - CRASH 

  PERSISTED UNCHANGED

  Database dump/reload manually (db_dump | db_load) - Preserved the malformed 

  message, crash persisted

  Full-text index deletion (cdb.0c, cdb.0d) - Allows server to start by 

  forcing index rebuild

Note: The fact that a complete database cleanup (dump/load of all 14 database 

files) did not resolve the issue demonstrates that:

1. The database files themselves are not corrupted

2. The malformed HTML content is preserved exactly through dump/load

3. Standard database recovery procedures are ineffective for this bug

4. The issue is with the content being valid Berkeley DB data but containing 

   HTML that crashes the parser

PROPOSED FIX

------------

The html_to_ascii() function should validate tag_start before use:

    // Around line 161 in lib/html_to_ascii.c

    if (tag_start == NULL || tag_end == NULL) {

        // Handle malformed HTML gracefully

        // Log warning, skip tag, or use safe default

        continue;  // or appropriate error handling

    }

    strncpy(tag, tag_start, tag_len);

Additionally, consider:

1. Input validation before HTML parsing

2. Defensive coding for all pointer operations in parser

3. Graceful degradation when HTML is malformed

REQUEST

-------

This is a CRITICAL PRODUCTION ISSUE causing recurring outages. We urgently 

request:

1. A patch for the NULL pointer check in html_to_ascii()

2. Guidance on additional defensive measures

3. Consider making full-text indexing more resilient to malformed input

Thank you for your attention to this severe bug.

ericsondatasystems

 don’t see those messages in that queue. Previously, I had to remove those messages directly from the DB because Citadel was crashing with a segmentation fault. Is it possible I didn’t remove them from all the required places?

In the Citadel console I also see:

paź 15 14:55:40 xxx citserver[328259]: citserver[328259]: msgbase: message #11040 was not found

paź 15 14:55:40 xxx citserver[328259]: msgbase: message #11040 was not found

Could these be ghost/orphaned messages?

śro paź 15 2025 00:36:59 UTC od IGnatius T Foobar Temat: Re: smtp queue

2. After my problem with server hang (few weekes ago I send here
information about that) I notice that in "Aida" directory there are
planty of meassages to today. Server is generating it reapetly after few

minutes:

Sounds like someone dumped a big pile of boomerang spam at your site, maybe?

The queue is in a hidden room called __CitadelSMTPspoolout__

You can delete from there.

navigate to https://easyinstall.citadel.org/

you'll find the site is down

i am trying to install citadel using sudo curl https://easyinstall.citadel.org/install | bash

Instructions for which i found on https://www.citadel.org/easyinstall.html

anyone know why site is down

also, is a copy of the easyinstall script available elsewhere?

thanks - ericsondatasystems

Hi,

two problems to solve - could you please give me a tip:

1. After sending email, massage goes to SMTP queue. I should expect that it will be send stright after. In my server email will be send after 8-10minutes. There is big delay. I notice also that:

2. After my problem with server hang (few weekes ago I send here information about that) I notice that in "Aida" directory there are planty of meassages to today. Server is generating it reapetly after few minutes:

2099538367@Uncensored

Specify please what you want to solve the problem. Do you want to have access to my server? Stack trace? How I obtain it?

Stack trace would be far more helpful than what you are currently trying to do.   Since you seem to have the ability to produce core dumps, you are halfway there already.

After a core dump, do this:

gdb /usr/local/citadel/citserver core.xxxxxxxxx   (use the name of your core file)

The debugger will open, and show you where it crashed.   Now type:

thread apply all bt

And post the output.  it should show lots of filenames and line numbers.

Specify please what you want to solve the problem. Do you want to have access to my server? Stack trace? How I obtain it?

Sat Sep 20 2025 18:08:00 UTC from IGnatius T Foobar Subject: Re: Concerning tha last two posts in Support Room.

Sorry again.

This night happened again. More coredumps. I updated the citadel. It installed and compiled a version but it remained the same version number. Did that attended my problem?

If not a send the new coredumps.

https://luisgo.pro/down/coredumps3.zip

I hope that you solved or are solving this problem.

Let see that if or not happen again.

Unfortunately, your core dumps are not useful to anyone because they are specific to your citserver binary.  I suppose if you include your citserver binary it might be useful, otherwise a stack trace is better.

In your case, we're just seeing so many weird things on your system that don't happen anywhere else.  It's difficult to pin down why.  I would strongly suggest that you give some consideration to moving to the containerized version of the Citadel system.  It is lovingly built for you in a carefully controlled environment.   Perhaps switch to the container version, and if necessary, do a ctdldump/ctdlload on your existing data.

And of course take lots of backups before doing anything.

https://luisgo.pro/down/coredumps6.zip

Including citserver 

Centos 9, last version.

Dear All,

I submit another coredump and this time I include the Citadel server binary.

https://luisgo.pro/down/coredumps5.zip

Thank you,

Luís Gonçalves.

Subject pretty much says it all: Are modems still supported in Citadel?

SP

I send you priv messages.

J.K.

Do you still have the unedited dump?  If you could upload the removed records it would be an invaluable aid in figuring out what went wrong.

Ok, I was able to turn it on. dumped all DB to file. Removed somehow all records with "11040" and load it back to server. Looks like it do the trick.

J.K.

wto wrz 23 2025 06:41:37 UTC od kwadrat Temat: Segmentation fault (core dumped)

I've got problem with turning on citadel server. It was working but from a day not. When I tried to turn it on have:

 

citserver[76547]: smtpclient: start full queue run , last_queue_job_processed=0 , last_queue_job_submitted=0

citserver[76547]: smtpclient: 1 messages to be processed

citserver[76547]: msgbase: CtdlFetchMessage(11041, 1)

citserver[76547]: smtpclient: attempting delivery of message <11041> now

citserver[76547]: smtpclient: smtp_attempt_delivery(11040, 0@test.com)

citserver[76547]: msgbase: CtdlOutputMsg(msgnum=11040, mode=1, section=<>)

citserver[76547]: msgbase: CtdlFetchMessage(11040, 1)

citserver[76547]: msgbase: CtdlOutputPreLoadedMsg(TheMessage=not null, 1, 0, 0, 1

citserver[76547]: smtpclient: dkim-signing for selector <hdfxv> in domain <XXXXX.XXXXXX.XXXXX>

citserver[76547]: SIGSEGV received in thread 133741677622976 at address 0x1

citserver[76547]: Stack frame #0: ./citserver(+0x34a9d) [0x5dced6cfaa9d]

citserver[76547]: Stack frame #1: /lib/x86_64-linux-gnu/libc.so.6(+0x45330) [0x79a32ce45330]

citserver[76547]: Stack frame #2: ./citserver(+0x723f7) [0x5dced6d383f7]

citserver[76547]: Stack frame #3: ./citserver(+0x72d6d) [0x5dced6d38d6d]

citserver[76547]: Stack frame #4: ./citserver(+0x776b3) [0x5dced6d3d6b3]

citserver[76547]: Stack frame #5: ./citserver(+0x78280) [0x5dced6d3e280]

citserver[76547]: Stack frame #6: ./citserver(+0x7899d) [0x5dced6d3e99d]

citserver[76547]: Stack frame #7: ./citserver(+0x78a44) [0x5dced6d3ea44]

citserver[76547]: Stack frame #8: ./citserver(+0x32bdf) [0x5dced6cf8bdf]

citserver[76547]: Stack frame #9: ./citserver(+0x1c052) [0x5dced6ce2052]

citserver[76547]: Stack frame #10: ./citserver(+0x35d7b) [0x5dced6cfbd7b]

citserver[76547]: Stack frame #11: /lib/x86_64-linux-gnu/libc.so.6(+0x9caa4) [0x79a32ce9caa4]

citserver[76547]: Stack frame #12: /lib/x86_64-linux-gnu/libc.so.6(+0x129c6c) [0x79a32cf29c6c]

Segmentation fault (core dumped)

 

From what I undersatnd there is a problem with reading email id=11041. Is there a way to remove it from database manually? It's Berkley DB from what I notice but i'm not able to do this... Could someone give  me a tip?

 

Best Regards

J.K.

I've got problem with turning on citadel server. It was working but from a day not. When I tried to turn it on have:

citserver[76547]: smtpclient: start full queue run , last_queue_job_processed=0 , last_queue_job_submitted=0

citserver[76547]: smtpclient: 1 messages to be processed

citserver[76547]: msgbase: CtdlFetchMessage(11041, 1)

citserver[76547]: smtpclient: attempting delivery of message <11041> now

citserver[76547]: smtpclient: smtp_attempt_delivery(11040, 0@test.com)

citserver[76547]: msgbase: CtdlOutputMsg(msgnum=11040, mode=1, section=<>)

citserver[76547]: msgbase: CtdlFetchMessage(11040, 1)

citserver[76547]: msgbase: CtdlOutputPreLoadedMsg(TheMessage=not null, 1, 0, 0, 1

citserver[76547]: smtpclient: dkim-signing for selector <hdfxv> in domain <XXXXX.XXXXXX.XXXXX>

citserver[76547]: SIGSEGV received in thread 133741677622976 at address 0x1

citserver[76547]: Stack frame #0: ./citserver(+0x34a9d) [0x5dced6cfaa9d]

citserver[76547]: Stack frame #1: /lib/x86_64-linux-gnu/libc.so.6(+0x45330) [0x79a32ce45330]

citserver[76547]: Stack frame #2: ./citserver(+0x723f7) [0x5dced6d383f7]

citserver[76547]: Stack frame #3: ./citserver(+0x72d6d) [0x5dced6d38d6d]

citserver[76547]: Stack frame #4: ./citserver(+0x776b3) [0x5dced6d3d6b3]

citserver[76547]: Stack frame #5: ./citserver(+0x78280) [0x5dced6d3e280]

citserver[76547]: Stack frame #6: ./citserver(+0x7899d) [0x5dced6d3e99d]

citserver[76547]: Stack frame #7: ./citserver(+0x78a44) [0x5dced6d3ea44]

citserver[76547]: Stack frame #8: ./citserver(+0x32bdf) [0x5dced6cf8bdf]

citserver[76547]: Stack frame #9: ./citserver(+0x1c052) [0x5dced6ce2052]

citserver[76547]: Stack frame #10: ./citserver(+0x35d7b) [0x5dced6cfbd7b]

citserver[76547]: Stack frame #11: /lib/x86_64-linux-gnu/libc.so.6(+0x9caa4) [0x79a32ce9caa4]

citserver[76547]: Stack frame #12: /lib/x86_64-linux-gnu/libc.so.6(+0x129c6c) [0x79a32cf29c6c]

Segmentation fault (core dumped)

From what I undersatnd there is a problem with reading email id=11041. Is there a way to remove it from database manually? It's Berkley DB from what I notice but i'm not able to do this... Could someone give  me a tip?

Best Regards

J.K.

Sorry again.

This night happened again. More coredumps. I updated the citadel. It installed and compiled a version but it remained the same version number. Did that attended my problem?

If not a send the new coredumps.

https://luisgo.pro/down/coredumps3.zip

I hope that you solved or are solving this problem.

Let see that if or not happen again.

Unfortunately, your core dumps are not useful to anyone because they are specific to your citserver binary.  I suppose if you include your citserver binary it might be useful, otherwise a stack trace is better.

In your case, we're just seeing so many weird things on your system that don't happen anywhere else.  It's difficult to pin down why.  I would strongly suggest that you give some consideration to moving to the containerized version of the Citadel system.  It is lovingly built for you in a carefully controlled environment.   Perhaps switch to the container version, and if necessary, do a ctdldump/ctdlload on your existing data.

And of course take lots of backups before doing anything.

Sorry again.

This night happened again. More coredumps. I updated the citadel. It installed and compiled a version but it remained the same version number. Did that attended my problem?

If not a send the new coredumps.

https://luisgo.pro/down/coredumps3.zip

I hope that you solved or are solving this problem.

Let see that if or not happen again.

Thank you,

Luís Gonçalves.

Wed Sep 17 2025 09:36:18 UTC from luisgo Subject: Re: Concerning tha last two posts in Support Room.

From a previous post (see above):

 

Centos 9, VPS (KVM), 3 GBytes RAM, 18 GBytes available disk, 2 virtual processors.

Last version of Citadel (1020)

Linux xxxxxx.xxx 5.14.0-612.el9.x86_64 #1 SMP PREEMPT_DYNAMIC Sat Aug 30 16:03:12 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux

processor       : 0

vendor_id       : GenuineIntel

cpu family      : 6

model           : 63

model name      : Intel(R) Xeon(R) CPU E5-2697 v3 @ 2.60GHz

stepping        : 2

cpu MHz         : 2599.925

cache size      : 4096 KB

physical id     : 0

siblings        : 1

core id         : 0

cpu cores       : 1

apicid          : 0

initial apicid  : 0

fpu             : yes

fpu_exception   : yes

cpuid level     : 15

wp              : yes

flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx pdpe1gb rdtscp lm constant_tsc nopl cpuid tsc_known_freq pni ssse3 cx16 sse4_1 sse4_2 x2apic movbe popcnt aes hypervisor lahf_lm abm pti xsaveopt xsavec xsaves

bugs            : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit mmio_stale_data bhi spectre_v2_user its

bogomips        : 5199.85

clflush size    : 64

cache_alignment : 64

address sizes   : 40 bits physical, 48 bits virtual

power management:

 

processor       : 1

vendor_id       : GenuineIntel

cpu family      : 6

model           : 63

model name      : Intel(R) Xeon(R) CPU E5-2697 v3 @ 2.60GHz

stepping        : 2

cpu MHz         : 2599.925

cache size      : 4096 KB

physical id     : 1

siblings        : 1

core id         : 0

cpu cores       : 1

apicid          : 1

initial apicid  : 0

fpu             : yes

fpu_exception   : yes

cpuid level     : 15

wp              : yes

flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx pdpe1gb rdtscp lm constant_tsc nopl cpuid tsc_known_freq pni ssse3 cx16 sse4_1 sse4_2 x2apic movbe popcnt aes hypervisor lahf_lm abm pti xsaveopt xsavec xsaves

bugs            : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit mmio_stale_data bhi spectre_v2_user its

bogomips        : 5199.85

clflush size    : 64

cache_alignment : 64

address sizes   : 40 bits physical, 48 bits virtual

 

power management:

Tue Sep 16 2025 14:22:31 UTC from Motobike Subject: Re: Concerning tha last two posts in Support Room.

 

Di Sep 16 2025 13:58:28 UTC von luisgo Betreff: Re: Concerning tha last two posts in Support Room.

I provided the core dumps for you all evaluate.

As I said in a past post is a Centos 9.

Tue Sep 16 2025 03:36:14 UTC from IGnatius T Foobar Subject: Re: Concerning tha last two posts in Support Room.

What system you are using ? This dont looks like a general
citadel problem for me. 

Agreed, this doesn't seem like a failure mode related to Citadel itself.
Something else is wrong with the system. Any log messages giving a clue?

 

Wich filesystem you are using ? ext4 or something else ? do you use disk encryption ? 

Maybe there are changes in kernel for system drivers ? when you have done the last update to your kernel ? wich kernel you are using ?

 

So many questions :D

Greetings

Mike

 

 

It is Centos 9 and the last version of openssl.

I analyzed better and in my server SMTP requires TLS. And I suppose that those errors are from servers with bad TLS or something near that. Because the server messages before those errors are from connections from outside servers. Also I have another port in SMTP-SSL, originally from other service. Perhaps that.

Thu Sep 18 2025 06:27:08 UTC from Motobike Subject: Re: Another problem.

You installed and configured TLS 1.3 on your Server ?

 

Do Sep 18 2025 03:21:40 UTC von luisgo Betreff: Another problem.

Dear All,

In the citserver log appear all the time:

Sep 18 05:03:00 luisgo.pro citserver[17435]: crypto: SSL_accept failed: wrong version number

 

See please:

https://luisgo.pro/images/cert1.jpg

https://luisgo.pro/images/cert2.jpg

Sorry in Portuguese.

Thank you,

Luís Gonçalves.

 

 

You installed and configured TLS 1.3 on your Server ?

Do Sep 18 2025 03:21:40 UTC von luisgo Betreff: Another problem.

Dear All,

In the citserver log appear all the time:

Sep 18 05:03:00 luisgo.pro citserver[17435]: crypto: SSL_accept failed: wrong version number

 

See please:

https://luisgo.pro/images/cert1.jpg

https://luisgo.pro/images/cert2.jpg

Sorry in Portuguese.

Thank you,

Luís Gonçalves.

 

Dear All,

In the citserver log appear all the time:

Sep 18 05:03:00 luisgo.pro citserver[17435]: crypto: SSL_accept failed: wrong version number

See please:

https://luisgo.pro/images/cert1.jpg

https://luisgo.pro/images/cert2.jpg

Sorry in Portuguese.

Thank you,

Luís Gonçalves.

From a previous post (see above):

Centos 9, VPS (KVM), 3 GBytes RAM, 18 GBytes available disk, 2 virtual processors.

Last version of Citadel (1020)

Linux xxxxxx.xxx 5.14.0-612.el9.x86_64 #1 SMP PREEMPT_DYNAMIC Sat Aug 30 16:03:12 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux

processor       : 0

vendor_id       : GenuineIntel

cpu family      : 6

model           : 63

model name      : Intel(R) Xeon(R) CPU E5-2697 v3 @ 2.60GHz

stepping        : 2

cpu MHz         : 2599.925

cache size      : 4096 KB

physical id     : 0

siblings        : 1

core id         : 0

cpu cores       : 1

apicid          : 0

initial apicid  : 0

fpu             : yes

fpu_exception   : yes

cpuid level     : 15

wp              : yes

flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx pdpe1gb rdtscp lm constant_tsc nopl cpuid tsc_known_freq pni ssse3 cx16 sse4_1 sse4_2 x2apic movbe popcnt aes hypervisor lahf_lm abm pti xsaveopt xsavec xsaves

bugs            : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit mmio_stale_data bhi spectre_v2_user its

bogomips        : 5199.85

clflush size    : 64

cache_alignment : 64

address sizes   : 40 bits physical, 48 bits virtual

power management:

processor       : 1

vendor_id       : GenuineIntel

cpu family      : 6

model           : 63

model name      : Intel(R) Xeon(R) CPU E5-2697 v3 @ 2.60GHz

stepping        : 2

cpu MHz         : 2599.925

cache size      : 4096 KB

physical id     : 1

siblings        : 1

core id         : 0

cpu cores       : 1

apicid          : 1

initial apicid  : 0

fpu             : yes

fpu_exception   : yes

cpuid level     : 15

wp              : yes

flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx pdpe1gb rdtscp lm constant_tsc nopl cpuid tsc_known_freq pni ssse3 cx16 sse4_1 sse4_2 x2apic movbe popcnt aes hypervisor lahf_lm abm pti xsaveopt xsavec xsaves

bugs            : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit mmio_stale_data bhi spectre_v2_user its

bogomips        : 5199.85

clflush size    : 64

cache_alignment : 64

address sizes   : 40 bits physical, 48 bits virtual

power management:

Tue Sep 16 2025 14:22:31 UTC from Motobike Subject: Re: Concerning tha last two posts in Support Room.

 

Di Sep 16 2025 13:58:28 UTC von luisgo Betreff: Re: Concerning tha last two posts in Support Room.

I provided the core dumps for you all evaluate.

As I said in a past post is a Centos 9.

Tue Sep 16 2025 03:36:14 UTC from IGnatius T Foobar Subject: Re: Concerning tha last two posts in Support Room.

What system you are using ? This dont looks like a general
citadel problem for me. 

Agreed, this doesn't seem like a failure mode related to Citadel itself.
Something else is wrong with the system. Any log messages giving a clue?

 

Wich filesystem you are using ? ext4 or something else ? do you use disk encryption ? 

Maybe there are changes in kernel for system drivers ? when you have done the last update to your kernel ? wich kernel you are using ?

 

So many questions :D

Greetings

Mike

 

Di Sep 16 2025 13:58:28 UTC von luisgo Betreff: Re: Concerning tha last two posts in Support Room.

I provided the core dumps for you all evaluate.

As I said in a past post is a Centos 9.

Tue Sep 16 2025 03:36:14 UTC from IGnatius T Foobar Subject: Re: Concerning tha last two posts in Support Room.

What system you are using ? This dont looks like a general
citadel problem for me. 

Agreed, this doesn't seem like a failure mode related to Citadel itself.
Something else is wrong with the system. Any log messages giving a clue?

 

Wich filesystem you are using ? ext4 or something else ? do you use disk encryption ? 

Maybe there are changes in kernel for system drivers ? when you have done the last update to your kernel ? wich kernel you are using ?

So many questions :D

Greetings

Mike

I provided the core dumps for you all evaluate.

As I said in a past post is a Centos 9.

Tue Sep 16 2025 03:36:14 UTC from IGnatius T Foobar Subject: Re: Concerning tha last two posts in Support Room.

What system you are using ? This dont looks like a general
citadel problem for me. 

Agreed, this doesn't seem like a failure mode related to Citadel itself.
Something else is wrong with the system. Any log messages giving a clue?

Dear Motobike,

That script did not worked. I used instead dump and load separatelly.

Thank you,

Luís Gonçalves.

Mon Sep 15 2025 12:53:23 UTC from Motobike Subject: Re: Concerning tha last two posts in Support Room.

 

Mo Sep 15 2025 12:30:08 UTC von luisgo Betreff: Re: Concerning tha last two posts in Support Room.

Dear Motobike,

Which script?

Thank you,

Luís Gonçalves.

 

Sun Sep 14 2025 20:17:27 UTC from Motobike Subject: Re: Concerning tha last two posts in Support Room.

Hi Luis,

i shrink database with the database script inside the program dir. That works fine for me. my database i now round about 90GB and i dont have any problems. 

 

Greetings

Mike

 

 

Look inside your citadel directory

 

root@citadel:/usr/local/citadel# ./database_cleanup.sh

 

You ever tryed this script ?

 

Greetings 

Mike

 

Thank you IGnatius T Foobar,

compiling went well,now it runs on recent version.

Fr Sep 12 2025 01:40:06 UTC von IGnatius T Foobar Betreff: Re: upgrade with easy install on raspberry pi os

 

Any idea what this mean?

maybe there is no longer support for a 32 bit OS?

32-bit support is ending soon, but it hasn't ended yet.

Try removing the file /usr/local/ctdlsupport/db-easyinstall.sum (or stash it somewhere safe) and attempt the build again.   This will force it to rebuild Berkeley DB.

 

Mo Sep 15 2025 12:30:08 UTC von luisgo Betreff: Re: Concerning tha last two posts in Support Room.

Dear Motobike,

Which script?

Thank you,

Luís Gonçalves.

 

Sun Sep 14 2025 20:17:27 UTC from Motobike Subject: Re: Concerning tha last two posts in Support Room.

Hi Luis,

i shrink database with the database script inside the program dir. That works fine for me. my database i now round about 90GB and i dont have any problems. 

 

Greetings

Mike

 

 

Look inside your citadel directory

root@citadel:/usr/local/citadel# ./database_cleanup.sh

Dear Motobike,

Which script?

Thank you,

Luís Gonçalves.

Sun Sep 14 2025 20:17:27 UTC from Motobike Subject: Re: Concerning tha last two posts in Support Room.

Hi Luis,

i shrink database with the database script inside the program dir. That works fine for me. my database i now round about 90GB and i dont have any problems. 

 

Greetings

Mike

 

Centos 9, VPS, 3 GBytes RAM, 18 GBytes available disk, 2 virtual processors.

Last version of Citadel (1020)

Linux xxxxxx.xxx 5.14.0-612.el9.x86_64 #1 SMP PREEMPT_DYNAMIC Sat Aug 30 16:03:12 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux

processor       : 0

vendor_id       : GenuineIntel

cpu family      : 6

model           : 63

model name      : Intel(R) Xeon(R) CPU E5-2697 v3 @ 2.60GHz

stepping        : 2

cpu MHz         : 2599.925

cache size      : 4096 KB

physical id     : 0

siblings        : 1

core id         : 0

cpu cores       : 1

apicid          : 0

initial apicid  : 0

fpu             : yes

fpu_exception   : yes

cpuid level     : 15

wp              : yes

flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx pdpe1gb rdtscp lm constant_tsc nopl cpuid tsc_known_freq pni ssse3 cx16 sse4_1 sse4_2 x2apic movbe popcnt aes hypervisor lahf_lm abm pti xsaveopt xsavec xsaves

bugs            : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit mmio_stale_data bhi spectre_v2_user its

bogomips        : 5199.85

clflush size    : 64

cache_alignment : 64

address sizes   : 40 bits physical, 48 bits virtual

power management:

processor       : 1

vendor_id       : GenuineIntel

cpu family      : 6

model           : 63

model name      : Intel(R) Xeon(R) CPU E5-2697 v3 @ 2.60GHz

stepping        : 2

cpu MHz         : 2599.925

cache size      : 4096 KB

physical id     : 1

siblings        : 1

core id         : 0

cpu cores       : 1

apicid          : 1

initial apicid  : 0

fpu             : yes

fpu_exception   : yes

cpuid level     : 15

wp              : yes

flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx pdpe1gb rdtscp lm constant_tsc nopl cpuid tsc_known_freq pni ssse3 cx16 sse4_1 sse4_2 x2apic movbe popcnt aes hypervisor lahf_lm abm pti xsaveopt xsavec xsaves

bugs            : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit mmio_stale_data bhi spectre_v2_user its

bogomips        : 5199.85

clflush size    : 64

cache_alignment : 64

address sizes   : 40 bits physical, 48 bits virtual

power management:

Sun Sep 14 2025 20:37:11 UTC from Motobike Subject: Re: Concerning tha last two posts in Support Room.

 

So Sep 14 2025 20:14:07 UTC von luisgo Betreff: Concerning tha last two posts in Support Room.

Dear All,

Due to problems reported in the last two posts in this room I am loosing emails. Perhaps due to Citadel misses to write to the database.

Thank you,

Luís Gonçalves.

What system you are using ? This dont looks like a general citadel problem for me. 

So Sep 14 2025 20:14:07 UTC von luisgo Betreff: Concerning tha last two posts in Support Room.

Dear All,

Due to problems reported in the last two posts in this room I am loosing emails. Perhaps due to Citadel misses to write to the database.

Thank you,

Luís Gonçalves.

What system you are using ? This dont looks like a general citadel problem for me. 

Hi Luis,

i shrink database with the database script inside the program dir. That works fine for me. my database i now round about 90GB and i dont have any problems. 

Greetings

Mike

Dear All,

Due to problems reported in the last two posts in this room I am loosing emails. Perhaps due to Citadel misses to write to the database.

Thank you,

Luís Gonçalves.

Dear All,

I am still waiting about the procedure to shrink the Database. How to configure the hidden configuration variable?

Luís Gonçalves.

Dear All,

Second time in a day that I have to delete the database and put back the backup.

Despite I said in a past post that I have not such much disk space I still have 18GBytes.

Every month I make a bakup of my Thunderbird and I delete one month of my older emails. (in a time range of 4 months). But as is normal the database does not reduce. The database is increasing despite it is said that the new emails will occupy the old ones.

My intuition is that this email replacement is not such solid procedure. Sorry to say.

See please the coredump files below:

https://luisgo.pro/down/coredumps2.zip

Thank you,

Luís Gonçalves.

Any idea what this mean?

maybe there is no longer support for a 32 bit OS?

32-bit support is ending soon, but it hasn't ended yet.

Try removing the file /usr/local/ctdlsupport/db-easyinstall.sum (or stash it somewhere safe) and attempt the build again.   This will force it to rebuild Berkeley DB.

Hi there,

after a while I wanted to upgrade my citadel installation on a raspberrypi with bookworm 32 bit official raspberrypi os

with easy install

My previous version is: Citadel Server 996 mit WebCit #define CLIENT_VERSION 996 /* This version of WebCit */
Server Build: 996

compiling leads to this error:

gcc -I/usr/local/ctdlsupport/include  -g -DBUILD_ID=\"25254\" -DCTDLDIR=\"/usr/local/citadel\"  -I/usr/local/ctdlsupport/include  -g -L/usr/local/ctdlsupport/lib -Wl,--rpath -Wl,/usr/local/ctdlsupport/lib  -lssl -lcrypto -lz utils/ctdldump.c server/visit.c -DVISIT_DUMP_LOAD server/backends/berkeley_db/berkeley_db.o server/backends/common/database.o -lcitadel -lz -ldb -lpthread -o ctdldump
/usr/bin/ld: /usr/local/ctdlsupport/lib/libdb.a(os_yield.o): in function `__os_yield_ctdl':
os_yield.c:(.text+0x94): undefined reference to `pthread_yield'
collect2: error: ld returned 1 exit status
gmake: *** [Makefile:59: ctdldump] Fehler 1

 Citadel Easy Install is aborting.
 The last few lines above this message may indicate what went wrong.

Any idea what this mean?

maybe there is no longer support for a 32 bit OS?

I perhaps solved.

In my server I have ports switched between services. And the services in firewalld were not well configured.

Until now is working.

Sorry about all.

Thu Sep 04 2025 15:34:13 UTC from luisgo Subject: Re: Urgent

https://luisgo.pro/down/coredumps.zip

 

Thu Sep 04 2025 15:18:39 UTC from luisgo Subject: Re: Urgent

With Webcit seems be stable. Some problem with external comunication to Thunderbird. 

 

 

Thu Sep 04 2025 14:38:41 UTC from luisgo Subject: Re: Urgent

I downgraded glibc and it did not worked.

A recompilation did not worked also.

 

Thu Sep 04 2025 13:58:07 UTC from luisgo Subject: Urgent

Dear all,

I updated my Centos 9 and the citadel simply stops with Core Dump.

When I do the easy install gives the following:

Error

D▒s▒

 

 

I suppose that was the "yum update". Some of the libraries used by citadel were updated. I suppose some incompatibility.

 

How I force a new compile of citadel?

 

Thanks,

 

Luís Gonçaçalves.

 

 

 

https://luisgo.pro/down/coredumps.zip

Thu Sep 04 2025 15:18:39 UTC from luisgo Subject: Re: Urgent

With Webcit seems be stable. Some problem with external comunication to Thunderbird. 

 

 

Thu Sep 04 2025 14:38:41 UTC from luisgo Subject: Re: Urgent

I downgraded glibc and it did not worked.

A recompilation did not worked also.

 

Thu Sep 04 2025 13:58:07 UTC from luisgo Subject: Urgent

Dear all,

I updated my Centos 9 and the citadel simply stops with Core Dump.

When I do the easy install gives the following:

Error

D▒s▒

 

 

I suppose that was the "yum update". Some of the libraries used by citadel were updated. I suppose some incompatibility.

 

How I force a new compile of citadel?

 

Thanks,

 

Luís Gonçaçalves.

 

 

With Webcit seems be stable. Some problem with external comunication to Thunderbird. 

Thu Sep 04 2025 14:38:41 UTC from luisgo Subject: Re: Urgent

I downgraded glibc and it did not worked.

A recompilation did not worked also.

 

Thu Sep 04 2025 13:58:07 UTC from luisgo Subject: Urgent

Dear all,

I updated my Centos 9 and the citadel simply stops with Core Dump.

When I do the easy install gives the following:

Error

D▒s▒

 

 

I suppose that was the "yum update". Some of the libraries used by citadel were updated. I suppose some incompatibility.

 

How I force a new compile of citadel?

 

Thanks,

 

Luís Gonçaçalves.

 

I downgraded glibc and it did not worked.

A recompilation did not worked also.

Thu Sep 04 2025 13:58:07 UTC from luisgo Subject: Urgent

Dear all,

I updated my Centos 9 and the citadel simply stops with Core Dump.

When I do the easy install gives the following:

Error

D▒s▒

 

 

I suppose that was the "yum update". Some of the libraries used by citadel were updated. I suppose some incompatibility.

 

How I force a new compile of citadel?

 

Thanks,

 

Luís Gonçaçalves.

Dear all,

I updated my Centos 9 and the citadel simply stops with Core Dump.

When I do the easy install gives the following:

Error

D▒s▒

Mo Sep 01 2025 17:53:00 UTC von IGnatius T Foobar Betreff: Re: BCC

There is a problem with BCC recieptiens.

They will all appear in Mail header as > Envelope-to:

Is there a option to hide recieptens in header ?

Can you clarify please, is this on outbound or inbound email?

Hi Ignatius,

this happens on Outbound Mails. It doesnt matter wich Client you use. All BCC mails will show up for everybody who receive the mail. Not in client, but if you look in header from the mail... all will show up @envelopeto

Greetings

Mike

Dear Foobar,

I have not so much space.

Do not see this as I putting bad reputation on the software.

Could you please explain how to set "c_shrink_db_files"?

Thank you,

Luís Gonçalves.

Mon Sep 01 2025 17:57:32 UTC from IGnatius T Foobar Subject: Re: Shrink my databases.

I want to shrink my databases. I tried with the shell script "database_cleanup.sh" and it gives a error even with citadel shutdown and with plenty of disk space (I renamed /tmp in the script).

How to set the "c_shrink_db_files" variable (before compilation)?

I want only an one time shrink.

c_shrink_db_files is not a compile-time option.  We've worked hard to have as few of those as possible.

If you set the c_shrink_db_files configuration option, the database will be compacted at shutdown time.

If you're not satisfied with the results, I would suggest using ctdldump and ctdlload, not database_cleanup.sh.   But really, Citadel is good with disk space -- it will reuse the "holes" in those files to write new data.  At some point your disk utilization will stabilize if you have both new data coming in and old data being purged.  If you have plenty of disk space and your system is running cleanly I would advise leaving it alone.

I want to shrink my databases. I tried with the shell script "database_cleanup.sh" and it gives a error even with citadel shutdown and with plenty of disk space (I renamed /tmp in the script).

How to set the "c_shrink_db_files" variable (before compilation)?

I want only an one time shrink.

c_shrink_db_files is not a compile-time option.  We've worked hard to have as few of those as possible.

If you set the c_shrink_db_files configuration option, the database will be compacted at shutdown time.

If you're not satisfied with the results, I would suggest using ctdldump and ctdlload, not database_cleanup.sh.   But really, Citadel is good with disk space -- it will reuse the "holes" in those files to write new data.  At some point your disk utilization will stabilize if you have both new data coming in and old data being purged.  If you have plenty of disk space and your system is running cleanly I would advise leaving it alone.

There is a problem with BCC recieptiens.

They will all appear in Mail header as > Envelope-to:

Is there a option to hide recieptens in header ?

Can you clarify please, is this on outbound or inbound email?

Dear All,

I want to shrink my databases. I tried with the shell script "database_cleanup.sh" and it gives a error even with citadel shutdown and with plenty of disk space (I renamed /tmp in the script).

How to set the "c_shrink_db_files" variable (before compilation)?

I want only an one time shrink.

Thank you,

Luís Gonçalves.

There is a problem with BCC recieptiens.

They will all appear in Mail header as > Envelope-to:

Is there a option to hide recieptens in header ?

Is it possible to set a quota for space used per user? Want to be sure one user doesn't chew up all the space...

If you create a room and set up a Mailing List. In a Docker Container, subscribers will not shown in overview.

In a normal installation it works fine. 

2099527869@Uncensored

Hi there,

my protocol says this.

Jul 18 17:50:17 pbcontrol citserver[21027]: SIGSEGV received in thread 139790179628800 at address 0x270

Jul 18 17:50:17 pbcontrol citserver[21027]: Stack frame #0: /usr/local/citadel/citserver(+0x163dc) [0x55f5876173dc]

Jul 18 17:50:17 pbcontrol citserver[21027]: Stack frame #1: /lib/x86_64-linux-gnu/libpthread.so.0(+0x12730) [0x7f23931de730]

Jul 18 17:50:17 pbcontrol citserver[21027]: Stack frame #2: /usr/local/citadel/citserver(+0x61dc0) [0x55f587662dc0]

Jul 18 17:50:17 pbcontrol citserver[21027]: Stack frame #3: /usr/local/citadel/citserver(+0x62bd4) [0x55f587663bd4]

Jul 18 17:50:17 pbcontrol citserver[21027]: Stack frame #4: /usr/local/citadel/citserver(+0x62e7c) [0x55f587663e7c]

Jul 18 17:50:17 pbcontrol citserver[21027]: Stack frame #5: /usr/local/citadel/citserver(+0x63aec) [0x55f587664aec]

Jul 18 17:50:17 pbcontrol citserver[21027]: Stack frame #6: /usr/local/citadel/citserver(+0x6e044) [0x55f58766f044]

Jul 18 17:50:17 pbcontrol citserver[21027]: Stack frame #7: /usr/local/citadel/citserver(+0x1732d) [0x55f58761832d]

Jul 18 17:50:17 pbcontrol citserver[21027]: Stack frame #8: /lib/x86_64-linux-gnu/libpthread.so.0(+0x7fa3) [0x7f23931d3fa3]

Jul 18 17:50:17 pbcontrol citserver[21027]: Stack frame #9: /lib/x86_64-linux-gnu/libc.so.6(clone+0x3f) [0x7f2392f1406f]

do someone else have any error like this since update 1018 ?

Di Jul 15 2025 03:41:57 UTC von IGnatius T Foobar Betreff: Re: docker image keeps crashing

Give the new container image a try and see how we did now.

I wholeheartly agree on IBM. Otherwise, I didn't had the chance to test too thoroughly, but hey, so far it looks good  now! At least calling the login screen and editing rooms now seems to work without crashing. Nice job, thanks again! 

In case I'll stumble over other issues, be sure, I'll let you know

Greetings:

 Used easy install method. Was able to get spamd/clamav to function.

 However unable to modify/edit drafts (draft room) . No prompt for editing draft or to "send message" from draft room available.

Write mail with Tiny MCE is o.k.  Is there some configuration that was missed?

 Thanks

Wow, I really thought that was going to fix it.   Now I also see that the admin account is being created in this trace, which means it's the very first run?

If you could share what OS distribution you're using and what version of Podman is on it, I'd like to try to reproduce the error.

Sa Jul 12 2025 02:32:52 UTC von IGnatius T Foobar Betreff: Re: docker image keeps crashing

All righty then, a fix has been checked in, download the new container image (version 1018) and let's see how it works.   Attach the trace if not.

Seems, the Pasta have been a little bit too salty. Happens to the best of us. See Attachment, called without ssl, or just http.

Anyway, mille gracie for the very fast response/patch, even if not complete. 

All righty then, a fix has been checked in, download the new container image (version 1018) and let's see how it works.   Attach the trace if not.

I have no idea, what is going in, but the suggestion seems to be ssl related. Still, the server also crashes, when called explicitly with http, not https. Again, these crashes are happening before the loginscreen appears. Takes about ~30 seconds to load the site, DNS however is fine (unless there is a podman problem which may very well be, as I am new to this and pasta)

I am an honorary Italian Grandmother so I know plenty about pasta.  But that's not important right now.

These traces offer some good clues.  It's crashing in cprintf() which is being called by cmd_oimg() and I found an uninitialized variable in cmd_oimg().   Honestly I don't know how you're the only one reporting this problem, but maybe it has to do with podman.  I only know it's been tested on Docker Engine and on Kubernetes (probably with runc).  In any case, a fix should be forthcoming if that's the problem.

Do Jul 10 2025 00:03:17 UTC von IGnatius T Foobar Betreff: Re: docker image keeps crashing

I updated the container image again today. Went back to offsets because addr2line is hallucinating about where the file names and line numbers line up. I got that weird imap.c one too, and it's definitely wrong.

Also turned up the logging level so we'll get more context.

Now we are talking, therefore I have attached them, instead of posting the output. 

I have no idea, what is going in, but the suggestion seems to be ssl related. Still, the server also crashes, when called explicitly with http, not https. Again, these crashes are happening before the loginscreen appears. Takes about ~30 seconds to load the site, DNS however is fine (unless there is a podman problem which may very well be, as I am new to this and pasta)

Fr Jul 04 2025 00:47:30 UTC von IGnatius T Foobar Betreff: Re: docker image keeps crashing

I am having trouble getting podmal to be ba any verbose at all, and
running in the foreground does not talk much either:

Ok, let's try this. I added some code to the server and to the supervisor, and now when it crashes it will make its best effort to produce a stack trace that has some filenames and line numbers in it.

Go ahead and update your container with the latest image.

Not too chatty, either. But maybe it is still helpful. As you may see, this is the very first start and it crashes (as it usually does), when loading the page, before the login screen is being presented. Hence, no timezone yet. Another instance, where it regulary chrashes, is, when editing certain parameters of rooms.  But this one is the crash from before the login screen:

$ podman run --systemd=true --rm --cpus=2 --memory=1g --name=citadel --hostname=hello.world.net --mount=type=bind,source=/daten/podman/data/citadel,destination=/citadel-data,ro=false,U=true --network=pasta:--interface,dummy.pod,--ns-ifname,tap15.pod,--ns-mac-addr,2a:00:00:00:00:15,--address,192.168.89.15,--netmask,255.255.255.0
,--gateway,192.168.89.1,--outbound,192.168.89.15,--outbound-if4,dummy.pod,--fqdn,hello.world.net,--no-dhcpv6,--no-dhcp,--dns,none,--no-map-gw,--tcp-ports,192.168.89.1/25,--tcp-ports,192.168.89.1/80,--tcp-ports,192.168.89.1/110,--tcp-ports,192.168.89.1/119,--tcp-ports,192.168.89.1/143,--tcp-ports,192.168.89.1/443,--tcp-ports,192.168.89.1/465,--tcp-ports,192
.168.89.1/504,--tcp-ports,192.168.89.1/563,--tcp-ports,192.168.89.1/587,--tcp-ports,192.168.89.1/993,--tcp-ports,192.168.89.1/995,--tcp-ports,192.168.89.1/5222 docker.io/citadeldotorg/citadel
2099526169@UncensoredI am having trouble getting podmal to be ba any verbose at all, and >running in the foreground does not talk much either: Ok, let's try this. I added some code to the server and to the supervisor, and now when it crashes it will make its best effort to produce a stack trace that has some filenames and line numbers in it. Go ahead and update your container with the latest image. ]]>https://uncensored.citadel.org/readfwd?go=Citadel%20Support?start_reading_at=2099525779Mon, 30 Jun 2025 17:18:23 -00002099525779@Uncensored

Sa Jun 28 2025 18:11:05 UTC von IGnatius T Foobar Betreff: Re: docker image keeps crashing

Running the docker image on arch/podman 5.5.1 (unpriviledged) seems to
crash rather happily, after some light use:

If you could run the container in the foreground with full logging turned on, it would be great if you could capture the last screenful of log messages before a crash.

As your previous log capture shows, we've been trying to get it to be better about showing where it crashed, but all we're able to get so far is a program name and memory offset.

I am having trouble getting podmal to be ba any verbose at all, and running in the foreground does not talk much either:

$ podman run --systemd=true --rm --cpus=2 --memory=1g --name=citadel --hostname=hello.world.net --mount=type=bind,source=/daten/podman/data/citadel,destination=/citadel-data,ro=false,U=true --network=pasta:--interface,dummy.pod,--ns-ifname,tap15.pod,--ns-mac-addr,2a:00:00:00:00:15,--address,192.168.89.15,--netmask,255.255.255.0,--gateway,192.168.89.1,--outbound,192.168.89.15,--outbound-if4,dummy.pod,--fqdn,hello.world.net,--no-dhcpv6,--no-dhcp,--dns,none,--no-map-gw,--tcp-ports,192.168.89.1/25,--tcp-ports,192.168.89.1/80,--tcp-ports,192.168.89.1/110,--tcp-ports,192.168.89.1/119,--tcp-ports,192.168.89.1/143,--tcp-ports,192.168.89.1/443,--tcp-ports,192.168.89.1/465,--tcp-ports,192.168.89.1/504,--tcp-ports,192.168.89.1/563,--tcp-ports,192.168.89.1/587,--tcp-ports,192.168.89.1/993,--tcp-ports,192.168.89.1/995,--tcp-ports,192.168.89.1/5222 docker.io/citadeldotorg/citadel
ctdlvisor: Welcome to the Citadel System running in a container.
ctdlvisor: command line arguments: /usr/local/bin/ctdlvisor 
 

I have however, attached a coredumd for each of above crashes. Those came from a fresh install (empty citadel-data), so nothing secret in there. I hope. Maybe these help. In case you have any more hints for verbosity, just let me know, please. 

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 p ]]>https://uncensored.citadel.org/readfwd?go=Citadel%20Support?start_reading_at=2099525337Thu, 26 Jun 2025 05:54:51 -00002099525337@Uncensored

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.

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

Di Jun 24 2025 02:23:28 UTC von IGnatius T Foobar Betreff: Re: Textclient and docker

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!

Di Jun 24 2025 02:27:46 UTC von IGnatius T Foobar Betreff: 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.

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.  

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

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

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.

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

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

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"}

The upgrade to 1103 worked for me.

Thanks

Citserver has not crashed since my last message after installing the newer version, even with Webcit up.  Not sure what changed.

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

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_ ]]>https://uncensored.citadel.org/readfwd?go=Citadel%20Support?start_reading_at=2099521681Fri, 23 May 2025 22:01:50 -00002099521681@Uncensored

I am running on Debian Bullseye/Sid. 

As far as the messages folder... It's empty, I'm guessing that's not right.

2099521613@Uncensored

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.

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?

We might be able to work with that.  At least we have line numbers and calls to look at.  That's an odd place for it to have trouble though.    What operating system are you on?

I ran the GDB instructions again and I believe I have a better backtrace than the one I posted.  Any ideas?

Thread 3 (Thread 0x7ffff3f4d700 (LWP 18942)):
#0  0x00007ffff79de947 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#1  0x00007ffff78ced15 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#2  0x00007ffff78e1f9a in ?? () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#3  0x00005555555811fb in cprintf (format=0x5555556c8f6f "%d Cannot open '%s': %s\n") at server/sysdep.c:436
        arg_ptr = {{gp_offset = 32, fp_offset = 48, overflow_arg_area = 0x7ffff3f4b900, reg_save_area = 0x7ffff3f4b840}}
        buf = "571 Cannot open 'messages/hello': ôóÿ200\000\236Ýi­pÃ%`¶ôóÿ\177\000\000\000\236Ýi­pÃ%ÿ\003\000\000\000\000\000\000ØF\226÷ÿ\177\000\000h\205lUUU\000\000H¶ôóÿ\177\000\000\020\000\000\000ÿ\177\000\000ðŽôóÿ\177\000\000°Žôóÿ\177\000\000\000\236Ýi­pÃ%\001\200­û!\000\000\000`¶ôóÿ\177\000\000@\023Á÷ÿ\177\000\000`¶ôó�

I am hoping this is what you are looking for, I have never used GDB before:

#0  0x00007ffff79de727 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#1  0x00007ffff78ced15 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#2  0x00007ffff78e1f9a in ?? () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#3  0x00005555555811fb in cprintf (
    format=0x5555556c8f6f "%d Cannot open '%s': %s\n") at server/sysdep.c:436
        arg_ptr = {{gp_offset = 32, fp_offset = 48,
            overflow_arg_area = 0x7ffff474e900,
            reg_save_area = 0x7ffff474e840}}
        buf = "571 Cannot open 'messages/hello': tôÿ200\000îÿ/ ó%7`ætôÿ\177\000\000\000îÿ/ ó%7ÿ\003\000\000\000\000\000\000žD\226÷ÿ\177\000\000h\205lUUU\000\000Hætôÿ\177\000\000\020\000\000\000ÿ\177\000\000ðätôÿ\177\000\000°ätôÿ\177\000\000\000îÿ/ ó%7\001\200­û!\000\000\000`ætôÿ\177\000\000@\023Á÷ÿ\177\000\000`ætôÿ\ ]]>https://uncensored.citadel.org/readfwd?go=Citadel%20Support?start_reading_at=2099521083Tue, 20 May 2025 03:06:51 -00002099521083@Uncensoredhttps://uncensored.citadel.org/readfwd?go=Citadel%20Support?start_reading_at=2099520996Mon, 19 May 2025 15:04:50 -00002099520996@Uncensored

I am having a similar problem after updating from 1000 to Cit 1011/Webcit 1012 using easyinstall.  The Citadel service is restarting continuously after segfauting and eventually dies due to too many failures.  Syslog messages follow:

May 17 00:36:41 nadia citserver[277225]: context: session (citadel-UDS) started from  () uid=-1
May 17 00:36:41 nadia webcit[275098]: StrBuf_ServGetln(): Server connection broken: Transport endpoint is not connected
May 17 00:36:41 nadia kernel: [10736988.345626] citserver[277227]: segfault at 6a899820 ip 00007f296a86d727 sp 00007f2966ddbce8 error 4 in libc-2.31.so[7f296a707000+178000]
May 17 00:36:41 nadia kernel: [10736988.345635] Code: 85 c0 0f 85 eb 00 00 00 48 83 c7 20 83 e1 1f 48 83 e7 e0 eb 42 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 83 e1 1f 48 83 e7 e0 <c5> fd 74 0f c5 fd d7 c1 d3 f8 85 c0 74 1b f3 0f bc c0 4>
May 17 00:36:41 nadia webcit[275098]: HTTP: 200 [11.337045] GET
May 17 00:36:41 nadia systemd[1]: citadel.service: Main process exited, code=killed, status=11/SEGV
May 17 00:36:41 nadia systemd[1]: citadel.service: Failed with result 'signal'.
May 17 00:36:41 nadia systemd[1]: citadel.service: Scheduled restart job, restart counter is at 81.
]]>https://uncensored.citadel.org/readfwd?go=Citadel%20Support?start_reading_at=2099520831Sun, 18 May 2025 11:11:39 -00002099520831@Uncensored

I am having a similar problem after updating from 1000 to Cit 1011/Webcit 1012 using easyinstall.  The Citadel service is restarting continuously after segfauting and eventually dies due to too many failures.  Syslog messages follow:

May 17 00:36:41 nadia citserver[277225]: context: session (citadel-UDS) started from  () uid=-1
May 17 00:36:41 nadia webcit[275098]: StrBuf_ServGetln(): Server connection broken: Transport endpoint is not connected
May 17 00:36:41 nadia kernel: [10736988.345626] citserver[277227]: segfault at 6a899820 ip 00007f296a86d727 sp 00007f2966ddbce8 error 4 in libc-2.31.so[7f296a707000+178000]
May 17 00:36:41 nadia kernel: [10736988.345635] Code: 85 c0 0f 85 eb 00 00 00 48 83 c7 20 83 e1 1f 48 83 e7 e0 eb 42 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 83 e1 1f 48 83 e7 e0 <c5> fd 74 0f c5 fd d7 c1 d3 f8 85 c0 74 1b f3 0f bc c0 4>
May 17 00:36:41 nadia webcit[275098]: HTTP: 200 [11.337045] GET
May 17 00:36:41 nadia systemd[1]: citadel.service: Main process exited, code=killed, status=11/SEGV
May 17 00:36:41 nadia systemd[1]: citadel.service: Failed with result 'signal'.
May 17 00:36:41 nadia systemd[1]: citadel.service: Scheduled restart job, restart counter is at 81.
]]>https://uncensored.citadel.org/readfwd?go=Citadel%20Support?start_reading_at=2099520637Fri, 16 May 2025 03:33:50 -00002099520637@Uncensoredhttps://uncensored.citadel.org/readfwd?go=Citadel%20Support?start_reading_at=2099520057Sat, 10 May 2025 22:41:57 -00002099520057@Uncensored

Got same Error and set befor session limit to 50. After setting to 0, i got no error anymore. 

Sa Mai 10 2025 19:25:44 UTC von IGnatius T Foobar Betreff: Re: Initial web access pops 503 error.

I just double checked and concurrent session limit is set to 0.

So ... did changing that to some nonzero value fix it?

I just double checked and concurrent session limit is set to 0.

Thank you

Do you have set a Session limit in the options ?

Mi Mai 07 2025 17:49:54 UTC von MisterC Betreff: Initial web access pops 503 error.

Since updating to 1012, the first access of the website issues a 503 error:

This program was unable to connect or stay connected to the Citadel server. Please report this problem to your system administrator.

If you reload, it works and stays working.  If you navigate away for a while (half hourish?) and go back you get the error again.

 

In the log, I see a message like:

2025-05-07T17:41:59.145989868Z webcit[8]: StrBuf_ServGetln(): Server connection broken: Resource temporarily unavailable

This is a private/testing instance so I'm the only user, so I can't comment if other users have this problem.

I am not sure if I broke something or it's a regression from 1011 to 1012

 

Thanks!

Since updating to 1012, the first access of the website issues a 503 error:

This program was unable to connect or stay connected to the Citadel server. Please report this problem to your system administrator.

If you reload, it works and stays working.  If you navigate away for a while (half hourish?) and go back you get the error again.

In the log, I see a message like:

This is a private/testing instance so I'm the only user, so I can't comment if other users have this problem.

I am not sure if I broke something or it's a regression from 1011 to 1012

Thanks!

I hope this time I am not being rude. Thank you.

Tue May 06 2025 11:10:54 UTC from luisgo Subject: Re: Message with more than 40 destinataries

Good Afternoon,

Cloud you please increase to say 4096 or 8192 charaters instead of 1024?

Or it has difficult implications on the database?

Thank you,

Luís Gonçalves.

Tue May 06 2025 02:25:09 UTC from IGnatius T Foobar Subject: Re: Message with more than 40 destinataries

 

I suppose this is a limitation of the Citadel Email Server.

It is normal that I send batches greater than 100 emails each.

Could it be solved?

I believe there is a limit of 1024 characters.  I don't quite remember whether that's in total or for each of to/cc/bcc, but it's a character limit, not an address limit.

 

Good Afternoon,

Cloud you please increase to say 4096 or 8192 charaters instead of 1024?

Or it has difficult implications on the database?

Thank you,

Luís Gonçalves.

Tue May 06 2025 02:25:09 UTC from IGnatius T Foobar Subject: Re: Message with more than 40 destinataries

 

I suppose this is a limitation of the Citadel Email Server.

It is normal that I send batches greater than 100 emails each.

Could it be solved?

I believe there is a limit of 1024 characters.  I don't quite remember whether that's in total or for each of to/cc/bcc, but it's a character limit, not an address limit.

I suppose this is a limitation of the Citadel Email Server.

It is normal that I send batches greater than 100 emails each.

Could it be solved?

I believe there is a limit of 1024 characters.  I don't quite remember whether that's in total or for each of to/cc/bcc, but it's a character limit, not an address limit.

i got problems with insert links after update to 1011. Same here...

Maybe try from another browser or clear your cache?   It seems to work for me.

Good Night (here),

I use Thunderbird as email client.

Due to I am being now unemployed I send lots of emails advertizing me. I use an email template and the plugin/extension Merge to send a batch of emails.

When I send a batch of several emails and store the template email in a folder in the citadel server I notice that I have only access to about 40 emails addresses (i.e. when I do a reply to all from the email template) when the template have much more than 40 destinataries. When I store in a local folder or in another email server (e.g. Microsoft Exchange) I have access to all the emails addresses. 

I suppose this is a limitation of the Citadel Email Server.

It is normal that I send batches greater than 100 emails each.

Could it be solved?

Thank you,

Luís Gonçalves.

Hi there,

i got problems with insert links after update to 1011. Same here...

2099518726@Uncensored

Sorry for the dumb question :)

There was a missing Information to edit it in systemd.

nano /etc/systemd/system/webcit-https.service

nano /etc/systemd/system/webcit-http.service

[Unit]

Description=Citadel web service with encryption

After=citadel.target

[Service]

ExecStart=/usr/local/webcit/webcit -s -p443 -g /dotgoto?room='MBF' uds /usr/local/citadel

ExecReload=/bin/kill

KillMode=process

Restart=always

RestartSec=3

[Install]

WantedBy=multi-user.target

Do Mai 01 2025 09:26:51 UTC von Motobike Betreff: Re: First Room

Hi Ignatius,

but where will it be defined ? First start citadel, it will defined in a config that starts webcit with parameters X. 

 

Do Feb 13 2025 23:38:47 UTC von IGnatius T Foobar Betreff: Re: First Room

What you mean with [other options] ?

WebCit is normally called with options to specify the port number it's listening on, whether to enable HTTPS, and the directory where Citadel Server can be found.

For example, here are the commands we are using to start WebCit here:

webcit -x1 -s -p 443 -g /dotgoto?room='Welcome to UNCENSORED!' uds /citadel-data
webcit -x1 -p 80 -g /dotgoto?room='Welcome to UNCENSORED!' uds /citadel-data

(Most sites will have two, one for HTTP and one for HTTPS, but if you have Citadel sitting behind a proxy or if you have some other webserver redirecting HTTP to HTTPS you might only have one.)

 

Hi Ignatius,

but where will it be defined ? First start citadel, it will defined in a config that starts webcit with parameters X. 

Do Feb 13 2025 23:38:47 UTC von IGnatius T Foobar Betreff: Re: First Room

What you mean with [other options] ?

WebCit is normally called with options to specify the port number it's listening on, whether to enable HTTPS, and the directory where Citadel Server can be found.

For example, here are the commands we are using to start WebCit here:

webcit -x1 -s -p 443 -g /dotgoto?room='Welcome to UNCENSORED!' uds /citadel-data
webcit -x1 -p 80 -g /dotgoto?room='Welcome to UNCENSORED!' uds /citadel-data

(Most sites will have two, one for HTTP and one for HTTPS, but if you have Citadel sitting behind a proxy or if you have some other webserver redirecting HTTP to HTTPS you might only have one.)

Dear All,

I am getting again message not found errors in the syslog:

Apr 27 11:12:55 [hostname]citserver[172369]: citserver[172369]: msgbase: error; invalid preloaded message for output
Apr 27 11:12:55 [hostname]citserver[172369]: msgbase: message #93638 was not found
Apr 27 11:12:55 [hostname]citserver[172369]: message repeated 2 times: [ msgbase: message #93638 was not found]
Apr 27 11:12:55 [hostname]citserver[172369]: msgbase: error; invalid preloaded message for output
Apr 27 11:12:56 [hostname]citserver[172369]: citserver[172369]: msgbase: message #93647 was not found
Apr 27 11:12:56 [hostname]citserver[172369]: citserver[172369]: msgbase: message #93647 was not found
Apr 27 11:12:56 [hostname]citserver[172369]: msgbase: message #93647 was not found
Apr 27 11:12:56 [hostname]citserver[172369]: citserver[172369]: msgbase: message #93647 was not found
Apr 27 11:12:56 [hostname]citserver[172369]: citserver[172369]: msgbase: error; invalid preloaded message for output
Apr 27 11:12:56 [hostname]citserver[172369]: msgbase: messa

Believe ther was a way to target and remove these message references from the system using the console interface but I can't recall how this was done. Also did not find this in the documentation. Can somebody remind me on the procedure, please.

Thanks! 

Mo Apr 14 2025 18:25:54 UTC von IGnatius T Foobar Betreff: Re: Citadel Server sudden stop and restart fails with error DBD2055

However, just to re-confirm in my particular case disk is no issue at
all. I have around 470GiB free on the file system where the database
resides. So question is still how I can understand what causes the
SIGSEGV crash on the citadel server. 

If you have a core dump you can do a stack trace against it. If not, you can run citserver in the debugger. Like this:

systemctl stop citserver
cd /usr/local/citadel
gdb ./citserver
gdb> run -x9
[ wait for it to crash ]
gdb> thread apply all bt

Then post the output here.

With some logfile watching I was able to track the issue back to two iOS devices. As soon as these start syncing IMAP the server crashes and executes automatic restart. I disabled the devices and did export and re-import of database. Server was stable after. Re-nable on device was triggering the crashes again. Went then and updated server to 1011. So far server has not crahed again even with the Apple devices synching. Will watch, let's hope this did the trick.  

Mo Apr 14 2025 01:39:12 UTC von IGnatius T Foobar Betreff: Re: Citadel Server sudden stop and restart fails with error DBD2055

I had a similar problem this late afternoon. I had to recover the data
files from a backup due a full disk. I reported a similar problem some
time ago.

You know what, I'm going to add something to the server to make it refuse to accept new messages when the free disk space is under 100 MB. It sure seems better than seeing people have problems *after* they run out of disk.

That could indeed be helpful for scenarios where disk space is an issue. However, just to re-confirm in my particular case disk is no issue at all. I have around 470GiB free on the file system where the database resides. So question is still how I can understand what causes the SIGSEGV crash on the citadel server. 

Dear All,

I tried to disable without success. Is it normal?

ManageSieve Port (-1 to disable)

Thanks,

Luís Gonçalves

Mon Apr 14 2025 06:57:22 UTC from luisgo Subject: Re: Citadel Server sudden stop and restart fails with error DBD2055

 

Mon Apr 14 2025 01:39:12 UTC from IGnatius T Foobar Subject: Re: Citadel Server sudden stop and restart fails with error DBD2055

I had a similar problem this late afternoon. I had to recover the data
files from a backup due a full disk. I reported a similar problem some
time ago.

You know what, I'm going to add something to the server to make it refuse to accept new messages when the free disk space is under 100 MB. It sure seems better than seeing people have problems *after* they run out of disk.

Dear All,

What I think that will help a lot from my experience dealing with this is doing the following:

It is doing Auto-Purging from 15 minutes in 15 minutes instead only one time a day.

Hour to run database auto-purge

Thanks,

Luís Gonçalves

Doing that without accepting transactions (stopped server).

Mon Apr 14 2025 01:39:12 UTC from IGnatius T Foobar Subject: Re: Citadel Server sudden stop and restart fails with error DBD2055

I had a similar problem this late afternoon. I had to recover the data
files from a backup due a full disk. I reported a similar problem some
time ago.

You know what, I'm going to add something to the server to make it refuse to accept new messages when the free disk space is under 100 MB. It sure seems better than seeing people have problems *after* they run out of disk.

Dear All,

What I think that will help a lot from my experience dealing with this is doing the following:

It is doing Auto-Purging from 15 minutes in 15 minutes instead only one time a day.

Thanks,

Luís Gonçalves

I had a similar problem this late afternoon. I had to recover the data files from a backup due a full disk. I reported a similar problem some time ago.

Sun Apr 13 2025 17:54:25 UTC from p.agsten Subject: Re: Citadel Server sudden stop and restart fails with error DBD2055

To add to this I further analysed the syslog and found that within 8 hours after the first crash there were three restarts after signal 11 (SEGV). After the third restart the fourth server crash was with signal 6 (ABRT) after DB runs out of lock entries:

Apr 13 18:23:03 [hostname] citserver[711154]: citserver[711154]: bdb: BDB2055 Lock table is out of available lock entries

Apr 13 18:23:03 [hostname] citserver[711154]: citserver[711154]: bdb: bdb_store(09): error 12: Cannot allocate memory

Apr 13 18:23:03 [hostname] citserver[711154]: bdb: BDB2055 Lock table is out of available lock entries

Apr 13 18:23:03 [hostname] citserver[711154]: bdb: bdb_store(09): error 12: Cannot allocate memory

Apr 13 18:23:03 [hostname] systemd[1]: citadel.service: Main process exited, code=killed, status=6/ABRT 

From there the server restarted and survived for about another 3 minutes accepting connections. Then restarted 231 times generating around 6.500 log files within 19 minutes.

Looks like one of the SEGV somehow corrupt or block the DB. The lock table issue is just the fallout. Is there a log where we can see what causes signal 11 (SEGV)?

So Apr 13 2025 17:20:30 UTC von p.agsten Betreff: Re: Citadel Server sudden stop and restart fails with error DBD2055

 

Fr Apr 11 2025 13:22:11 UTC von IGnatius T Foobar Betreff: Re: Citadel Server sudden stop and restart fails with error DBD2055

these in the folder. Can this be related to database corruption or I/O
delays?

Yes, once the system has been running for a while it will clean up all log files that have been fully committed to the database. Usually this is rock solid so I'm wondering if you had a resource problem of some sort (disk full, etc)

Disk is not a problem, less than 50%. Did restored the DB again from backup. Server was running for a couple of hours after. Then this morning again sudden stopand down. The server was restarted automatically but the restarts then happen every couple of minutes. Restart count was eventually at 235. Up to restart 230 or so there was only one log.XXX file in the data folder, but then accumulated rapidly. Below is the last log files that caused the first automatic restart with error code 11. Interesting part is the message not found just before the crash, can this cause the issue? Or is this some sort of attack? Does any of this make sense?

Apr 13 10:55:14 [hostname] citserver[701535]: citserver[701535]: context: session 7508 (SMTP-MTA) ended.

Apr 13 10:55:14 [hostname] citserver[701535]: context: session 7508 (SMTP-MTA) ended.

Apr 13 10:55:16 [hostname] citserver[701535]: citserver[701535]: msgbase: message #93631 was not found

Apr 13 10:55:16 [hostname] citserver[701535]: msgbase: message #93631 was not found

Apr 13 10:55:16 [hostname] citserver[701535]: citserver[701535]: msgbase: message #93631 was not found

Apr 13 10:55:16 [hostname] citserver[701535]: msgbase: message #93631 was not found

Apr 13 10:55:21 [hostname] citserver[701535]: citserver[701535]: context: session (SMTP-MTA) started from 80.94.95.228 (80.94.95.228) uid=-1

Apr 13 10:55:21 [hostname] citserver[701535]: context: session (SMTP-MTA) started from 80.94.95.228 (80.94.95.228) uid=-1

Apr 13 10:55:22 [hostname] citserver[701535]: citserver[701535]: context: session (SMTP-MTA) started from 167.94.146.61 (167.94.146.61) uid=-1

Apr 13 10:55:22 [hostname] citserver[701535]: context: session (SMTP-MTA) started from 167.94.146.61 (167.94.146.61) uid=-1

Apr 13 10:55:22 [hostname] citserver[701535]: citserver[701535]: crypto: TLS using TLS_CHACHA20_POLY1305_SHA256 on TLSv1.3 (256 of 256 bits)

Apr 13 10:55:22 [hostname] citserver[701535]: crypto: TLS using TLS_CHACHA20_POLY1305_SHA256 on TLSv1.3 (256 of 256 bits)

Apr 13 10:55:22 [hostname] citserver[701535]: citserver[701535]: crypto: ending TLS on this session

Apr 13 10:55:22 [hostname] citserver[701535]: crypto: ending TLS on this session

Apr 13 10:55:22 [hostname] citserver[701535]: citserver[701535]: SMTP: client disconnected: ending session.

Apr 13 10:55:22 [hostname] citserver[701535]: citserver[701535]: context: session 7510 (SMTP-MTA) ended.

Apr 13 10:55:22 [hostname] citserver[701535]: SMTP: client disconnected: ending session.

Apr 13 10:55:22 [hostname] citserver[701535]: context: session 7510 (SMTP-MTA) ended.

Apr 13 10:55:26 [hostname] systemd[1]: citadel.service: Main process exited, code=killed, status=11/SEGV

Apr 13 10:55:26 [hostname] systemd[1]: citadel.service: Failed with result 'signal'.

Apr 13 10:55:27 [hostname] systemd[1]: citadel.service: Scheduled restart job, restart counter is at 1.

Apr 13 10:55:27 [hostname] systemd[1]: Stopped Citadel Server.

Apr 13 10:55:27 [hostname] systemd[1]: Started Citadel Server.

Apr 13 10:55:27 [hostname] citserver:

Apr 13 10:55:27 [hostname] citserver:

Apr 13 10:55:27 [hostname] citserver:*** Citadel server engine ***

Apr 13 10:55:27 [hostname] citserver:Version 998 (build 24041) ***

 

To add to this I further analysed the syslog and found that within 8 hours after the first crash there were three restarts after signal 11 (SEGV). After the third restart the fourth server crash was with signal 6 (ABRT) after DB runs out of lock entries:

Apr 13 18:23:03 [hostname] citserver[711154]: citserver[711154]: bdb: BDB2055 Lock table is out of available lock entries

Apr 13 18:23:03 [hostname] citserver[711154]: citserver[711154]: bdb: bdb_store(09): error 12: Cannot allocate memory

Apr 13 18:23:03 [hostname] citserver[711154]: bdb: BDB2055 Lock table is out of available lock entries

Apr 13 18:23:03 [hostname] citserver[711154]: bdb: bdb_store(09): error 12: Cannot allocate memory

Apr 13 18:23:03 [hostname] systemd[1]: citadel.service: Main process exited, code=killed, status=6/ABRT 

From there the server restarted and survived for about another 3 minutes accepting connections. Then restarted 231 times generating around 6.500 log files within 19 minutes.

Looks like one of the SEGV somehow corrupt or block the DB. The lock table issue is just the fallout. Is there a log where we can see what causes signal 11 (SEGV)?

So Apr 13 2025 17:20:30 UTC von p.agsten Betreff: Re: Citadel Server sudden stop and restart fails with error DBD2055

 

Fr Apr 11 2025 13:22:11 UTC von IGnatius T Foobar Betreff: Re: Citadel Server sudden stop and restart fails with error DBD2055

these in the folder. Can this be related to database corruption or I/O
delays?

Yes, once the system has been running for a while it will clean up all log files that have been fully committed to the database. Usually this is rock solid so I'm wondering if you had a resource problem of some sort (disk full, etc)

Disk is not a problem, less than 50%. Did restored the DB again from backup. Server was running for a couple of hours after. Then this morning again sudden stopand down. The server was restarted automatically but the restarts then happen every couple of minutes. Restart count was eventually at 235. Up to restart 230 or so there was only one log.XXX file in the data folder, but then accumulated rapidly. Below is the last log files that caused the first automatic restart with error code 11. Interesting part is the message not found just before the crash, can this cause the issue? Or is this some sort of attack? Does any of this make sense?

Apr 13 10:55:14 [hostname] citserver[701535]: citserver[701535]: context: session 7508 (SMTP-MTA) ended.

Apr 13 10:55:14 [hostname] citserver[701535]: context: session 7508 (SMTP-MTA) ended.

Apr 13 10:55:16 [hostname] citserver[701535]: citserver[701535]: msgbase: message #93631 was not found

Apr 13 10:55:16 [hostname] citserver[701535]: msgbase: message #93631 was not found

Apr 13 10:55:16 [hostname] citserver[701535]: citserver[701535]: msgbase: message #93631 was not found

Apr 13 10:55:16 [hostname] citserver[701535]: msgbase: message #93631 was not found

Apr 13 10:55:21 [hostname] citserver[701535]: citserver[701535]: context: session (SMTP-MTA) started from 80.94.95.228 (80.94.95.228) uid=-1

Apr 13 10:55:21 [hostname] citserver[701535]: context: session (SMTP-MTA) started from 80.94.95.228 (80.94.95.228) uid=-1

Apr 13 10:55:22 [hostname] citserver[701535]: citserver[701535]: context: session (SMTP-MTA) started from 167.94.146.61 (167.94.146.61) uid=-1

Apr 13 10:55:22 [hostname] citserver[701535]: context: session (SMTP-MTA) started from 167.94.146.61 (167.94.146.61) uid=-1

Apr 13 10:55:22 [hostname] citserver[701535]: citserver[701535]: crypto: TLS using TLS_CHACHA20_POLY1305_SHA256 on TLSv1.3 (256 of 256 bits)

Apr 13 10:55:22 [hostname] citserver[701535]: crypto: TLS using TLS_CHACHA20_POLY1305_SHA256 on TLSv1.3 (256 of 256 bits)

Apr 13 10:55:22 [hostname] citserver[701535]: citserver[701535]: crypto: ending TLS on this session

Apr 13 10:55:22 [hostname] citserver[701535]: crypto: ending TLS on this session

Apr 13 10:55:22 [hostname] citserver[701535]: citserver[701535]: SMTP: client disconnected: ending session.

Apr 13 10:55:22 [hostname] citserver[701535]: citserver[701535]: context: session 7510 (SMTP-MTA) ended.

Apr 13 10:55:22 [hostname] citserver[701535]: SMTP: client disconnected: ending session.

Apr 13 10:55:22 [hostname] citserver[701535]: context: session 7510 (SMTP-MTA) ended.

Apr 13 10:55:26 [hostname] systemd[1]: citadel.service: Main process exited, code=killed, status=11/SEGV

Apr 13 10:55:26 [hostname] systemd[1]: citadel.service: Failed with result 'signal'.

Apr 13 10:55:27 [hostname] systemd[1]: citadel.service: Scheduled restart job, restart counter is at 1.

Apr 13 10:55:27 [hostname] systemd[1]: Stopped Citadel Server.

Apr 13 10:55:27 [hostname] systemd[1]: Started Citadel Server.

Apr 13 10:55:27 [hostname] citserver:

Apr 13 10:55:27 [hostname] citserver:

Apr 13 10:55:27 [hostname] citserver:*** Citadel server engine ***

Apr 13 10:55:27 [hostname] citserver:Version 998 (build 24041) ***

Fr Apr 11 2025 13:22:11 UTC von IGnatius T Foobar Betreff: Re: Citadel Server sudden stop and restart fails with error DBD2055

these in the folder. Can this be related to database corruption or I/O
delays?

Yes, once the system has been running for a while it will clean up all log files that have been fully committed to the database. Usually this is rock solid so I'm wondering if you had a resource problem of some sort (disk full, etc)

Disk is not a problem, less than 50%. Did restored the DB again from backup. Server was running for a couple of hours after. Then this morning again sudden stopand down. The server was restarted automatically but the restarts then happen every couple of minutes. Restart count was eventually at 235. Up to restart 230 or so there was only one log.XXX file in the data folder, but then accumulated rapidly. Below is the last log files that caused the first automatic restart with error code 11. Interesting part is the message not found just before the crash, can this cause the issue? Or is this some sort of attack? Does any of this make sense?

Apr 13 10:55:14 [hostname] citserver[701535]: citserver[701535]: context: session 7508 (SMTP-MTA) ended.

Apr 13 10:55:14 [hostname] citserver[701535]: context: session 7508 (SMTP-MTA) ended.

Apr 13 10:55:16 [hostname] citserver[701535]: citserver[701535]: msgbase: message #93631 was not found

Apr 13 10:55:16 [hostname] citserver[701535]: msgbase: message #93631 was not found

Apr 13 10:55:16 [hostname] citserver[701535]: citserver[701535]: msgbase: message #93631 was not found

Apr 13 10:55:16 [hostname] citserver[701535]: msgbase: message #93631 was not found

Apr 13 10:55:21 [hostname] citserver[701535]: citserver[701535]: context: session (SMTP-MTA) started from 80.94.95.228 (80.94.95.228) uid=-1

Apr 13 10:55:21 [hostname] citserver[701535]: context: session (SMTP-MTA) started from 80.94.95.228 (80.94.95.228) uid=-1

Apr 13 10:55:22 [hostname] citserver[701535]: citserver[701535]: context: session (SMTP-MTA) started from 167.94.146.61 (167.94.146.61) uid=-1

Apr 13 10:55:22 [hostname] citserver[701535]: context: session (SMTP-MTA) started from 167.94.146.61 (167.94.146.61) uid=-1

Apr 13 10:55:22 [hostname] citserver[701535]: citserver[701535]: crypto: TLS using TLS_CHACHA20_POLY1305_SHA256 on TLSv1.3 (256 of 256 bits)

Apr 13 10:55:22 [hostname] citserver[701535]: crypto: TLS using TLS_CHACHA20_POLY1305_SHA256 on TLSv1.3 (256 of 256 bits)

Apr 13 10:55:22 [hostname] citserver[701535]: citserver[701535]: crypto: ending TLS on this session

Apr 13 10:55:22 [hostname] citserver[701535]: crypto: ending TLS on this session

Apr 13 10:55:22 [hostname] citserver[701535]: citserver[701535]: SMTP: client disconnected: ending session.

Apr 13 10:55:22 [hostname] citserver[701535]: citserver[701535]: context: session 7510 (SMTP-MTA) ended.

Apr 13 10:55:22 [hostname] citserver[701535]: SMTP: client disconnected: ending session.

Apr 13 10:55:22 [hostname] citserver[701535]: context: session 7510 (SMTP-MTA) ended.

Apr 13 10:55:26 [hostname] systemd[1]: citadel.service: Main process exited, code=killed, status=11/SEGV

Apr 13 10:55:26 [hostname] systemd[1]: citadel.service: Failed with result 'signal'.

Apr 13 10:55:27 [hostname] systemd[1]: citadel.service: Scheduled restart job, restart counter is at 1.

Apr 13 10:55:27 [hostname] systemd[1]: Stopped Citadel Server.

Apr 13 10:55:27 [hostname] systemd[1]: Started Citadel Server.

Apr 13 10:55:27 [hostname] citserver:

Apr 13 10:55:27 [hostname] citserver:

Apr 13 10:55:27 [hostname] citserver:*** Citadel server engine ***

Apr 13 10:55:27 [hostname] citserver:Version 998 (build 24041) ***