Recent Messages Blank

Report bugs and workarounds
theEFAmenace
Posts: 16
Joined: 30 Jun 2016 00:32

Re: Recent Messages Blank

Post by theEFAmenace »

For me it was also a disk space issue, you need to look at your space.

As per Shawn's "Bingo" post

sudo mkdir /var/lib/mysql/temp
sudo chown mysql:mysql /var/lib/mysql/temp
sudo sed -i "/^\[mysqld\]/ a\tmpdir = /var/lib/mysql/temp" /etc/my.cnf.d/server.cnf
sudo service mysql reload
User avatar
shawniverson
Posts: 3640
Joined: 13 Jan 2014 23:30
Location: Indianapolis, Indiana USA
Contact:

Re: Recent Messages Blank

Post by shawniverson »

Yeah, if you are upgrading from an older version <3.0.2.3, you may still have to do this step yourself, as it may affect the incremental updates along the way. It is not permanently fixed until the 3.0.2.4 update is actually applied but can still manifest from, for example 3.0.2.2 to 3.0.2.3 during the incremental upgrade process.
kcargin
Posts: 10
Joined: 08 Sep 2017 12:59

Re: Recent Messages Blank

Post by kcargin »

If anyone reads this, I have spent over two hours trying to upgrade to the latest (.5) version, but STILL have blank "Recent Messages".
Oddly enough, the quarantines DO list messages...

I am at the end of my role on this.
The last error I was not able to get past was this:
$ wget https://raw.githubusercontent.com/mailw ... pgrade.php
--2017-10-17 17:56:32-- https://raw.githubusercontent.com/mailw ... pgrade.php
Resolving raw.githubusercontent.com... 151.101.200.133
Connecting to raw.githubusercontent.com|151.101.200.133|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 36497 (36K) [text/plain]
Saving to: âupgrade.php.3â

100%[===================================================================================================================================================================>] 36,497 --.-K/s in 0.02s

2017-10-17 17:56:32 (1.52 MB/s) - âupgrade.php.3â

$ sudo /usr/bin/php ./upgrade.php

MailWatch for MailScanner Database Upgrade to 1.2.7-dev

Have you done a full backup of your database? Type 'yes' to continue: yes

Testing connectivity to the database ................................. OK

Updating database schema:

- Convert database to utf8........................................... ALREADY DONE

- Drop `geoip_country` table......................................... ALREADY DROPPED
- Drop `spamscores` table............................................ ALREADY DROPPED
- Add autorelease table to `mailscanner` database.................... ALREADY EXIST
- Add mtalog_ids table to `mailscanner` database..................... ALREADY EXIST
- Add resetid, resetexpire and lastreset fields in `users` table..... ALREADY EXIST
- Add login_expiry and login_timeout fields in `users` table......... ALREADY EXIST

- Fix schema for username field in `audit_log` table................. ALREADY DONE
- Fix schema for id field in `blacklist` table....................... ALREADY DONE
- Fix schema for id field in `whitelist` table....................... ALREADY DONE
- Fix schema for username field in `users` table..................... ALREADY DONE
- Fix schema for username field in `user_filters` table.............. ALREADY DONE
- Fix schema for spamscore field in `users` table.................... ALREADY DONE
- Fix schema for highspamscore field in `users` table................ ALREADY DONE
- Fix schema for timestamp field in `maillog` table.................. ALREADY DONE
- Fix schema for password field in `users` table..................... ALREADY DONE
- Fix schema for fullname field in `users` table..................... ALREADY DONE
- Fix schema for rule_desc field in `mcp_rules` table................ ALREADY DONE

