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ÝipÃ%`¶ôóÿ\177\000\000\000\236ÝipÃ%ÿ\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ÝipÃ%\001\200û!\000\000\000`¶ôóÿ\177\000\000@\023Á÷ÿ\177\000\000`¶ôóÿ\177\000\000`¶ôóÿ\177\000\000\212¶ôóÿ\177\000\000_ºôóÿ\177\000\000¿bÀ÷ÿ\177\000\000\020\000\000\000ÿ\177\000\000"...
rc = 0
#4 0x000055555559c322 in cmd_mesg (mname=0x7ffff3f4bb95 "hello") at server/modules/ctdlproto/serv_file.c:551
mfp = 0x0
targ = "messages/hello\000\000P¹ôóÿ\177\000\000\000\236ÝipÃ%\000\000\000\000\000\000\000\000\000\001\000\000\000\000\000\000\220Ò\000äÿ\177\000\000àŒ\000äÿ\177\000\000\000\000\000\000\000\000\000\000Ðq\001ìÿ\177\000\000ÀÏ\000äÿ\177\000\000¿bÀ÷ÿ\177\000\000\020\000\000\000ÿ\177\000\000ð¹ôóÿ\177\000\000°¹ôóÿ\177\000\000\000\236Ýi_\000\000\000\060\032\000äÿ\177\000\000î_Â÷ÿ\177", '\000' <repeats 18 times>, "k\027\000äÿ\177", '\000' <repeats 18 times>, "z¹Â÷ÿ\177", '\000' <repeats 18 times>...
buf = "hello\000\000\000\060\060\000äÿ\177\000\000\000\000\000\000\000\000\000\000ìFÂ÷ÿ\177\000\000\000\000\000\000\000\000\000\000âEÂ÷ÿ\177\000\000ÙhlUUU\000\000\000\236ÝipÃ%", '\000' <repeats 16 times>, "°Ëôóÿ\177\000\000ÎÓÿÿÿ\177\000\000ÏÓÿÿÿ\177\000\000pÔÿÿÿ\177\000\000\200Íôóÿ\177\000\000ªä\226÷ÿ\177\000\000\020\000\000\000\060\000\000\000\220»ôóÿ\177\000\000кôóÿ\177\000\000\000\236ÝipÃ%P»ôóÿ\177\000\000ØÒ\000äÿ\177\000\000üÒ\000äÿ\177\000\000\000\000\000\000\000\000\000\000\220»ôóÿ\177\000\000"...
dp = 0x7
d = 0x7fffe40008d0
#5 0x000055555558c4ad in DLoader_Exec_Cmd (cmdbuf=0x7ffff3f4bb90 "MESG hello") at server/serv_extensions.c:219
vP = 0x555555782ee0
p = 0x555555782ee0
#6 0x0000555555592582 in do_command_loop () at server/modules/ctdlproto/serv_ctdlproto.c:64
cmdbuf = "MESG hello", '\000' <repeats 4085 times>
#7 0x00005555555824e1 in worker_thread (blah=0x0) at server/sysdep.c:937
sockets_waiting = 1
highest = 37
ptr = 0x0
worker_session = 0x7fffe400d230
readfds = {__fds_bits = {137438953472, 0 <repeats 15 times>}}
tv = {tv_sec = 0, tv_usec = 999997}
force_purge = 0
serviceptr = 0x0
ssock = 37
con = 0x7fffe400d230
i = 1
#8 0x00007ffff7bfb609 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
No symbol table info available.
#9 0x00007ffff7975353 in clone () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
Thread 2 (Thread 0x7ffff474e700 (LWP 18941)):
#0 0x00007ffff796b1eb in select () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#1 0x0000555555581fe4 in worker_thread (blah=0x0) at server/sysdep.c:817
sockets_waiting = 0
highest = 36
ptr = 0x0
worker_session = 0x0
readfds = {__fds_bits = {137422176256, 0 <repeats 15 times>}}
tv = {tv_sec = 0, tv_usec = 998444}
force_purge = 0
serviceptr = 0x0
ssock = 37
con = 0x7fffec037090
i = 1
#2 0x00007ffff7bfb609 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
No symbol table info available.
#3 0x00007ffff7975353 in clone () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
Thread 1 (Thread 0x7ffff4915980 (LWP 18936)):
#0 0x00007ffff793323f in clock_nanosleep () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#1 0x00007ffff7938ec7 in nanosleep () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#2 0x00007ffff796ba7f in usleep () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#3 0x0000555555582afc in go_threading () at server/threads.c:142
No locals.
#4 0x0000555555572c24 in main (argc=1, argv=0x7fffffffe678) at server/server_main.c:308
facility = " M\000\000\000\000\000\000 ]\000\000\000\000\000\000 ]\000\000\000\000\000\000à\002\000\000\000\000\000"
pw = {pw_name = 0x7fffffffd560 "citadel", pw_passwd = 0x7fffffffd568 "x", pw_uid = 1001, pw_gid = 1002, pw_gecos = 0x7fffffffd574 "Citadel service account", pw_dir = 0x7fffffffd58c "/usr/local/citadel", pw_shell = 0x7fffffffd59f "/usr/local/citadel/citadel"}
pwp = 0x7fffffffd510
pwbuf = "citadel\000x\000\061\060\060\061:1002:Citadel service account\000/usr/local/citadel\000/usr/local/citadel/citadel\000\000\000\026\000\000\000\b\000\000\000\t\000\000\000\000\000\000\200\000\020@\002\001\000\202\022\004\004@\000\200\000@\b\000\000@\000\b\000\000\b8@\002 Z\210\201\a\004\002\220\022\bá¿\030\000à\002YÐÞÿÿÿ\177\000\000@ãÿÿÿ\177", '\000' <repeats 11 times>, "\060\222ôÿ\177\000\000\212Ï\221ôÿ\177\000\000\000\000\000\000\000\000\000\000"...
drop_root_perms = 1
max_log_level = 6
ctdldir = 0x5555556c1b41 "/usr/local/citadel"
syslog_facility = 24
u = 1001
p = 0x7ffff7a45460
g = -1
Subject: Re: Initial web access pops 503 error.
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?
Subject: Re: Initial web access pops 503 error.
It's a weird one because nothing unusual is happening here, it's just trying to display the site's greeting banner (hello).
What is the contents of ./messages/hello ? Is it there? Is it corrupted?
Subject: Re: Initial web access pops 503 error.
Ok, I'm really struggling with this one because it's crashing while doing something very clean and simple, which may suggest a problem elsewhere.
I've added a few more diagnostics to that area of the system. Also it will now print a simple stack trace to the syslog at the moment it crashes. Please upgrade to version 1013 and see if the behavior changes any.
Also if you find you need to run it in the debugger, the command to produce the output we need is "thread apply all bt" after it crashes.
I am running on Debian Bullseye/Sid.
As far as the messages folder... It's empty, I'm guessing that's not right.
I reloaded with Easyinstall and apparently it's still listing the server version as 1011. Very odd though, the server stayed up for hours without a problem until I opened Webcit in my browser, which came up to my personal mail room and then errored saying it couldn't stay connected to the Citadel server. Of course checking the logs immediately showed a citserver crash. I've listed the stack trace from the logs and the surrounding logs below:
May 23 20:25:08 nadia webcit[615]: webcit[615]: SSL_accept (sock=5) success, usi
ng TLS_AES_128_GCM_SHA256 on TLSv1.3 (128 of 128 bits)
May 23 20:25:08 nadia webcit[615]: SSL_accept (sock=5) success, using TLS_AES_12
8_GCM_SHA256 on TLSv1.3 (128 of 128 bits)
May 23 20:25:08 nadia webcit[615]: webcit[615]: Ending SSL/TLS
May 23 20:25:08 nadia webcit[615]: Ending SSL/TLS
May 23 20:25:08 nadia webcit[615]: webcit[615]: SSL_accept (sock=13) success, us
ing TLS_AES_128_GCM_SHA256 on TLSv1.3 (128 of 128 bits)
May 23 20:25:08 nadia webcit[615]: webcit[615]: SSL_accept (sock=8) success, usi
ng TLS_AES_128_GCM_SHA256 on TLSv1.3 (128 of 128 bits)
May 23 20:25:08 nadia webcit[615]: SSL_accept (sock=13) success, using TLS_AES_1
28_GCM_SHA256 on TLSv1.3 (128 of 128 bits)
May 23 20:25:08 nadia webcit[615]: SSL_accept (sock=8) success, using TLS_AES_12
8_GCM_SHA256 on TLSv1.3 (128 of 128 bits)
May 23 20:25:08 nadia webcit[615]: webcit[615]: SSL_accept (sock=6) success, usi
ng TLS_AES_128_GCM_SHA256 on TLSv1.3 (128 of 128 bits)
May 23 20:25:08 nadia webcit[615]: webcit[615]: SSL_accept (sock=6) success, usi
ng TLS_AES_128_GCM_SHA256 on TLSv1.3 (128 of 128 bits)
May 23 20:25:08 nadia webcit[615]: SSL_accept (sock=6) success, using TLS_AES_12
8_GCM_SHA256 on TLSv1.3 (128 of 128 bits)
May 23 20:25:08 nadia citserver[9135]: citserver[9135]: SIGSEGV received in thre
ad 140169230857984 at address 0xb79be820
May 23 20:25:08 nadia citserver[9135]: SIGSEGV received in thread 14016923085798
4 at address 0xb79be820
May 23 20:25:08 nadia webcit[615]: webcit[615]: Ending SSL/TLS
May 23 20:25:08 nadia webcit[615]: Ending SSL/TLS
May 23 20:25:08 nadia webcit[615]: webcit[615]: Ending SSL/TLS
May 23 20:25:08 nadia webcit[615]: Ending SSL/TLS
May 23 20:25:08 nadia webcit[615]: webcit[615]: SSL_accept (sock=9) success, usi
ng TLS_AES_128_GCM_SHA256 on TLSv1.3 (128 of 128 bits)
May 23 20:25:08 nadia webcit[615]: webcit[615]: SSL_accept (sock=10) success, us
ing TLS_AES_128_GCM_SHA256 on TLSv1.3 (128 of 128 bits)
May 23 20:25:08 nadia webcit[615]: SSL_accept (sock=10) success, using TLS_AES_1
28_GCM_SHA256 on TLSv1.3 (128 of 128 bits)
May 23 20:25:08 nadia webcit[615]: SSL_accept (sock=9) success, using TLS_AES_12
8_GCM_SHA256 on TLSv1.3 (128 of 128 bits)
May 23 20:25:08 nadia webcit[615]: webcit[615]: Ending SSL/TLS
May 23 20:25:08 nadia webcit[615]: webcit[615]: Ending SSL/TLS
May 23 20:25:08 nadia webcit[615]: Ending SSL/TLS
May 23 20:25:08 nadia webcit[615]: Ending SSL/TLS
May 23 20:25:08 nadia citserver[9135]: citserver[9135]: Stack frame #0: /usr/loc
al/citadel/citserver(+0x36f0a) [0x55c470fbaf0a]
May 23 20:25:08 nadia citserver[9135]: Stack frame #0: /usr/local/citadel/citser
ver(+0x36f0a) [0x55c470fbaf0a]
May 23 20:25:08 nadia citserver[9135]: citserver[9135]: Stack frame #1: /lib/x86
_64-linux-gnu/libpthread.so.0(+0x14420) [0x7f7bb7bbb420]
May 23 20:25:08 nadia citserver[9135]: Stack frame #1: /lib/x86_64-linux-gnu/lib
pthread.so.0(+0x14420) [0x7f7bb7bbb420]
May 23 20:25:08 nadia citserver[9135]: citserver[9135]: Stack frame #2: /lib/x86
_64-linux-gnu/libc.so.6(+0x188947) [0x7f7bb7992947]
May 23 20:25:08 nadia citserver[9135]: Stack frame #2: /lib/x86_64-linux-gnu/lib
c.so.6(+0x188947) [0x7f7bb7992947]
May 23 20:25:08 nadia citserver[9135]: citserver[9135]: Stack frame #3: /lib/x86
_64-linux-gnu/libc.so.6(+0x78d15) [0x7f7bb7882d15]
May 23 20:25:08 nadia citserver[9135]: Stack frame #3: /lib/x86_64-linux-gnu/lib
c.so.6(+0x78d15) [0x7f7bb7882d15]
May 23 20:25:08 nadia citserver[9135]: citserver[9135]: Stack frame #4: /lib/x86
_64-linux-gnu/libc.so.6(+0x8bf9a) [0x7f7bb7895f9a]
May 23 20:25:08 nadia citserver[9135]: Stack frame #4: /lib/x86_64-linux-gnu/lib
c.so.6(+0x8bf9a) [0x7f7bb7895f9a]
May 23 20:25:08 nadia citserver[9135]: citserver[9135]: Stack frame #5: /usr/loc
al/citadel/citserver(+0x1d0a1) [0x55c470fa10a1]
May 23 20:25:08 nadia citserver[9135]: Stack frame #5: /usr/local/citadel/citser
ver(+0x1d0a1) [0x55c470fa10a1]
May 23 20:25:08 nadia citserver[9135]: citserver[9135]: Stack frame #6: /usr/loc
al/citadel/citserver(+0x473c9) [0x55c470fcb3c9]
May 23 20:25:08 nadia citserver[9135]: Stack frame #6: /usr/local/citadel/citser
ver(+0x473c9) [0x55c470fcb3c9]
May 23 20:25:08 nadia citserver[9135]: citserver[9135]: Stack frame #7: /usr/loc
al/citadel/citserver(+0x3876e) [0x55c470fbc76e]
May 23 20:25:08 nadia citserver[9135]: citserver[9135]: Stack frame #8: /usr/loc
al/citadel/citserver(+0x3e843) [0x55c470fc2843]
May 23 20:25:08 nadia citserver[9135]: citserver[9135]: Stack frame #9: /usr/loc
al/citadel/citserver(+0x3810f) [0x55c470fbc10f]
May 23 20:25:08 nadia citserver[9135]: citserver[9135]: Stack frame #10: /lib/x8
6_64-linux-gnu/libpthread.so.0(+0x8609) [0x7f7bb7baf609]
May 23 20:25:08 nadia citserver[9135]: citserver[9135]: Stack frame #11: /lib/x8
6_64-linux-gnu/libc.so.6(clone+0x43) [0x7f7bb7929353]
May 23 20:25:08 nadia citserver[9135]: Stack frame #7: /usr/local/citadel/citser
ver(+0x3876e) [0x55c470fbc76e]
May 23 20:25:08 nadia citserver[9135]: Stack frame #8: /usr/local/citadel/citser
ver(+0x3e843) [0x55c470fc2843]
May 23 20:25:08 nadia citserver[9135]: Stack frame #9: /usr/local/citadel/citser
ver(+0x3810f) [0x55c470fbc10f]
May 23 20:25:08 nadia citserver[9135]: Stack frame #10: /lib/x86_64-linux-gnu/li
bpthread.so.0(+0x8609) [0x7f7bb7baf609]
May 23 20:25:08 nadia citserver[9135]: Stack frame #11: /lib/x86_64-linux-gnu/li
bc.so.6(clone+0x43) [0x7f7bb7929353]
May 23 20:25:08 nadia webcit[615]: webcit[615]: StrBuf_ServGetln(): Server conne
ction broken: Success
May 23 20:25:08 nadia webcit[615]: StrBuf_ServGetln(): Server connection broken:
Success
May 23 20:25:08 nadia webcit[615]: webcit[615]: HTTP: 200 [0.171787] GET /image?
name=hello
May 23 20:25:08 nadia webcit[615]: webcit[615]: Ending SSL/TLS
May 23 20:25:08 nadia webcit[615]: HTTP: 200 [0.171787] GET /image?name=hello
May 23 20:25:08 nadia webcit[615]: Ending SSL/TLS
May 23 20:25:08 nadia systemd[1]: citadel.service: Main process exited, code=kil
led, status=11/SEGV
May 23 20:25:08 nadia systemd[1]: citadel.service: Failed with result 'signal'.
May 23 20:25:09 nadia webcit[615]: webcit[615]: SSL_accept (sock=7) success, usi
ng TLS_AES_128_GCM_SHA256 on TLSv1.3 (128 of 128 bits)
May 23 20:25:09 nadia webcit[615]: SSL_accept (sock=7) success, using TLS_AES_12
8_GCM_SHA256 on TLSv1.3 (128 of 128 bits)
May 23 20:25:09 nadia webcit[615]: webcit[615]: Ending SSL/TLS
May 23 20:25:09 nadia webcit[615]: Ending SSL/TLS
May 23 20:25:09 nadia webcit[615]: webcit[615]: SSL_accept (sock=10) success, us
ing TLS_AES_128_GCM_SHA256 on TLSv1.3 (128 of 128 bits)
May 23 20:25:09 nadia webcit[615]: webcit[615]: SSL_accept (sock=9) success, usi
ng TLS_AES_128_GCM_SHA256 on TLSv1.3 (128 of 128 bits)
May 23 20:25:09 nadia webcit[615]: SSL_accept (sock=10) success, using TLS_AES_1
28_GCM_SHA256 on TLSv1.3 (128 of 128 bits)
May 23 20:25:09 nadia webcit[615]: SSL_accept (sock=9) success, using TLS_AES_12
8_GCM_SHA256 on TLSv1.3 (128 of 128 bits)
May 23 20:25:09 nadia webcit[615]: webcit[615]: Ending SSL/TLS
May 23 20:25:09 nadia webcit[615]: webcit[615]: Ending SSL/TLS
May 23 20:25:09 nadia webcit[615]: Ending SSL/TLS
May 23 20:25:09 nadia webcit[615]: Ending SSL/TLS
May 23 20:25:09 nadia systemd[1]: citadel.service: Scheduled restart job, restar
t counter is at 2.
May 23 20:25:09 nadia systemd[1]: Stopped Citadel Server.
Citserver has not crashed since my last message after installing the newer version, even with Webcit up. Not sure what changed.
Subject: Re: Initial web access pops 503 error.
The upgrade to 1103 worked for me.
Thanks
Subject: Re: Initial web access pops 503 error.
I use Citadel as a container.
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
0abf2ea2b684 citadeldotorg/citadel "/usr/local/bin/ctdl…" 4 months ago Up 2 hours citadel
I'm unsure how it happened, and unfortunately, I'm unable to provide you with an explanatory log. Last night, inbox rules suddenly stopped working for all defined users. The log for the last processed inbox rule is below. No rules have worked for 7 hours. No changes have been made to Citadel.
Is there anything you can direct me to? Thank you very much in advance for your valuable help.
{"log":"citserver[7]: inbox_do_msg: stop processing\n","stream":"stderr","time":"2025-06-19T07:02:51.33862326Z"}
{"log":"citserver[7]: inbox_do_msg: delete 8693757 from inbox\n","stream":"stderr","time":"2025-06-19T07:02:51.338935481Z"}
{"log":"citserver[7]: msgbase: CtdlDeleteMessages(0000000050.Mail, 1 msgs, )\n","stream":"stderr","time":"2025-06-19T07:02:51.338969635Z"}
{"log":"citserver[7]: msgbase: AdjRefCount() msg 8693757 ref count delta -1, is now 0\n","stream":"stderr","time":"2025-06-19T07:02:51.339721978Z"}
{"log":"citserver[7]: msgbase: deleting message \u003c8693757\u003e\n","stream":"stderr","time":"2025-06-19T07:02:51.339749945Z"}
{"log":"citserver[7]: msgbase: 1 message(s) deleted\n","stream":"stderr","time":"2025-06-19T07:02:51.342082159Z"}
{"log":"citserver[7]: user_ops: 185 maps to ****-vipsupport.inr01\n","stream":"stderr","time":"2025-06-19T07:02:51.342455597Z"}
{"log":"citserver[7]: user_ops: 74 maps to *****-inrkyc\n","stream":"stderr","time":"2025-06-19T07:02:51.342626661Z"}
{"log":"citserver[7]: msgbase: CtdlFetchMessage(373, 1)\n","stream":"stderr","time":"2025-06-19T07:02:51.34264403Z"}
{"log":"citserver[7]: do_inbox_processing_for_user: for ****-inrkyc, messages newer than 8681597\n","stream":"stderr","time":"2025-06-19T07:02:51.342941165Z"}
{"log":"citserver[7]: pop3: NOOP\n","stream":"stderr","time":"2025-06-19T07:02:51.34296413Z"}
{"log":"citserver[7]: inbox_do_msg: processing message #8694707 which is higher than 8681597, we are in 0000000074.Mail\n","stream":"stderr","time":"2025-06-19T07:02:51.342970663Z"}
{"log":"citserver[7]: inbox_do_msg: processing rule: 0 , field: all\n","stream":"stderr","time":"2025-06-19T07:02:51.342975083Z"}
{"log":"citserver[7]: inbox_do_msg: this is an always-on rule\n","stream":"stderr","time":"2025-06-19T07:02:51.342979319Z"}
{"log":"citserver[7]: inbox_do_msg: rule activated\n","stream":"stderr","time":"2025-06-19T07:02:51.342983816Z"}
{"log":"citserver[7]: internet_addressing: directory key is \u003cnifi03@****.com\u003e\n","stream":"stderr","time":"2025-06-19T07:02:51.34344315Z"}
{"log":"citserver[7]: internet_addressing: directory alias \u003cnifi03@****.com\u003e to \u003c****-nifi03\u003e\n","stream":"stderr","time":"2025-06-19T07:02:51.343472501Z"}
{"log":"citserver[7]: Recipient #0 of type 2 is \u003c***-nifi03\u003e\n","stream":"stderr","time":"2025-06-19T07:02:51.343489341Z"}
{"log":"citserver[7]: internet_addressing: validate_recipients() = 1 local, 0 room, 0 SMTP, 0 error\n","stream":"stderr","time":"2025-06-19T07:02:51.343514387Z"}
{"log":"citserver[7]: msgbase: CtdlFetchMessage(8694707, 1)\n","stream":"stderr","time":"2025-06-19T07:02:51.343523033Z"}
Subject: Re: Inbox rules stop working suddenly
I'm unsure how it happened, and unfortunately, I'm unable to provide
you with an explanatory log. Last night, inbox rules suddenly stopped
working for all defined users. The log for the last processed inbox
rule is below. No rules have worked for 7 hours. No changes have been
made to Citadel.
First things first: are the rules failing to run and all mail goes to inbox without processing, or has mail delivery stopped entirely?
Those are good logs by the way, how did you get them exported from the container?
Hello,
I've managed to connect thunderbird to the calender, using the documented URL: http://<server>/groupdav/calendar/calendar.ics
However, I am struggeling to find a corresponding url for the contacts
/groupdav/Contacts/ does not work, thunderbird does ask for the password, but afterwards reports a "failed to connect" error, when trying to add a caldav addressbook. Contrary to what I could find, it does not matter, wether I provide the port with the server address or not. Also a newly created address room cannot be found
For news, thunderbird reports, it has connected to the news server, but it does not find any groups to possibly subscribe to.
Since there is no dedicated news option for new rooms, I would have expected the public rooms to be available. At least those, that have been created by that particular user. Or how would I create a news group, in case this is the more appropiate question
Thanks
Another beginners question: Is there a way to use the text mode client when running the docker image? The client itself is part of the image, but so far there seems to be no way of remotely accessing it.Well, besides "podman exec -it citadel /usr/local/bin/citadel". Obviously not a feasible option.
Neither telnet nor ssh seem to be installed and I am not aware of any remote text client. Hopefully I am just missing the last one?
Has anyone tried this yet? Any hints I might have missed in the documentation?
Thanks
First of all, thank you very much for your answer. I found the source of the problem and prevented it from recurring. Whatever the PutEmail function used by the Apache NiFi application to send mail was doing, it was avoiding the message processing ID from being added to new messages. You can print the debug log with the "-X 9" parameter when starting the container to get the logs. The emails were falling into the Inbox without any rules working. Sending and receiving mail was working normally. Only the Inbox rules were not working.
Hi!
I use Citadel 2 years ago, but recently, I can't send emails to mailboxes hosted on O2Switch (error 421 with no further explanation).
I can communicate with any mailbox on any host (GMail, Outlook, Orange, etc.) but not with them (I can receive emails from them from two domains hosted with them, but not vice versa).
And for their part, they have no problem communicating with anyone...
Could someone help me? Because this type of problem is really stumping me...
Thanks in advance
Hello!
But recently, I can't send emails to mailboxes hosted on O2Switch (error 421 with no further explanation).
I can communicate with any mailbox on any host (GMail, Outlook, Orange, etc.) but not with them (I can receive emails from them from two domains hosted with them, but not vice versa).
And for their part, they have no problem communicating with anyone, and don't see any SMTP connections...
Could someone help me? Because this type of problem is really stumping me...
Thanks in advance
Hello!
But recently, I can't send emails to mailboxes hosted on O2Switch (error 421 with no further explanation).
I can communicate with any mailbox on any host (GMail, Outlook, Orange, etc.) but not with them (I can receive emails from them from two domains hosted with them, but not vice versa).
And for their part, they have no problem communicating with anyone, and don't see any SMTP connections...
Could someone help me? Because this type of problem is really stumping me...
Thanks in advance
Another beginners question: Is there a way to use the text mode client
when running the docker image? The client itself is part of the image,
but so far there seems to be no way of remotely accessing it.Well,
besides "podman exec -it citadel /usr/local/bin/citadel". Obviously not
a feasible option.
This is definitely a tricky one, and something that I had to kind of hack together when I moved this system to the containerized version of Citadel.
I ended up just copying "citadel" and "libcitadel.so.4..." and "citadel.rc" into the host system and running it from there.
No doubt this is a hacky solution and one that we intend to solve a more elegant way in the future.
Subject: Re: URLs for external clients for contacts & news
However, I am struggeling to find a corresponding url for the contacts
Does the Thunderbird client support accessing the contacts list in that way?
To the best of my knowledge it does not.
When you connect Thunderbird to the Citadel calendar you're basically accessing the calendar "as a whole" which is to say, it downloads the whole calendar, then when you make changes it reuploads the whole calendar.
Thunderbird also supports CalDAV and probably CardDAV, which will be fully supported in the not-yet-released WebCit-NG, but unfortunately the current version does not support those protocols.