Language:
switch to room list switch to menu My folders
Go to page: First ... 8 9 10 11 [12] 13 14 15 16
[#] Mon Sep 15 2025 12:53:23 UTC from Motobike

Subject: Re: Concerning tha last two posts in Support Room.

[Reply] [ReplyQuoted] [Headers] [Print]

 

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
 


[#] Mon Sep 15 2025 14:38:05 UTC from alex007

Subject: Re: upgrade with easy install on raspberry pi os

[Reply] [ReplyQuoted] [Headers] [Print]

 

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.

 



 



[#] Mon Sep 15 2025 18:42:50 UTC from luisgo

Subject: Re: Concerning tha last two posts in Support Room.

[Reply] [ReplyQuoted] [Headers] [Print]

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
 


 



[#] Tue Sep 16 2025 03:34:19 UTC from IGnatius T Foobar

Subject: Re: upgrade with easy install on raspberry pi os

[Reply] [ReplyQuoted] [Headers] [Print]

Thank you IGnatius T Foobar,

compiling went well,now it runs on recent version.

Good to hear. In response to this I have removed the logic that attempts to figure out whether it can skip any recompile steps. Clearly there are now some interdependencies with system updates that can mess this up. And anyway, computers are generally much faster than they were when Easy Install was first written more than 20 years ago.

[#] Tue Sep 16 2025 03:36:14 UTC from IGnatius T Foobar

Subject: Re: Concerning tha last two posts in Support Room.

[Reply] [ReplyQuoted] [Headers] [Print]

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?

[#] Tue Sep 16 2025 13:58:28 UTC from luisgo

Subject: Re: Concerning tha last two posts in Support Room.

[Reply] [ReplyQuoted] [Headers] [Print]

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?

 



[#] Tue Sep 16 2025 14:22:31 UTC from Motobike

Subject: Re: Concerning tha last two posts in Support Room.

[Reply] [ReplyQuoted] [Headers] [Print]

 

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

 



[#] Wed Sep 17 2025 09:36:18 UTC from luisgo

Subject: Re: Concerning tha last two posts in Support Room.

[Reply] [ReplyQuoted] [Headers] [Print]

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

 



 



[#] Thu Sep 18 2025 03:21:40 UTC from luisgo

Subject: Another problem.

[Reply] [ReplyQuoted] [Headers] [Print]

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.

 



[#] Thu Sep 18 2025 06:27:08 UTC from Motobike

Subject: Re: Another problem.

[Reply] [ReplyQuoted] [Headers] [Print]

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.

 



 



[#] Thu Sep 18 2025 23:22:35 UTC from luisgo

Subject: Re: Another problem.

[Reply] [ReplyQuoted] [Headers] [Print]

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.

 



 



 



[#] Fri Sep 19 2025 03:34:46 UTC from IGnatius T Foobar

Subject: Re: Another problem.

[Reply] [ReplyQuoted] [Headers] [Print]

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

That error can appear if someone is attempting to connect to your encrypted ports without using SSL/TLS.

I've had that problem over here as well. My recommendation to you is that if you are not using the POP3S, IMAPS, etc. ports, set their port numbers to -1 to disable them.

[#] Fri Sep 19 2025 08:03:51 UTC from luisgo

Subject: Re: Concerning tha last two posts in Support Room.

[Reply] [ReplyQuoted] [Headers] [Print]

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

 



 



 



[#] Sat Sep 20 2025 18:08:00 UTC from IGnatius T Foobar

Subject: Re: Concerning tha last two posts in Support Room.

[Reply] [ReplyQuoted] [Headers] [Print]

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.



[#] Tue Sep 23 2025 06:41:37 UTC from kwadrat

Subject: Segmentation fault (core dumped)

[Reply] [ReplyQuoted] [Headers] [Print]

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.



[#] Tue Sep 23 2025 08:19:38 UTC from kwadrat

Subject: Re: Segmentation fault (core dumped)

[Reply] [ReplyQuoted] [Headers] [Print]

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.



 



[#] Tue Sep 23 2025 21:55:07 UTC from IGnatius T Foobar

Subject: Re: Segmentation fault (core dumped)

[Reply] [ReplyQuoted] [Headers] [Print]

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.



[#] Wed Sep 24 2025 10:46:26 UTC from kwadrat

Subject: Re: Segmentation fault (core dumped)

[Reply] [ReplyQuoted] [Headers] [Print]

I send you priv messages.

J.K.



[#] Mon Sep 29 2025 01:47:19 UTC from spareparts

Subject: Are modems still supported in Citadel?

[Reply] [ReplyQuoted] [Headers] [Print]

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

SP



[#] Mon Sep 29 2025 15:15:18 UTC from IGnatius T Foobar

Subject: Re: Are modems still supported in Citadel?

[Reply] [ReplyQuoted] [Headers] [Print]

Of course. It's always been easy. All you have to do is follow any available guide for setting up inbound dialup modems on Linux. Citadel is just another application running on it. If you want to bypass the system login prompt and send users straight to Citadel, you can configure your getty program to do that as well.

Go to page: First ... 8 9 10 11 [12] 13 14 15 16