- Cleanup orphaned user_filters...................................... OK
- Add id field and primary key to `audit_log` table.................. ALREADY DONE
- Add inq_id field and primary key to `inq` table.................... ALREADY DONE
- Add maillog_id field and primary key to `maillog` table............ ALREADY DONE
- Add rblspamreport field to `maillog` table......................... ALREADY DONE
- Add token field to `maillog` table................................. ALREADY DONE
- Add released field to `maillog` table.............................. ERROR
Database error: Incorrect key file for table 'maillog'; try to repair it - SQL = 'ALTER TABLE `maillog` ADD `released` TINYINT(1) DEFAULT '0''
theEFAmenace
Posts: 16
Joined: 30 Jun 2016 00:32

Re: Recent Messages Blank

Post by theEFAmenace »

looks like you might need to run a repair on the mysql database ...
kcargin
Posts: 10
Joined: 08 Sep 2017 12:59

Re: Recent Messages Blank

Post by kcargin »

Would a MySQL repair be option 10, or something else?
kcargin
Posts: 10
Joined: 08 Sep 2017 12:59

Re: Recent Messages Blank

Post by kcargin »

Ran option 10 and it halted with "Lost connection to MySQL server during query when executing 'OPTIMIZE TABLE".
The last table referenced before the error was in the SA_Bayes database.
User avatar
pdwalker
Posts: 1553
Joined: 18 Mar 2015 09:16

Re: Recent Messages Blank

Post by pdwalker »

in /var/lib/mysql should be some file called *.err (where * is probably the hostname.domainname of your efa box).

Can you find any interesting errors or messages near the end of the file?
kcargin
Posts: 10
Joined: 08 Sep 2017 12:59

Re: Recent Messages Blank

Post by kcargin »

Sorry for the delayed reply. There is nothing in the err file dated any more recent than 9-1-2017:

170901 10:40:45 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
2017-09-01 10:40:45 140016727009312 [Note] /usr/sbin/mysqld (mysqld 10.1.24-MariaDB) starting as process 54275 ...
2017-09-01 10:40:45 140016727009312 [Note] InnoDB: innodb_empty_free_list_algorithm has been changed to legacy because of small buffer pool size. In order to use backoff, increase buffer pool at least up to 20MB.

2017-09-01 10:40:45 140016727009312 [Note] InnoDB: Using mutexes to ref count buffer pool pages
2017-09-01 10:40:45 140016727009312 [Note] InnoDB: The InnoDB memory heap is disabled
2017-09-01 10:40:45 140016727009312 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2017-09-01 10:40:45 140016727009312 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
2017-09-01 10:40:45 140016727009312 [Note] InnoDB: Compressed tables use zlib 1.2.3
2017-09-01 10:40:45 140016727009312 [Note] InnoDB: Using Linux native AIO
2017-09-01 10:40:45 140016727009312 [Note] InnoDB: Using generic crc32 instructions
2017-09-01 10:40:45 140016727009312 [Note] InnoDB: Initializing buffer pool, size = 128.0M
2017-09-01 10:40:45 140016727009312 [Note] InnoDB: Completed initialization of buffer pool
2017-09-01 10:40:45 140016727009312 [Note] InnoDB: Highest supported file format is Barracuda.
2017-09-01 10:40:45 140016727009312 [Note] InnoDB: Starting crash recovery from checkpoint LSN=166097949266
2017-09-01 10:40:45 140016727009312 [Note] InnoDB: Restoring possible half-written data pages from the doublewrite buffer...
2017-09-01 10:40:45 140016727009312 [Note] InnoDB: Starting final batch to recover 118 pages from redo log
2017-09-01 10:40:45 140016137254656 [Note] InnoDB: Log sequence number at the start 2889192508 and the end 2863234601 do not match.
2017-09-01 10:40:45 140016137254656 [ERROR] InnoDB: Database page corruption on disk or a failed file read of tablespace ./ibdata1 page [page id: space=0, page number=20598]. You may have to recover from a backup.
2017-09-01 10:40:45 7f580c1fb700 InnoDB: Page dump in ascii and hex (16384 bytes):
len 16384; hex 4889d2ad00005076000006b10000370500000026ac35943c45bf000000000000000000000000003028d7810b244a01d420f00005000000fd00000000000000000000000000000000002400000000000000000000000000000000000000000100020eba696e66696d756d0004000b$
InnoDB: End of page dump
2017-09-01 10:40:45 7f580c1fb700 InnoDB: uncompressed page, stored checksum in field1 1216991917, calculated checksums for field1: crc32 498578265, innodb 1216991917, none 3735928559, stored checksum in field2 2417799334, calculated che$
InnoDB: page type 17855 meaning INDEX
InnoDB: Page may be an index page where index id is 36
2017-09-01 10:40:45 140016137254656 [Note] InnoDB: It is also possible that your operating system has corrupted its own file cache and rebooting your computer removes the error. If the corrupt page is an index page. You can also try to $
2017-09-01 10:40:45 140016137254656 [ERROR] InnoDB: Ending processing because of a corrupt database page.
2017-09-01 10:40:45 7f580c1fb700 InnoDB: Assertion failure in thread 140016137254656 in file ha_innodb.cc line 21953
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/ ... overy.html
InnoDB: about forcing recovery.
170901 10:40:45 [ERROR] mysqld got signal 6 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.

