core dump - but email is delivered
As I described in my previous email a core dump is produced by deliver. I now discovered, that every delivery causes a core dump. Before I used a procmail script like :0 w | $DELIVERMAIL -a $LOGNAME -m user.$LOGNAME ($DELIVERMAIL is "/usr/local/bin/deliver -r $SENDER") Since I checked the exit status of this recipe with the w flag a following recipe was executed sending a warning message that the mail couldn't be delivered. This caused a mail loop with a bad configured mailing list. I removed the w flag but that's of course not a solution if each message causes deliver to throw a core. As I wrote, these problems occur since the upgrade 1.6.24 -> 2.0.13 Any hints greatly appreciated. Werner -- Werner Reisberger pgp-public-key available: Viktoriastr. 15http://www.pure.ch/mypubkey.txt CH-8057 Zurich
signaled to death by 11
Guys, I've installed Cyrus IMAP 2.0.13, Cyrus SASL 1.5.24,BerkeleyDB 3.2, pam_mysql and postfix on my RH 6.2 box. Started /usr/cyrus/bin/master and tried to telnet both pop3d and imap but i don't get any prompt... looking at my imapd.log... here's what it says... any idea? TYI! [imapd.log] May 8 00:08:29 mail master[1323]: about to exec /usr/cyrus/bin/lmtpd May 8 00:08:30 mail service-lmtpunix[1323]: executed May 8 00:08:30 mail master[1318]: process 1323 exited, signaled to death by 11 May 8 00:08:34 mail master[1327]: about to exec /usr/cyrus/bin/pop3d May 8 00:08:34 mail service-pop3[1327]: executed May 8 00:08:34 mail master[1318]: process 1327 exited, signaled to death by 11 May 8 00:08:54 mail master[1329]: about to exec /usr/cyrus/bin/imapd May 8 00:08:54 mail service-imap[1329]: executed May 8 00:08:54 mail master[1318]: process 1329 exited, signaled to death by 11 Get 250 color business cards for FREE! http://businesscards.lycos.com/vp/fastpath/
Re: Compilation fails under Red Hat 7.1 - libucdmibs.so undefined reference
Hans Deragon <[EMAIL PROTECTED]> writes: > I tried to compile cyrus under Red Hat 7.1, but the following errors > occured: > undefined reference to `rpmdbClose' Looks familiar. :-\ > I suspected that it might be a compiler issue (2.96 is I believe still >experimental) > so I compiled with kgcc: No, it's not gcc. (read below) > Since it refers to rpm* stuff, I do not suspect that Cyrus itself is broken, but > Red Hat 7.1. I could not imagine why Cyrus would want to have anything to Yes, Red Hat *is* broken. > do with rpms, unless this acronym stands for something else than the usual > binary packaging system. > Any help would be appreciated. I have no clue what libucdmibs.so's function is > and how to correct this. Is it possible that library is missing on the > compiler's command line? Uninstall snmp package, autoconfigure from cyrus-imapd will find this libraries, and include support for snmp. This libraries are somehow linked with rpm libraries (!?). Just hide or temporary deinstall snmp-devel and snmp (rpm -qa | grep snmp - don't remember full name of package) and rerun ./configure (remove config.cache before, or extract source again). Maybe you can add --without-snmp to cyrus-imapd, but it's safer ti just remove/hide snmp from RedHat. Another error during compilation will be previous declaration of some extern char from malloc.h (or stdio.h?). Just somment out that line in cyru code and rerun make. Sorry, this are nasty workarounds, but I don't know better. :-( -- This signature intentionally left blank
postfix+cyrus errors
I am using PostFix on my RedHatBox 7.0 And I use cyrus as my mailbox transport, but when I deliver mail I can not receive mail from Inbox.I check the mail log and found follows in mail log: May 6 10:26:58 tifa postfix/pipe[8634]: fatal: request to use mail system owner group id 12 May 6 10:26:59 tifa postfix/local[8624]: warning: end of input while receiving string data from service private/cyrus May 6 10:26:59 tifa postfix/local[8624]: warning: private/cyrus: malformed response May 6 10:26:59 tifa postfix/master[8597]: warning: process /usr/libexec/postfix/pipe pid 8634 exit status 1 May 6 10:26:59 tifa postfix/master[8597]: warning: /usr/libexec/postfix/pipe: bad command startup -- throttling in message log: May 6 10:27:41 tifa imapd[8650]: login: cloud.net.edu.xx [200.20.27.210] basara plaintext May 6 10:27:41 tifa gpm[645]: Error in protocol The problem that happened in message log is that there always a gpm error log message after each imapd log message.what does gpm do?from "man gpm" I got that it is something related with mouse, what does it to do with cyrus?
PAM authentication does not work with latest .tar.gz files ...
Okay, either I'm losing it, or there is a bug here somewhere :( I removed the ports I had installed, for FreeBSD, and built fresh from source, using the following configure settings: =[ sasl ] #!/bin/tcsh setenv CFLAGS -I/usr/local/include/db3 #setenv CPPFLAGS -I/usr/local/include/db3 ./configure \ --with-prefix=/usr/local \ --with-dbpath=/usr/local/etc/sasldb \ --with-pwcheck=/usr/local/var/pwcheck \ --with-pam \ --disable-krb4 \ --disable-gssapi \ --disable-anon \ --enable-login ==[ imap ]= #!/bin/tcsh setenv CFLAGS -I/usr/local/include/db3 ./configure \ --prefix=/usr/local \ --with-cyrus-user=cyrus \ --with-cyrus-group=cyrus \ --with-dbdir=/usr/local \ --with-openssl \ --with-sasl=/usr/local \ --without-krb \ --with-auth=unix \ --enable-debug \ --with-perl=/usr/bin/perl = Builds clean, installs clean and runs ... as long as I have a passwd in sasldb file, I'm find, but as soon as I try to use PAM to authenticate to an NT server, it fails ... My /etc/imapd.conf file looks like: = configdirectory: /var/spool/imap partition-default: /var/spool/mail admins: cyrus sieveusehomedir: false sievedir: /var/spool/sieve hashimapspool: true sasl_pwcheck_method: PAM If I do an 'saslpasswd -d marc' to remove myself from the sasldb file, then try and re-connect with pine, I get the following error: May 7 13:21:00 new-relay imapd[66067]: badlogin: atelier.acadiau.ca[131.162.138.223] CRAM-MD5 authentication failure [no secret in database] now, I know the PAM module/authentication itself is working, as if I use the same settings, same user and same passwd for ftpd, and it authenticates fine ... so its as if, even with sasl_pwcheck_method set, it isn't using PAM properly ... Am I missing something in my configure? My imapd.conf file? Some known reason why PAM doesn't work with FreeBSD? Thanks ... Marc G. Fournier [EMAIL PROTECTED] Senior Systems AdministratorAcadia University "These are my opinions, which are not necessarily shared by my employer"
Re: PAM authentication does not work with latest .tar.gz files ...
Date: Mon, 7 May 2001 13:37:42 -0300 (ADT) From: "Marc G. Fournier" <[EMAIL PROTECTED]> [...] If I do an 'saslpasswd -d marc' to remove myself from the sasldb file, then try and re-connect with pine, I get the following error: May 7 13:21:00 new-relay imapd[66067]: badlogin: atelier.acadiau.ca[131.162.138.223] CRAM-MD5 authentication failure [no secret in database] Cyrus is advertising CRAM-MD5, which always uses /etc/sasldb, because the file exists. However, since there's no secret for the user "marc" in /etc/sasldb, Pine can't use CRAM-MD5. Either remove the CRAM-MD5 plugin, remove /etc/sasldb, or configure Pine to not use CRAM-MD5. Larry
Re: Problems with 2.0.13 on FreeBSD
Date: Mon, 07 May 2001 11:06:18 -0700 From: Nick Sayer <[EMAIL PROTECTED]> Cc: Hajimu UMEMOTO <[EMAIL PROTECTED]>, [EMAIL PROTECTED] Lawrence Greenfield wrote: > I've applied this patch against imapd.c. pop3d doesn't currently have > this problem since it never services more than one connection. Au Contraire, pop3d does indeed have the same problem. To duplicate it, you connect to the pop3s port with 'openssl s_client', QUIT, then quickly telnet into the pop3s port. You will get a non-SSL pop3 service response because argv got trashed by setproctitle(). I'm extremely confused how this could happen. I just tried it against my test server to be sure, and couldn't reproduce this. pop3d doesn't reuse processes, so after the first connection (with openssl s_client) exits, it doesn't respond to the 2nd connection (with telnet). A different process is fork'd and exec'd, so the argv is brand new. Have you actually done this and seen this happen? Larry
Re: Problems with 2.0.13 on FreeBSD
Hajimu UMEMOTO wrote: > > nsayer> 2. imapd loses its "-s" argument the 2nd time around. I suspect this is a > nsayer> setproctitle issue, but I haven't tried to prove it. If I do > nsayer> 'openssl s_client -connect localhost:imaps', then '. logout' and then > nsayer> very quickly 'telnet localhost imaps', I get a non-SSLed imapd. > nsayer> Further research shows that when this happens the 'imaps' variable in the > nsayer> code is set to 0, which can only be because the argv[][] given to > nsayer> service_main() does not have a "-s" in it. > > How about this patch? It seems fixed the problem here. What I've > done is moving option parsing from service_main() to service_init(). > I believe option parsing is good enough to be done only one time. > I think there is same problem in pop3d. > > The patch to imapd appears to be both safe and effective. I have duplicated the problem with pop3d, however, so a similar patch would need to be applied.
Re: Problems with 2.0.13 on FreeBSD
Lawrence Greenfield wrote: > I've applied this patch against imapd.c. pop3d doesn't currently have > this problem since it never services more than one connection. Au Contraire, pop3d does indeed have the same problem. To duplicate it, you connect to the pop3s port with 'openssl s_client', QUIT, then quickly telnet into the pop3s port. You will get a non-SSL pop3 service response because argv got trashed by setproctitle(). Anything that has a service_main() that cares about **argv is potentially affected by this unless MAX_USE is set to -1 in master/service.h (At which point you might as well be just sticking the thing in inetd).
Re: PAM authentication does not work with latest .tar.gz files ...
Larry Greenfield writes: > >However, since there's no secret for the user "marc" in /etc/sasldb, >Pine can't use CRAM-MD5. This is a generic problem with c-client. If the server advertizes CRAM-MD5, the client will try only CRAM-MD5, and will not fall back to less secure authentication methods. The author states that this is correct behavior. -- -Gary Mills--Unix Support--U of M Academic Computing and Networking-
Re[2]: signalled to death by 11?
Hey Seva, This could also be due to an overheating system. -- Kevin Friday, March 23, 2001, 11:48:29 AM, you wrote: SA> This probably should be a FAQ item by now! One of the most SA> common reasons for signal 11 (on Redhat systems) with cyrus SA> is mismatch with the shared libraries. Often times it is the SA> Berkeley db versions that come with the Redhat distribution SA> coming in the way. SA> You may want to do an "ldd imapd", to check the libraries that SA> the compiled version of your programs are picking, if they SA> are not the same as the one that you built them with, then most SA> likely, that is your problem. If the shared libraries look ok SA> then you would have to deal with the logs and see if they have SA> anything to offer and if they don't reveal anything, then you SA> will probably have to deal with core itself by going into "gdb" SA> and looking at the trace and see where it bombed! SA> __ SA> Seva SA> Andreas Rogge wrote: >> >> --On Thursday, March 22, 2001 23:26:38 -0700 Cory Waddingham >> <[EMAIL PROTECTED]> wrote: >> >> > I recently installed Cyrus 2.0.12 on a RedHat 6.2 system. When I start up >> > the server and attempt to connect, I get the following error in my log: >> > process exited, signaled to death by 11 >> >> The signals are described in man 7 signals. Signal 11 (aka SIGSEGV) means a >> segmentation fault (i.e. the program tried to write to ram it didn't own) >> this generally means a programming error or hardware failure or something >> like this (maybe OS-error?). >> >> -- >> Andreas Rogge <[EMAIL PROTECTED]> >> Available on IRCnet:#linux.de as Dyson
Re: PAM authentication does not work with latest .tar.gz files ...
On Mon, 7 May 2001, Lawrence Greenfield wrote: >Date: Mon, 7 May 2001 13:37:42 -0300 (ADT) >From: "Marc G. Fournier" <[EMAIL PROTECTED]> > > [...] >If I do an 'saslpasswd -d marc' to remove myself from the sasldb file, >then try and re-connect with pine, I get the following error: > >May 7 13:21:00 new-relay imapd[66067]: badlogin: >atelier.acadiau.ca[131.162.138.223] CRAM-MD5 authentication failure [no secret in >database] > > Cyrus is advertising CRAM-MD5, which always uses /etc/sasldb, because > the file exists. > > However, since there's no secret for the user "marc" in /etc/sasldb, > Pine can't use CRAM-MD5. > > Either remove the CRAM-MD5 plugin, remove /etc/sasldb, or configure > Pine to not use CRAM-MD5. Okay, is there any way of setting it up so that, if someone logs in, they issue their passwd, the system checks: /etc/sasldb - that fails, check through PAM - that succeeds, add/update entry to sasldb so that their first login might be insecure, but subsequent ones will use a more secure encryption? I thought the 'sasl_auto_transition' was *supposed* to do that, but have never succeeded in getting that to work ... Thanks ...
Re: PAM authentication does not work with latest .tar.gz files ...
On Mon, 7 May 2001, Lawrence Greenfield wrote: >Date: Mon, 7 May 2001 13:37:42 -0300 (ADT) >From: "Marc G. Fournier" <[EMAIL PROTECTED]> > > [...] >If I do an 'saslpasswd -d marc' to remove myself from the sasldb file, >then try and re-connect with pine, I get the following error: > >May 7 13:21:00 new-relay imapd[66067]: badlogin: >atelier.acadiau.ca[131.162.138.223] CRAM-MD5 authentication failure [no secret in >database] > > Cyrus is advertising CRAM-MD5, which always uses /etc/sasldb, because > the file exists. > > However, since there's no secret for the user "marc" in /etc/sasldb, > Pine can't use CRAM-MD5. > > Either remove the CRAM-MD5 plugin, remove /etc/sasldb, or configure > Pine to not use CRAM-MD5. Woo hoo ... got one of the other guys to try it using kmail, and it appears to go to PAM (auth still fails, but at least now I know its going there) ... Has anyone here had any experience with pam_smb for authenticating? I'm using the same pam_smb module that I tested with ftpd, and it authenticated, but with POP3, I'm getting the error below: May 7 15:44:57 new-relay pop3d[66043]: pamsmbd : msg_snd problem May 7 15:45:05 new-relay pop3d[66046]: pamsmbd : msg_snd problem Its soo close, I can taste it :(
rlimit and linux 2.2.x
Ramiro noted in his cyrus-imap RPM release for 2.0.11: - Add patch from Lawrence Greenfield for bad file descriptor ordering and rlimit type portability. I still see rlimit problems in linux 2.2.x with cyrus-imap-2.0.13. Did this patch make it into that release? Has anyone else seen problems with rlimit in master.c? Thanks. Chris
Re: PAM authentication does not work with latest .tar.gz files ...
On Mon, 7 May 2001 [EMAIL PROTECTED] wrote: > Larry Greenfield writes: > > > >However, since there's no secret for the user "marc" in /etc/sasldb, > >Pine can't use CRAM-MD5. > > This is a generic problem with c-client. If the server advertizes > CRAM-MD5, the client will try only CRAM-MD5, and will not fall back > to less secure authentication methods. The author states that this > is correct behavior. My experience with 'the author' is that anything he does is right, everyone else is wrong :( That's why I use Cyrus IMAPd vs UofW ... but, pine is, so far as I've experienced, one of the better command line readers, and c-client is used in a fair number of other mailers :(
Re: PAM authentication does not work with latest .tar.gz files ...
> On Mon, 7 May 2001 13:37:42 -0300 (ADT)
> "Marc G. Fournier" <[EMAIL PROTECTED]> said:
marc.fournier> If I do an 'saslpasswd -d marc' to remove myself from the sasldb file,
marc.fournier> then try and re-connect with pine, I get the following error:
marc.fournier> May 7 13:21:00 new-relay imapd[66067]: badlogin:
atelier.acadiau.ca[131.162.138.223] CRAM-MD5 authentication failure [no secret in
database]
I believe CRAM-MD5 authentication requires sasldb. You need to
change pine setting to use plain password.
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
[EMAIL PROTECTED] [EMAIL PROTECTED] ume@{,jp.}FreeBSD.org
http://www.imasy.org/~ume/
Re: PAM authentication does not work with latest .tar.gz files ...
The Hermit Hacker writes: > >I thought the 'sasl_auto_transition' was *supposed* to do that, but have >never succeeded in getting that to work ... Yes, this works for me, as long as the client is able to do both kinds of authentication. -- -Gary Mills--Unix Support--U of M Academic Computing and Networking-
Re: PAM authentication does not work with latest .tar.gz files ...
On Tue, 8 May 2001, Hajimu UMEMOTO wrote: > > On Mon, 7 May 2001 13:37:42 -0300 (ADT) > > "Marc G. Fournier" <[EMAIL PROTECTED]> said: > > marc.fournier> If I do an 'saslpasswd -d marc' to remove myself from the sasldb file, > marc.fournier> then try and re-connect with pine, I get the following error: > > marc.fournier> May 7 13:21:00 new-relay imapd[66067]: badlogin: >atelier.acadiau.ca[131.162.138.223] CRAM-MD5 authentication failure [no secret in >database] > > I believe CRAM-MD5 authentication requires sasldb. You need to > change pine setting to use plain password. Any idea how?
Re: PAM authentication does not work with latest .tar.gz files ...
> On Mon, 7 May 2001 16:33:46 -0300 (ADT)
> The Hermit Hacker <[EMAIL PROTECTED]> said:
scrappy> On Tue, 8 May 2001, Hajimu UMEMOTO wrote:
> > On Mon, 7 May 2001 13:37:42 -0300 (ADT)
> > "Marc G. Fournier" <[EMAIL PROTECTED]> said:
>
> marc.fournier> If I do an 'saslpasswd -d marc' to remove myself from the sasldb file,
> marc.fournier> then try and re-connect with pine, I get the following error:
>
> marc.fournier> May 7 13:21:00 new-relay imapd[66067]: badlogin:
>atelier.acadiau.ca[131.162.138.223] CRAM-MD5 authentication failure [no secret in
>database]
>
> I believe CRAM-MD5 authentication requires sasldb. You need to
> change pine setting to use plain password.
scrappy> Any idea how?
Though I have no experience with pine, doesn't pine have the
configuration for the authentication method? LOGIN should work.
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
[EMAIL PROTECTED] [EMAIL PROTECTED] ume@{,jp.}FreeBSD.org
http://www.imasy.org/~ume/
Re: PAM authentication does not work with latest .tar.gz files ...
On Tue, 8 May 2001, Hajimu UMEMOTO wrote: > > On Mon, 7 May 2001 16:33:46 -0300 (ADT) > > The Hermit Hacker <[EMAIL PROTECTED]> said: > > scrappy> On Tue, 8 May 2001, Hajimu UMEMOTO wrote: > > > > On Mon, 7 May 2001 13:37:42 -0300 (ADT) > > > "Marc G. Fournier" <[EMAIL PROTECTED]> said: > > > > marc.fournier> If I do an 'saslpasswd -d marc' to remove myself from the sasldb >file, > > marc.fournier> then try and re-connect with pine, I get the following error: > > > > marc.fournier> May 7 13:21:00 new-relay imapd[66067]: badlogin: >atelier.acadiau.ca[131.162.138.223] CRAM-MD5 authentication failure [no secret in >database] > > > > I believe CRAM-MD5 authentication requires sasldb. You need to > > change pine setting to use plain password. > > scrappy> Any idea how? > > Though I have no experience with pine, doesn't pine have the > configuration for the authentication method? LOGIN should work. you are correct ... they have a 'disable method' feature, which will do it ... thanks ...
configure error
Hi, When I do a ./configure for cyrus-imapd-2.0.13 on my Linux box with Mandrake 8.0 ./configure --with-auth=unix --with-dbdir=/usr/lib/ The compiling script complains with an error message, configure: error: this version requires Berkeley DB 3.x. I checked my system for Berkeley DB 3.x with slocate libdb and I get /usr/lib/liddb_cxx_3.1.so /usr/lib/libdb_so.2 /usr/lib/libdb1.so.2 /usr/lib/libdb.so.3 /usr/lib/libdb2.so.3 /usr/X11R6/lib/modules/extensions/libdbe.a /lib/libdb-3.1.so Would someone please tell me what I am doing wrong here? Regards, Norman
SSL problems with Eudora and Outlook Express
I recently upgraded to Cyrus 2.0.13 (from 1.6.24), and as such was anxious to take advantage of the integrated SSL/TLS support. It worked just as it had under 1.6.24 under Communicator (I used stunnel for the SSL support then). However, under Outlook Express I encountered some strange problems. When I have two accounts setup, I could go from the Cyrus one to the other account and back once, but not twice (ie, view a folder on the Cyrus account, then a folder on another account). Initially this smelled like an Outlook Express bug to me, but then I switched from using Cyrus' native SSL support (imaps in this case) to using stunnel again, and it worked flawlessly. When this error occurred, I got debugging output that stated a 0 length key had been negotiated in the SSL connection setup. Then I tried the same thing with Eudora. Unlike Outlook Express, Eudora uses STARTTLS (not imaps port 993). Eudora failed even earlier (debugging showed that it failed in SSL_accept()). When I told Eudora to instead use the port 993 method, it worked just fine. Any thoughts about why STARTTLS doesn't seem to work? I don't know of other clients to check the STARTTLS functionality with other than Eudora... On the server, I'm running RedHat 6.2 on a 2.2.14 kernel. Alec -- Alec H. Peterson - [EMAIL PROTECTED] Staff Scientist CenterGate Research Group - http://www.centergate.com "Technology so advanced, even _we_ don't understand it!"
No Subject
Hi, When I do a ./configure for cyrus-imapd-2.0.13 on my Linux box with Mandrake 8.0 ./configure --with-auth=unix --with-dbdir=/usr/lib/ The compiling script complains with an error message, configure: error: this version requires Berkeley DB 3.x. I checked my system for Berkeley DB 3.x with slocate libdb and I get /usr/lib/liddb_cxx_3.1.so /usr/lib/libdb_so.2 /usr/lib/libdb1.so.2 /usr/lib/libdb.so.3 /usr/lib/libdb2.so.3 /usr/X11R6/lib/modules/extensions/libdbe.a /lib/libdb-3.1.so Would someone please tell me what I am doing wrong here? Regards, Norman
configure error
Hi, When I do a ./configure for cyrus-imapd-2.0.13 on my Linux box with Mandrake 8.0 ./configure --with-auth=unix --with-dbdir=/usr/lib/ The compiling script complains with an error message, configure: error: this version requires Berkeley DB 3.x. I checked my system for Berkeley DB 3.x with slocate libdb and I get /usr/lib/liddb_cxx_3.1.so /usr/lib/libdb_so.2 /usr/lib/libdb1.so.2 /usr/lib/libdb.so.3 /usr/lib/libdb2.so.3 /usr/X11R6/lib/modules/extensions/libdbe.a /lib/libdb-3.1.so Would someone please tell me what I am doing wrong here? Regards, Norman
Re: Problems with 2.0.13 on FreeBSD
Lawrence Greenfield wrote: [snip...] > > I'm extremely confused how this could happen. I just tried it against > my test server to be sure, and couldn't reproduce this. > > pop3d doesn't reuse processes, so after the first connection (with > openssl s_client) exits, it doesn't respond to the 2nd connection > (with telnet). A different process is fork'd and exec'd, so the argv > is brand new. I think the problem is in master and not pop3d... Maybe that's the confusion? Regards, Nuno Silva
Re: configure error
It looks like you haven't installed the db3 development package, which contains the header files needed to compile. Install db3-devel-3.1.17-1mdk.i586.rpm, that should solve this problem. Good Luck! On Mon, 7 May 2001, Norman Zhang wrote: > Hi, > > When I do a ./configure for cyrus-imapd-2.0.13 on my Linux box with Mandrake > 8.0 > > ./configure --with-auth=unix --with-dbdir=/usr/lib/ > > The compiling script complains with an error message, > > configure: error: this version requires Berkeley DB 3.x. > > I checked my system for Berkeley DB 3.x with slocate libdb and I get > > /usr/lib/liddb_cxx_3.1.so > /usr/lib/libdb_so.2 > /usr/lib/libdb1.so.2 > /usr/lib/libdb.so.3 > /usr/lib/libdb2.so.3 > /usr/X11R6/lib/modules/extensions/libdbe.a > /lib/libdb-3.1.so > > Would someone please tell me what I am doing wrong here? > > Regards, > Norman > > > >
Re: signalled to death by 11?
Could you elaborate the reason for this observation. Why would an over heated system be discriminating imap server process and not the master process or for that matter any other process on the system? __ Seva "Kevin J. Menard, Jr." wrote: > > Hey Seva, > > This could also be due to an overheating system. > > -- > Kevin > > Friday, March 23, 2001, 11:48:29 AM, you wrote: > > SA> This probably should be a FAQ item by now! One of the most > SA> common reasons for signal 11 (on Redhat systems) with cyrus > SA> is mismatch with the shared libraries. Often times it is the > SA> Berkeley db versions that come with the Redhat distribution > SA> coming in the way. > > SA> You may want to do an "ldd imapd", to check the libraries that > SA> the compiled version of your programs are picking, if they > SA> are not the same as the one that you built them with, then most > SA> likely, that is your problem. If the shared libraries look ok > SA> then you would have to deal with the logs and see if they have > SA> anything to offer and if they don't reveal anything, then you > SA> will probably have to deal with core itself by going into "gdb" > SA> and looking at the trace and see where it bombed! > > SA> __ > SA> Seva > > SA> Andreas Rogge wrote: > >> > >> --On Thursday, March 22, 2001 23:26:38 -0700 Cory Waddingham > >> <[EMAIL PROTECTED]> wrote: > >> > >> > I recently installed Cyrus 2.0.12 on a RedHat 6.2 system. When I start up > >> > the server and attempt to connect, I get the following error in my log: > >> > process exited, signaled to death by 11 > >> > >> The signals are described in man 7 signals. Signal 11 (aka SIGSEGV) means a > >> segmentation fault (i.e. the program tried to write to ram it didn't own) > >> this generally means a programming error or hardware failure or something > >> like this (maybe OS-error?). > >> > >> -- > >> Andreas Rogge <[EMAIL PROTECTED]> > >> Available on IRCnet:#linux.de as Dyson
