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.

 

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.

 

 

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

 

 

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.

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.

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.

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.

I send you priv messages.

J.K.

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

SP

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.

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

Including citserver 

Centos 9, last version.

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.

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.

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:

next attempt to send have date "sty 01 1970". Server date is correct. Is this connected?

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:

How I can remove this from queue? Where is is coz it should be somewhere and can not find it.

J.K.

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