New install of Clear 7 is showing an error for Zarafa-Server, GUI won't start it, logs show...
Dec 14 10:20:21 gateway webconfig: Starting zarafa-server (via systemctl): [ OK ]
Dec 14 10:20:21 gateway zarafa-server: Stopping zarafa-server: [FAILED]
Dec 14 10:20:26 gateway systemd: Reloading.
Dec 14 10:20:26 gateway systemd: [/usr/lib/systemd/system/dm-event.socket:10] Unknown lvalue 'RemoveOnStop' in section 'Socket'
Dec 14 10:20:26 gateway systemd: [/usr/lib/systemd/system/lvm2-lvmetad.socket:9] Unknown lvalue 'RemoveOnStop' in section 'Socket'
Dec 14 10:20:26 gateway systemd: Reloading.
Dec 14 10:20:26 gateway systemd: [/usr/lib/systemd/system/dm-event.socket:10] Unknown lvalue 'RemoveOnStop' in section 'Socket'
Dec 14 10:20:26 gateway systemd: [/usr/lib/systemd/system/lvm2-lvmetad.socket:9] Unknown lvalue 'RemoveOnStop' in section 'Socket'
Dec 14 10:20:48 gateway arpwatch: bogon 0.0.0.0 0:23:a2:1c:96:2c
Thoughts?
Dan
Dec 14 10:20:21 gateway webconfig: Starting zarafa-server (via systemctl): [ OK ]
Dec 14 10:20:21 gateway zarafa-server: Stopping zarafa-server: [FAILED]
Dec 14 10:20:26 gateway systemd: Reloading.
Dec 14 10:20:26 gateway systemd: [/usr/lib/systemd/system/dm-event.socket:10] Unknown lvalue 'RemoveOnStop' in section 'Socket'
Dec 14 10:20:26 gateway systemd: [/usr/lib/systemd/system/lvm2-lvmetad.socket:9] Unknown lvalue 'RemoveOnStop' in section 'Socket'
Dec 14 10:20:26 gateway systemd: Reloading.
Dec 14 10:20:26 gateway systemd: [/usr/lib/systemd/system/dm-event.socket:10] Unknown lvalue 'RemoveOnStop' in section 'Socket'
Dec 14 10:20:26 gateway systemd: [/usr/lib/systemd/system/lvm2-lvmetad.socket:9] Unknown lvalue 'RemoveOnStop' in section 'Socket'
Dec 14 10:20:48 gateway arpwatch: bogon 0.0.0.0 0:23:a2:1c:96:2c
Thoughts?
Dan
Share this post:
Accepted Answer
First, the fix:
Where 'xxxx' should be replaced with the password from the 'cat' command.
Now...off to log a bug tracker...you are the 2nd user whom I've seen had this exact same issue...doubt it's co-incidence...wonder what's up?
B.
cat /var/clearos/system_database/root
/usr/clearos/sandbox/usr/bin/mysql -uroot -p'xxxx' mysql
repair table proc;
exit;
service system-mariadb restart
service zarafa-server restart
Where 'xxxx' should be replaced with the password from the 'cat' command.
Now...off to log a bug tracker...you are the 2nd user whom I've seen had this exact same issue...doubt it's co-incidence...wonder what's up?
B.
Responses (12)
-
Accepted Answer
Addiitonal Zarafa log info....
[root@gateway ~]# tail -f /var/log/zarafa/server.log
Mon Dec 14 10:15:54 2015: [error ] Can't initialize database settings
Mon Dec 14 10:19:44 2015: [fatal ] SQL [00000014] Failed: Table './mysql/proc' is marked as crashed and should be repaired, Query Size: 33, Query: "DROP PROCEDURE IF EXISTS GetProps"
Mon Dec 14 10:19:44 2015: [fatal ] ECDatabaseMySQL::_Update() query failed
Mon Dec 14 10:19:44 2015: [error ] Can't initialize database settings
Mon Dec 14 10:19:58 2015: [fatal ] SQL [00000016] Failed: Table './mysql/proc' is marked as crashed and should be repaired, Query Size: 33, Query: "DROP PROCEDURE IF EXISTS GetProps"
Mon Dec 14 10:19:58 2015: [fatal ] ECDatabaseMySQL::_Update() query failed
Mon Dec 14 10:19:58 2015: [error ] Can't initialize database settings
Mon Dec 14 10:20:21 2015: [fatal ] SQL [00000020] Failed: Table './mysql/proc' is marked as crashed and should be repaired, Query Size: 33, Query: "DROP PROCEDURE IF EXISTS GetProps"
Mon Dec 14 10:20:21 2015: [fatal ] ECDatabaseMySQL::_Update() query failed
Mon Dec 14 10:20:21 2015: [error ] Can't initialize database settings -
Accepted Answer
-
Accepted Answer
-
Accepted Answer
Ben: You saved my day. Your fix worked instantly.
Had a power-out last night, and had forgot to install the APCUPSD-software (tip; let this software be possible to install via marketplace, I am sure many COSusers have APC UPS, and this software is great for communication) after upgrading the server, so the server went off the hard way.
EDIT: Now I see another fault: Windows Networking (Samba) will not work, so stuff like Flexshare is not working:
When I goes to Windows Networking - app, it says :" Warning
The Samba Directory software is installed, so you no longer need this app."
Could it be related? If I go to marketplace it says Windows Networks is installed (but I cannot configure), while the beta Samba Directory is not installed, so this is correct anyway... -
Accepted Answer
Ben Chambers wrote:
First, the fix:
cat /var/clearos/system_database/root
/usr/clearos/sandbox/usr/bin/mysql -uroot -p'xxxx' mysql
repair table proc;
exit;
service system-mariadb restart
service zarafa-server restart
Where 'xxxx' should be replaced with the password from the 'cat' command.
Now...off to log a bug tracker...you are the 2nd user whom I've seen had this exact same issue...doubt it's co-incidence...wonder what's up?
B.
I just had this same exact issue.... Ben, your fix solve it. Thanks! -
Accepted Answer
Hi,
My Zarafa-Server also stopped working out of a sudden - same problem.
By the way my computer froze directly beforehand, after installing an update. Will try the fix.
Thanks.
Best wishes,
Robert
p.s.: The fix works. Thanks.
Restarting the computer did not help. I do have Clearos 7 Business and Zarafa Business -
Accepted Answer
+1 for the fix. My proc table was also corrupted somehow - I was in the process of porting mail from Cos6.7 to Cos7.2.- happened between the first sync, testing and final sync.
(I was also moving Drupal sites and other mysql databases to the new server, but don't think it should have affected the sandboxed database).
Anyway I was able to fix the issue and zarafa is now content.
Paul -
Accepted Answer
For anyone coming across this thread, before repairing the proc table as one of the post in here advises, can you try:
yum --enablerepo=clearos-updates-testing upgrade app-system-database-core
And upgrade to 2.1.7-1.
Then, try restarting Zarafa server:
service zarafa-server restart
And report back here and let me know if that too, resolves the proc issue.
Also, if anyone who had the 'proc' corruption in the past, upgrading may prevent the issue from occurring in the future.
According to this thread on the Zarafa forums, we should have this issue with the version of MariaDB we're running...however, we should have been running the mysql_upgrade script when upgrading the internal database.
All this update does it provide an automated script that will run the mysql_upgrade command.
/usr/clearos/apps/system_database/deploy/db_upgrade_repair
That you can also run with the --force flag, if desired.
It does nothing if nothing is required, so a fairly innocuous script.
I'd like to know two things:
1. Confirm that running this script fixes the proc table corruption
2. Longer term, I'd like to hear back on users who have upgraded, whether they ever see the proc corruption again or not...ideally, this issue 'goes away'. If it occurs to users who have upgraded, but #1 confirms it repairs the proc table, my next step is to add the calling of this script to the Zarafa server stop/start, that will fix the situation when the user tries starting Zarafa server.
Thanks,
B -
Accepted Answer
I tried to follow your directions Ben, my zarafa crashed again this morning, I can only see app-database-2.6.1 installed in my yum log.
Perhaps I had big thumbs when typing the original command?
--------------
I manually enabled the clearos-updates-testing repo and then was able to upgrade the app-database to 2.7.1-1
After that, service zarafa-server restart worked.
Up and running again!
Paul -
Accepted Answer
Ben Chambers wrote:
For anyone coming across this thread, before repairing the proc table as one of the post in here advises, can you try:
yum --enablerepo=clearos-updates-testing upgrade app-system-database-core
And upgrade to 2.1.7-1.
Then, try restarting Zarafa server:
service zarafa-server restart
And report back here and let me know if that too, resolves the proc issue.
Also, if anyone who had the 'proc' corruption in the past, upgrading may prevent the issue from occurring in the future.
According to this thread on the Zarafa forums, we should have this issue with the version of MariaDB we're running...however, we should have been running the mysql_upgrade script when upgrading the internal database.
All this update does it provide an automated script that will run the mysql_upgrade command.
/usr/clearos/apps/system_database/deploy/db_upgrade_repair
That you can also run with the --force flag, if desired.
It does nothing if nothing is required, so a fairly innocuous script.
I'd like to know two things:
1. Confirm that running this script fixes the proc table corruption
2. Longer term, I'd like to hear back on users who have upgraded, whether they ever see the proc corruption again or not...ideally, this issue 'goes away'. If it occurs to users who have upgraded, but #1 confirms it repairs the proc table, my next step is to add the calling of this script to the Zarafa server stop/start, that will fix the situation when the user tries starting Zarafa server.
Thanks,
B
Thanks Ben,
I had a power loss at the house and it obviously knocked the server down. I had this proc problem on reboot. Your command line update fixed it good as new -
Accepted Answer
-
Accepted Answer
Please login to post a reply
You will need to be logged in to be able to post a reply. Login using the form on the right or register an account if you are new here.
Register Here »