Language:
switch to room list switch to menu My folders
Go to page: First ... 9 10 11 12 [13] 14 15 16 17 ... Last
[#] Sun Feb 12 2017 23:26:58 EST from IGnatius T Foobar @ Uncensored

Subject: Re: Error configuring citadel suite.

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

Under Ubuntu, you should build it using the EasyInstall script and not

from packages. The only distro I was ever able to get distro-specific

packaging to work was under Red Hat Enterprise 7.3, which is what I run

my Citadel system under.

What I'm starting to see here is that maybe we should provide some sort of way to move from the packages to Easy Install and vice versa.

[#] Mon Feb 13 2017 10:07:33 EST from bennabiy @ Uncensored

Subject: Re: Citadel misplacing messages and more

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

If you jump into the IRC channel, I am there, and can probably respond faster than checking back here every so often. (*or if you have another preferred method of communication*).

 

Thank you.

Sun Feb 12 2017 23:25:14 EST from IGnatius T Foobar @ Uncensored Subject: Re: Citadel misplacing messages and more
Bennabiy: thanks for describing your issues so clearly. I've copied your message to my desktop and we'll look at the issues one by one.

 



[#] Mon Feb 13 2017 10:14:25 EST from bennabiy @ Uncensored

Subject: Re: Error configuring citadel suite.

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

There could be a way to have some file (maybe in /etc) where you could store the type of install done, and have a script which would do the migration from one to the other (could even be a simple Makefile with the locations for Easy Install and the major distro locations (Deb/Ubuntu, RHEL et all) I think the configs are pretty much in the same place on other distros as one of those (not saying for sure though, as I do not run Gentoo or Arch or ...) and a simple easy2apt , easy2yum or yum2easy , apt2easy etc.

 

 

Sun Feb 12 2017 23:26:58 EST from IGnatius T Foobar @ Uncensored Subject: Re: Error configuring citadel suite.
Under Ubuntu, you should build it using the EasyInstall script and not

from packages. The only distro I was ever able to get distro-specific

packaging to work was under Red Hat Enterprise 7.3, which is what I run

my Citadel system under.

What I'm starting to see here is that maybe we should provide some sort of way to move from the packages to Easy Install and vice versa.

 



[#] Tue Feb 14 2017 09:02:30 EST from bennabiy @ Uncensored

Subject: Citserver stops responding

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

I have a situation where the citserver stops responding to requests but does not deny connections (SSL/TLS handshake error in IMAP client, blank screen if nc localhost 504)

If I kill the process, the daemon restarts and then all is fine. It seems to happen every day or every other day in the morning. I cannot seem to get it to produce a log file of what is happening.



[#] Tue Feb 14 2017 09:53:10 EST from IGnatius T Foobar @ Uncensored

Subject: Re: Citserver stops responding

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

That's kind of odd, but if you can get a backtrace in gdb we can figure out where it's stuck.

[#] Tue Feb 14 2017 09:57:37 EST from hidifly @ Uncensored

Subject: Mass deleting spam messages

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

I've had an issue where a user has been spamming other users with offensive emails. The user has been dealt with but now the system is full of these posts (in other users inboxes etc.) I would like to do some kind of mass delete. I haven't deleted the user yet since there may be a way to "remove user and all messages" function. But I'm not sure. What is the best way to handle that situation?



[#] Tue Feb 14 2017 10:47:35 EST from the_mgt @ Uncensored

Subject: Re: Error configuring citadel suite.

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

 

Mon Feb 13 2017 10:14:25 EST from bennabiy @ Uncensored Subject: Re: Error configuring citadel suite.

There could be a way to have some file (maybe in /etc) where you could store the type of install done, and have a script which would do the migration from one to the other (could even be a simple Makefile with the locations for Easy Install and the major distro locations (Deb/Ubuntu, RHEL et all) I think the configs are pretty much in the same place on other distros as one of those (not saying for sure though, as I do not run Gentoo or Arch or ...) and a simple easy2apt , easy2yum or yum2easy , apt2easy etc.

Well, everything in /etc is considered a config file which can and probably will be manipulated by the owner of the system. /usr/share/ would be the proper location, imho. But the point of easy install is to have everything in /usr/local or some other place.

 

My idea would be: the "how I was installed" file should live where the db lives. And when you fire any migration script, it needs to know where the db is located anyway. And it should contain a "automatically generated, no trespassing!" note....

Also, for maintenablitly, it should be dist2easy and easy2dist. It is still maintenance hell, I once wrote a generic install script for Retroshare, with distro guessing, etc.



[#] Tue Feb 14 2017 11:28:02 EST from bennabiy @ Uncensored

Subject: Re: Citserver stops responding

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

How would you recommend starting citserver to try to capture it? It is not something I can duplicate except by waiting...

Tue Feb 14 2017 09:53:10 EST from IGnatius T Foobar @ Uncensored Subject: Re: Citserver stops responding
That's kind of odd, but if you can get a backtrace in gdb we can figure out where it's stuck.

 



[#] Tue Feb 14 2017 11:30:24 EST from bennabiy @ Uncensored

Subject: Re: Error configuring citadel suite.

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

What about the system where someone did both, and has two instances running?

Tue Feb 14 2017 10:47:35 EST from the_mgt @ Uncensored Subject: Re: Error configuring citadel suite.

 

Mon Feb 13 2017 10:14:25 EST from bennabiy @ Uncensored Subject: Re: Error configuring citadel suite.

There could be a way to have some file (maybe in /etc) where you could store the type of install done, and have a script which would do the migration from one to the other (could even be a simple Makefile with the locations for Easy Install and the major distro locations (Deb/Ubuntu, RHEL et all) I think the configs are pretty much in the same place on other distros as one of those (not saying for sure though, as I do not run Gentoo or Arch or ...) and a simple easy2apt , easy2yum or yum2easy , apt2easy etc.

Well, everything in /etc is considered a config file which can and probably will be manipulated by the owner of the system. /usr/share/ would be the proper location, imho. But the point of easy install is to have everything in /usr/local or some other place.

 

My idea would be: the "how I was installed" file should live where the db lives. And when you fire any migration script, it needs to know where the db is located anyway. And it should contain a "automatically generated, no trespassing!" note....

Also, for maintenablitly, it should be dist2easy and easy2dist. It is still maintenance hell, I once wrote a generic install script for Retroshare, with distro guessing, etc.



 



[#] Tue Feb 14 2017 11:39:31 EST from the_mgt @ Uncensored

Subject: Re: Error configuring citadel suite.

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

 

Tue Feb 14 2017 11:30:24 ESTfrom bennabiy @ Uncensored Subject: Re: Error configuring citadel suite.

What about the system where someone did both, and has two instances running?

Those people do not need a nanny script.

We only need to care about what my psychologist friends call "differentiation in the lower competence stratum"...



[#] Tue Feb 14 2017 18:46:08 EST from IGnatius T Foobar @ Uncensored

Subject: Re: Citserver stops responding

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

Tue Feb 14 2017 11:28:02 AM EST from bennabiy @ Uncensored Subject: Re: Citserver stops responding

How would you recommend starting citserver to try to capture it? It is not something I can duplicate except by waiting...

Well, there are a couple of ways.  You can either start citserver from inside the debugger, or you can try to get a core dump.  If your problem is occurring on a predictable daily basis, you're probably better off starting with the debugger.  Stop citserver and then start it like this:

cd /usr/local/citadel

gdb ./citserver

(gdb) run

Citadel Server will run in the foreground.  When you have the problem where it gets stuck, press Ctrl-C.  You will get some diagnostics and a new gdb prompt.  At that point you have to get the stack traces for every thread:

(gdb) thread apply all bt

Most of your threads will be blocked on select() , those are idle threads.  If the server is truly stuck, there will be at least one thread doing something unusual.  Where it is will tell us what's stuck.



[#] Tue Feb 14 2017 18:52:55 EST from IGnatius T Foobar @ Uncensored

Subject: Re: Error configuring citadel suite.

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

My idea would be: the "how I was installed" file should live where the db lives. And when you fire any migration script, it needs to know where the db is located anyway. And it should contain a "automatically generated, no trespassing!" note....

Also, for maintenablitly, it should be dist2easy and easy2dist. It is still maintenance hell, I once wrote a generic install script for Retroshare, with distro guessing, etc.

To be honest, I don't have a lot of interest in going from Easy Install back to the distribution packages.  Once a site is running Easy Install, they've already satisfied the dependencies and have gotten their system into a state where they will always be able to pull down the latest-and-greatest version directly from the Citadel project.  Why would they ever go back?

What I'm thinking of doing is just adding some code to Easy Install that, if it doesn't find a Citadel installation in /usr/local/citadel, also looks for a Citadel installation in the FSSTND directories.  If it finds one, it can offer a prompt something like this:

Easy Install has found an existing Citadel installation in /var/lib/citadel.
Please select what you wish to do:
1) Move this data to /usr/local/citadel and run an Easy Install upgrade.
2) Copy this data to /usr/local/citadel and run an Easy Install upgrade.
3) Ignore this data and perform a new Citadel installation in /usr/local/citadel. 

We'll get the usual complaints from people who didn't RTFM and didn't take a backup, but those people can die in a car fire.



[#] Wed Feb 15 2017 10:38:44 EST from bennabiy @ Uncensored

Subject: Re: Citserver stops responding

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

Since I have not managed to get it to produce a core yet, I think I am better off manually starting it in gdb.

 

Tue Feb 14 2017 18:46:08 EST from IGnatius T Foobar @ Uncensored Subject: Re: Citserver stops responding
Tue Feb 14 2017 11:28:02 AM EST from bennabiy @ Uncensored Subject: Re: Citserver stops responding

How would you recommend starting citserver to try to capture it? It is not something I can duplicate except by waiting...

Well, there are a couple of ways.  You can either start citserver from inside the debugger, or you can try to get a core dump.  If your problem is occurring on a predictable daily basis, you're probably better off starting with the debugger.  Stop citserver and then start it like this:

cd /usr/local/citadel

gdb ./citserver

(gdb) run

Citadel Server will run in the foreground.  When you have the problem where it gets stuck, press Ctrl-C.  You will get some diagnostics and a new gdb prompt.  At that point you have to get the stack traces for every thread:

(gdb) thread apply all bt

Most of your threads will be blocked on select() , those are idle threads.  If the server is truly stuck, there will be at least one thread doing something unusual.  Where it is will tell us what's stuck.



 



[#] Wed Feb 15 2017 11:13:42 EST from bennabiy @ Uncensored

Subject: Re: Citserver stops responding

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

Ok, here is the backtrace-

citserver[1211]: SSL_read got error 5

citserver[1211]: Ending SSL/TLS

 

Program received signal SIGPIPE, Broken pipe.

[Switching to Thread 0x7ffff2f79700 (LWP 1380)]

0x00007ffff6a10a3d in write () at ../sysdeps/unix/syscall-template.S:81

81../sysdeps/unix/syscall-template.S: No such file or directory.

(gdb) thread apply all bt

 

Thread 8 (Thread 0x7ffff2f79700 (LWP 1380)):

#0  0x00007ffff6a10a3d in write () at ../sysdeps/unix/syscall-template.S:81

#1  0x00007ffff765e155 in ?? () from /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0

#2  0x00007ffff765c1ec in BIO_write () from /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0

#3  0x00007ffff7986f12 in ?? () from /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0

#4  0x00007ffff7988b83 in ?? () from /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0

#5  0x00007ffff7984d42 in ?? () from /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0

#6  0x0000000000443af0 in endtls () at modules/crypto/serv_crypto.c:707

#7  0x0000000000442ffa in client_read_sslbuffer (buf=0x7fffe00ec850, timeout=1) at modules/crypto/serv_crypto.c:420

#8  0x0000000000443240 in client_readline_sslbuffer (Line=0x7fffd8009700, IOBuf=0x7fffe00ec850, Pos=0x7fffe008e580, timeout=1) at modules/crypto/serv_crypto.c:486

#9  0x00000000004166ff in CtdlClientGetLine (Target=0x7fffd8009700) at sysdep.c:777

#10 0x0000000000464900 in imap_command_loop () at modules/imap/serv_imap.c:1527

#11 0x00000000004178ca in worker_thread (blah=0x0) at sysdep.c:1453

#12 0x0000000000434c4f in CTC_backend (supplied_start_routine=0x417188 <worker_thread>) at threads.c:121

#13 0x00007ffff6a0a064 in start_thread (arg=0x7ffff2f79700) at pthread_create.c:309

#14 0x00007ffff543d62d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

 

Thread 7 (Thread 0x7ffff3186700 (LWP 1339)):

#0  0x00007ffff6a10a9d in read () at ../sysdeps/unix/syscall-template.S:81

#1  0x00007ffff765e0dc in ?? () from /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0

#2  0x00007ffff765c0ec in BIO_read () from /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0

#3  0x00007ffff7986b44 in ?? () from /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0

#4  0x00007ffff7987e6d in ?? () from /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0

#5  0x00007ffff7984f84 in ?? () from /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0

#6  0x0000000000442f9d in client_read_sslbuffer (buf=0x7fffe82c8360, timeout=1) at modules/crypto/serv_crypto.c:410

#7  0x0000000000443240 in client_readline_sslbuffer (Line=0x7fffe01abf90, IOBuf=0x7fffe82c8360, Pos=0x7fffe8338bb0, timeout=1) at modules/crypto/serv_crypto.c:486

---Type <return> to continue, or q <return> to quit---

#8  0x00000000004166ff in CtdlClientGetLine (Target=0x7fffe01abf90) at sysdep.c:777

#9  0x0000000000464900 in imap_command_loop () at modules/imap/serv_imap.c:1527

#10 0x00000000004178ca in worker_thread (blah=0x0) at sysdep.c:1453

#11 0x0000000000434c4f in CTC_backend (supplied_start_routine=0x417188 <worker_thread>) at threads.c:121

#12 0x00007ffff6a0a064 in start_thread (arg=0x7ffff3186700) at pthread_create.c:309

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

 

Thread 6 (Thread 0x7ffff307a700 (LWP 1219)):

#0  0x00007ffff5436893 in select () at ../sysdeps/unix/syscall-template.S:81

#1  0x0000000000417450 in worker_thread (blah=0x0) at sysdep.c:1319

#2  0x0000000000434c4f in CTC_backend (supplied_start_routine=0x417188 <worker_thread>) at threads.c:121

#3  0x00007ffff6a0a064 in start_thread (arg=0x7ffff307a700) at pthread_create.c:309

#4  0x00007ffff543d62d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

 

Thread 5 (Thread 0x7ffff3287700 (LWP 1218)):

#0  0x00007ffff6a10a9d in read () at ../sysdeps/unix/syscall-template.S:81

#1  0x00007ffff765e0dc in ?? () from /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0

#2  0x00007ffff765c0ec in BIO_read () from /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0

#3  0x00007ffff798cb45 in ?? () from /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0

#4  0x00007ffff798b3da in ?? () from /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0

#5  0x00007ffff798b9f8 in ?? () from /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0

#6  0x00000000004437d6 in CtdlStartTLS (ok_response=0x0, nosup_response=0x0, error_response=0x0) at modules/crypto/serv_crypto.c:617

#7  0x000000000041a560 in CtdlModuleStartCryptoMsgs (ok_response=0x0, nosup_response=0x0, error_response=0x0) at serv_extensions.c:1477

#8  0x000000000048b12e in smtps_greeting () at modules/smtp/serv_smtp.c:201

#9  0x00000000004178ad in worker_thread (blah=0x0) at sysdep.c:1449

#10 0x0000000000434c4f in CTC_backend (supplied_start_routine=0x417188 <worker_thread>) at threads.c:121

#11 0x00007ffff6a0a064 in start_thread (arg=0x7ffff3287700) at pthread_create.c:309

---Type <return> to continue, or q <return> to quit---

#12 0x00007ffff543d62d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

 

Thread 4 (Thread 0x7ffff3388700 (LWP 1217)):

#0  0x00007ffff5436893 in select () at ../sysdeps/unix/syscall-template.S:81

#1  0x0000000000417450 in worker_thread (blah=0x0) at sysdep.c:1319

#2  0x0000000000434c4f in CTC_backend (supplied_start_routine=0x417188 <worker_thread>) at threads.c:121

#3  0x00007ffff6a0a064 in start_thread (arg=0x7ffff3388700) at pthread_create.c:309

#4  0x00007ffff543d62d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

 

Thread 3 (Thread 0x7ffff3489700 (LWP 1216)):

#0  0x00007ffff543dc03 in epoll_wait () at ../sysdeps/unix/syscall-template.S:81

#1  0x00007ffff735ebc2 in epoll_poll (loop=0x7fffe4000940, timeout=<optimized out>) at ev_epoll.c:153

#2  0x00007ffff7360f8d in ev_run (loop=0x7fffe4000940, flags=<optimized out>) at ev.c:3049

#3  0x0000000000450780 in db_event_thread (arg=0x0) at modules/eventclient/serv_eventclient.c:867

#4  0x0000000000434c4f in CTC_backend (supplied_start_routine=0x450663 <db_event_thread>) at threads.c:121

#5  0x00007ffff6a0a064 in start_thread (arg=0x7ffff3489700) at pthread_create.c:309

#6  0x00007ffff543d62d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

 

Thread 2 (Thread 0x7ffff7f80700 (LWP 1215)):

#0  0x00007ffff543dc03 in epoll_wait () at ../sysdeps/unix/syscall-template.S:81

#1  0x00007ffff735ebc2 in epoll_poll (loop=0x7ffff7567500 <default_loop_struct>, timeout=<optimized out>) at ev_epoll.c:153

#2  0x00007ffff7360f8d in ev_run (loop=0x7ffff7567500 <default_loop_struct>, flags=<optimized out>) at ev.c:3049

#3  0x000000000045027d in client_event_thread (arg=0x0) at modules/eventclient/serv_eventclient.c:727

#4  0x0000000000434c4f in CTC_backend (supplied_start_routine=0x450125 <client_event_thread>) at threads.c:121

#5  0x00007ffff6a0a064 in start_thread (arg=0x7ffff7f80700) at pthread_create.c:309

#6  0x00007ffff543d62d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

 

---Type <return> to continue, or q <return> to quit---

Thread 1 (Thread 0x7ffff7fe1700 (LWP 1211)):

#0  0x00007ffff540ef2d in nanosleep () at ../sysdeps/unix/syscall-template.S:81

#1  0x00007ffff5436fb4 in usleep (useconds=<optimized out>) at ../sysdeps/unix/sysv/linux/usleep.c:32

#2  0x0000000000434d96 in go_threading () at threads.c:178

#3  0x000000000040bf7f in main (argc=1, argv=0x7fffffffe5a8) at server_main.c:402

 

(gdb) 

 

This was the fastest I have seen it crash yet.

Tue Feb 14 2017 18:46:08 EST from IGnatius T Foobar @ Uncensored Subject: Re: Citserver stops responding
Tue Feb 14 2017 11:28:02 AM EST from bennabiy @ Uncensored Subject: Re: Citserver stops responding

How would you recommend starting citserver to try to capture it? It is not something I can duplicate except by waiting...

Well, there are a couple of ways.  You can either start citserver from inside the debugger, or you can try to get a core dump.  If your problem is occurring on a predictable daily basis, you're probably better off starting with the debugger.  Stop citserver and then start it like this:

cd /usr/local/citadel

gdb ./citserver

(gdb) run

Citadel Server will run in the foreground.  When you have the problem where it gets stuck, press Ctrl-C.  You will get some diagnostics and a new gdb prompt.  At that point you have to get the stack traces for every thread:

(gdb) thread apply all bt

Most of your threads will be blocked on select() , those are idle threads.  If the server is truly stuck, there will be at least one thread doing something unusual.  Where it is will tell us what's stuck.



 



[#] Wed Feb 15 2017 12:30:07 EST from bennabiy @ Uncensored

Subject: Re: Citserver stops responding

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

I decided to put the backtraces in a pastebin (sorry I did not do it the first time) so far I have gotten it to crash twice, same error.

https://pastebin.mozilla.org/8979383

You can view the diff between them (obviously there will be many)

Let me know where to go from here...

 

Tue Feb 14 2017 18:46:08 EST from IGnatius T Foobar @ Uncensored Subject: Re: Citserver stops responding
Tue Feb 14 2017 11:28:02 AM EST from bennabiy @ Uncensored Subject: Re: Citserver stops responding

How would you recommend starting citserver to try to capture it? It is not something I can duplicate except by waiting...

Well, there are a couple of ways.  You can either start citserver from inside the debugger, or you can try to get a core dump.  If your problem is occurring on a predictable daily basis, you're probably better off starting with the debugger.  Stop citserver and then start it like this:

cd /usr/local/citadel

gdb ./citserver

(gdb) run

Citadel Server will run in the foreground.  When you have the problem where it gets stuck, press Ctrl-C.  You will get some diagnostics and a new gdb prompt.  At that point you have to get the stack traces for every thread:

(gdb) thread apply all bt

Most of your threads will be blocked on select() , those are idle threads.  If the server is truly stuck, there will be at least one thread doing something unusual.  Where it is will tell us what's stuck.



 



[#] Wed Feb 15 2017 14:46:28 EST from bennabiy @ Uncensored

Subject: Re: Citserver stops responding

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

latest pastebin... https://pastebin.mozilla.org/8979396

Wed Feb 15 2017 12:30:07 EST from bennabiy @ Uncensored Subject: Re: Citserver stops responding

I decided to put the backtraces in a pastebin (sorry I did not do it the first time) so far I have gotten it to crash twice, same error.

https://pastebin.mozilla.org/8979383

You can view the diff between them (obviously there will be many)

Let me know where to go from here...

 

Tue Feb 14 2017 18:46:08 EST from IGnatius T Foobar @ Uncensored Subject: Re: Citserver stops responding
Tue Feb 14 2017 11:28:02 AM EST from bennabiy @ Uncensored Subject: Re: Citserver stops responding

How would you recommend starting citserver to try to capture it? It is not something I can duplicate except by waiting...

Well, there are a couple of ways.  You can either start citserver from inside the debugger, or you can try to get a core dump.  If your problem is occurring on a predictable daily basis, you're probably better off starting with the debugger.  Stop citserver and then start it like this:

cd /usr/local/citadel

gdb ./citserver

(gdb) run

Citadel Server will run in the foreground.  When you have the problem where it gets stuck, press Ctrl-C.  You will get some diagnostics and a new gdb prompt.  At that point you have to get the stack traces for every thread:

(gdb) thread apply all bt

Most of your threads will be blocked on select() , those are idle threads.  If the server is truly stuck, there will be at least one thread doing something unusual.  Where it is will tell us what's stuck.



 



 



[#] Thu Feb 16 2017 11:25:34 EST from bennabiy @ Uncensored

Subject: Re: BugHunt

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

I started citserver again in gdb, this time with glibc-source installed (so that we do not get a misleading error)... will let you know what I find.



[#] Thu Feb 16 2017 17:21:28 EST from IGnatius T Foobar @ Uncensored

Subject: Re: BugHunt

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

Quick hint here: if your server stopped on a SIGPIPE, you're not actually hung up. You have to bypass SIGPIPE in the debugger. This can be done by entering the following command in gdb *before* you run the program:

handle SIGPIPE nostop noprint pass

You'll get a SIGPIPE any time a remote host hangs up unexpectedly. This doesn't bother citserver but for some reason gdb likes to stop on it.

[#] Thu Feb 16 2017 17:34:15 EST from bennabiy @ Uncensored

Subject: Re: BugHunt

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

I figured as much that it seemed odd that it was crashing so quickly in the debugger, and I noticed it referenced a source library which didn't exist.

 

Running again...

Thu Feb 16 2017 17:21:28 EST from IGnatius T Foobar @ Uncensored Subject: Re: BugHunt
Quick hint here: if your server stopped on a SIGPIPE, you're not actually hung up. You have to bypass SIGPIPE in the debugger. This can be done by entering the following command in gdb *before* you run the program:

handle SIGPIPE nostop noprint pass

You'll get a SIGPIPE any time a remote host hangs up unexpectedly. This doesn't bother citserver but for some reason gdb likes to stop on it.

 



[#] Thu Feb 16 2017 22:51:42 EST from rwolfe @ Uncensored

Subject: Citadel VM

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

Hi all!  I am putting together a VM of the latest Citadel (built using the EasyInstall script) built on the latest CentOS 7.x release.  The VM is for Oracle VirtualBox and if anyone wants to give it a look see or a try, please let me know and I can make it available for downloading from my BBS and website.



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