To report this bug, see https://mariadb.com/kb/en/reporting-bugs

We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed,
something is definitely wrong and this may fail.

Server version: 10.1.24-MariaDB
key_buffer_size=134217728
read_buffer_size=131072
max_used_connections=0
max_threads=153
thread_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 467125 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0x0 thread_stack 0x48400
/usr/sbin/mysqld(my_print_stacktrace+0x2b)[0x7f582fef4abb]
/usr/sbin/mysqld(handle_fatal_signal+0x4d5)[0x7f582fa53365]
/lib64/libpthread.so.0(+0x3609c0f7e0)[0x7f582f0527e0]
/lib64/libc.so.6(gsignal+0x35)[0x7f582d478495]
/lib64/libc.so.6(abort+0x175)[0x7f582d479c75]
/usr/sbin/mysqld(+0x734002)[0x7f582fbb7002]
/usr/sbin/mysqld(+0x883b57)[0x7f582fd06b57]
/usr/sbin/mysqld(+0x8defec)[0x7f582fd61fec]
/usr/sbin/mysqld(+0x80f380)[0x7f582fc92380]
/lib64/libpthread.so.0(+0x3609c07aa1)[0x7f582f04aaa1]
/lib64/libc.so.6(clone+0x6d)[0x7f582d52ebcd]
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
170901 10:40:45 mysqld_safe mysqld from pid file /var/lib/mysql/notspam.centralva.net.pid ended
User avatar
pdwalker
Posts: 1553
Joined: 18 Mar 2015 09:16

Re: Recent Messages Blank

Post by pdwalker »

The English technical term for this problem is, "you're fucked"

Do you have backups?

What is your efa instance running on? Is it running under a vm? A real machine? Something else?
kcargin
Posts: 10
Joined: 08 Sep 2017 12:59

Re: Recent Messages Blank

Post by kcargin »

Ended up rebuilding a whole new VM and it worked great for about... THREE WEEKS and now we have the SAME issue AGAIN!
I can restore the VM, but WHY does this keep happening?!?!
User avatar
shawniverson
Posts: 3640
Joined: 13 Jan 2014 23:30
Location: Indianapolis, Indiana USA
Contact:

Re: Recent Messages Blank

Post by shawniverson »

Two thoughts:

1) Underlying storage problem?

2) Is /var filling up and crashing mariadb? If so, expand the disk size or lower the q_days duration in /etc/MailScanner/defaults
User avatar
pdwalker
Posts: 1553
Joined: 18 Mar 2015 09:16

Re: Recent Messages Blank

Post by pdwalker »

What shawniverson says.

Do a "df -H" immediately after one of these events and report back.

If your file system is full, you will cause issues with mysql/mariadb/whateverdb.
Post Reply