This is solved for now, But now I see other thing in this last GIT: (check more below the log)
--- Nov 23 20:42:14 lira mysqld[1757]: 081123 20:42:14 - mysqld got signal 11 ; Nov 23 20:42:14 lira mysqld[1757]: This could be because you hit a bug. It is also possible that this binary Nov 23 20:42:14 lira mysqld[1757]: or one of the libraries it was linked against is corrupt, improperly built, Nov 23 20:42:14 lira mysqld[1757]: or misconfigured. This error can also be caused by malfunctioning hardware. Nov 23 20:42:14 lira mysqld[1757]: We will try our best to scrape up some info that will hopefully help diagnose Nov 23 20:42:14 lira mysqld[1757]: the problem, but since we have already crashed, something is definitely wrong Nov 23 20:42:14 lira mysqld[1757]: and this may fail. Nov 23 20:42:14 lira mysqld[1757]: Nov 23 20:42:14 lira mysqld[1757]: key_buffer_size=52428800 Nov 23 20:42:14 lira mysqld[1757]: read_buffer_size=131072 Nov 23 20:42:14 lira mysqld[1757]: max_used_connections=1 Nov 23 20:42:14 lira mysqld[1757]: max_connections=1000 Nov 23 20:42:14 lira mysqld[1757]: threads_connected=1 Nov 23 20:42:14 lira mysqld[1757]: It is possible that mysqld could use up to Nov 23 20:42:14 lira mysqld[1757]: key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 2227192 K Nov 23 20:42:14 lira mysqld[1757]: bytes of memory Nov 23 20:42:14 lira mysqld[1757]: Hope that's ok; if not, decrease some variables in the equation. Nov 23 20:42:14 lira mysqld[1757]: Nov 23 20:42:14 lira mysqld[1757]: thd=0x9a7ffd0 Nov 23 20:42:14 lira mysqld[1757]: Attempting backtrace. You can use the following information to find out Nov 23 20:42:14 lira mysqld[1757]: where mysqld died. If you see no messages after this, something went Nov 23 20:42:14 lira mysqld[1757]: terribly wrong... Nov 23 20:42:14 lira mysqld[1757]: Cannot determine thread, fp=0x8769c638, backtrace may not be correct. Nov 23 20:42:14 lira mysqld[1757]: Stack range sanity check OK, backtrace follows: Nov 23 20:42:14 lira mysqld[1757]: 0x81f61e6 Nov 23 20:42:14 lira mysqld[1757]: 0x8318763 Nov 23 20:42:14 lira mysqld[1757]: 0x8264dbe Nov 23 20:42:14 lira mysqld[1757]: 0x826583e Nov 23 20:42:14 lira mysqld[1757]: 0x821276b Nov 23 20:42:14 lira mysqld[1757]: 0x82146e7 Nov 23 20:42:14 lira mysqld[1757]: 0xb7f1bf3b Nov 23 20:42:14 lira mysqld[1757]: 0xb7d37b6e Nov 23 20:42:14 lira mysqld[1757]: New value of fp=(nil) failed sanity check, terminating stack trace! Nov 23 20:42:14 lira mysqld[1757]: Please read http://dev.mysql.com/doc/mysql/en/using-stack-trace.html and follow instructions on how to resolve the stack trace. Resolved Nov 23 20:42:14 lira mysqld[1757]: stack trace is much more helpful in diagnosing the problem, so please do Nov 23 20:42:14 lira mysqld[1757]: resolve it Nov 23 20:42:14 lira mysqld[1757]: Trying to get some variables. Nov 23 20:42:14 lira mysqld[1757]: Some pointers may be invalid and cause the dump to abort... Nov 23 20:42:14 lira mysqld[1757]: thd->query at 0x9ac65a0 = INSERT INTO dbmail_messages (mailbox_idnr,physmessage_id,seen_flag,answered_flag,deleted_flag,flagged_fl ag,recent_flag,draft_flag,unique_id,status) SELECT 341,physmessage_id,seen_flag,answered_flag,deleted_flag,flagged_flag,1,draft _flag,'f7996ea801283d1d0e4f0f90fa7105ca',status FROM dbmail_messages WHERE message_idnr = 3835682 Nov 23 20:42:14 lira mysqld[1757]: thd->thread_id=1 Nov 23 20:42:14 lira mysqld[1757]: The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains Nov 23 20:42:14 lira mysqld[1757]: information that should help you find out what is causing the crash. Nov 23 20:42:14 lira mysqld_safe[1783]: Number of processes running now: 0 Nov 23 20:42:14 lira mysqld_safe[1787]: restarted Nov 23 20:42:14 lira mysqld[1792]: InnoDB: Log scan progressed past the checkpoint lsn 34 3300568106 Nov 23 20:42:14 lira mysqld[1792]: 081123 20:42:14 InnoDB: Database was not shut down normally! Nov 23 20:42:14 lira mysqld[1792]: InnoDB: Starting crash recovery. Nov 23 20:42:14 lira mysqld[1792]: InnoDB: Reading tablespace information from the .ibd files... Nov 23 20:42:14 lira mysqld[1792]: InnoDB: Restoring possible half-written data pages from the doublewrite Nov 23 20:42:14 lira mysqld[1792]: InnoDB: buffer... Nov 23 20:42:14 lira mysqld[1792]: InnoDB: Doing recovery: scanned up to log sequence number 34 3301052297 --- My InnoDB settings in my.cnf are: --- innodb_file_per_table innodb_data_home_dir = /home/mysql/ innodb_log_group_home_dir = /home/mysql/ innodb_log_arch_dir = /home/mysql/ set-variable = innodb_buffer_pool_size=512M set-variable = innodb_additional_mem_pool_size=32M set-variable = innodb_log_file_size=65M set-variable = innodb_log_files_in_group=10 set-variable = innodb_log_buffer_size=128M innodb_flush_log_at_trx_commit=1 set-variable = innodb_lock_wait_timeout=50 --- Do you recommend other settings for the new ZDB system? My machine has 3GB of RAM, and 7GB of disk SWAP. The database now has 15GB, and growing about 0,25GB per month. > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:dbmail-dev- > [EMAIL PROTECTED] On Behalf Of Paul J Stevens > Sent: domingo, 23 de Novembro de 2008 20:46 > To: DBMAIL Developers Mailinglist > Subject: Re: [Dbmail-dev] last GIT on 23-11-2008 > > Jorge Bastos wrote: > > Sorry forgot to ask, isn't dbmail trying to write the pid file with > the > > EFFECTIVE user in dbmail.conf? nobody in this case > > of course. That's why it's not working for you. Don't use /var/run but > rather /var/run/dbmail/ (configure --localstatedir=/var/run/dbmail) and > chown nobody /var/run/dbmail. Or chown nobody /var/run for now. > > In 2.2 the pidfile was written by root, and cleaned up by the parent > process - also running as root. > > In 2.3 there is no parent process, so the only way to cleanup the > pidfile on program exit is if it was created by the euid to begin with. > > > > > > > >> -----Original Message----- > >> From: [EMAIL PROTECTED] [mailto:dbmail-dev- > >> [EMAIL PROTECTED] On Behalf Of Jorge Bastos > >> Sent: domingo, 23 de Novembro de 2008 20:26 > >> To: 'DBMAIL Developers Mailinglist' > >> Subject: RE: [Dbmail-dev] last GIT on 23-11-2008 > >> > >> Ops, > >> I'm a bit sleepy. > >> But I was checking the test machine, and it worked OK there, and the > >> /var > >> and /var/run permissoes are equal. > >> How can I debug this? > >> > >> > >>> -----Original Message----- > >>> From: [EMAIL PROTECTED] [mailto:dbmail-dev- > >>> [EMAIL PROTECTED] On Behalf Of Paul J Stevens > >>> Sent: domingo, 23 de Novembro de 2008 20:18 > >>> To: DBMAIL Developers Mailinglist > >>> Subject: Re: [Dbmail-dev] last GIT on 23-11-2008 > >>> > >>> Jorge Bastos wrote: > >>>> But still not on git right? > >>> check the changelog! drop_privileges was added 9 days ago. > >>> > >>> > >>> -- > >>> ________________________________________________________________ > >>> Paul Stevens paul at nfg.nl > >>> NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31 > >>> The Netherlands________________________________http://www.nfg.nl > >>> _______________________________________________ > >>> Dbmail-dev mailing list > >>> Dbmail-dev@dbmail.org > >>> http://twister.fastxs.net/mailman/listinfo/dbmail-dev > >> _______________________________________________ > >> Dbmail-dev mailing list > >> Dbmail-dev@dbmail.org > >> http://twister.fastxs.net/mailman/listinfo/dbmail-dev > > > > _______________________________________________ > > Dbmail-dev mailing list > > Dbmail-dev@dbmail.org > > http://twister.fastxs.net/mailman/listinfo/dbmail-dev > > > > > -- > ________________________________________________________________ > Paul Stevens paul at nfg.nl > NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31 > The Netherlands________________________________http://www.nfg.nl > _______________________________________________ > Dbmail-dev mailing list > Dbmail-dev@dbmail.org > http://twister.fastxs.net/mailman/listinfo/dbmail-dev _______________________________________________ Dbmail-dev mailing list Dbmail-dev@dbmail.org http://twister.fastxs.net/mailman/listinfo/dbmail-dev
