Zentyal Forum, Linux Small Business Server
Zentyal Server => Installation and Upgrades => Topic started by: theb2b on March 21, 2014, 03:33:49 am
-
Openchange will stop working, when I attempt to restart the service using the web GUI it will not start, what I found in the log;
2014/03/20 21:20:16 ERROR> RestartService.pm:61 EBox::SysInfo::CGI::RestartService::_process - Restart of OpenChange from dashboard failed: Can't locate object method "enableInnoDBIfNeeded" via package "EBox::MyDBEngine" at /usr/share/perl5/EBox/OpenChange.pm line 451.
Any thoughts on how to rectify? I can down the server and bring it back up again but will only last five minutes before openchange is again down.
Running Zentyal 3.3 on Ubuntu 12.01 of course.
-
Helo:
I would file a log on tracker.zentyal.org , as it seems to be some missing dependecy here.
BR
-
Hello,
Have you upgraded all zentyal components?
BR,
-
Same here, but the error appeared after full apt-get update && apt-get upgrade.
2014/03/22 16:37:55 ERROR> RestartService.pm:61 EBox::SysInfo::CGI::RestartService::_process - Restart of OpenChange from dashboard failed: Can't locate object method "enableInnoDBIfNeeded" via package "EBox::MyDBEngine" at /usr/share/perl5/EBox/OpenChange.pm line 451.
Luckily, it is a test server, just for trying out.
-
Sixstone, all Zentyal components are upgraded, nothing due to be upgraded. I removed openchange, got an error message openchange state is unknown. I then preformed a apt-get update then apt-get upgrade, there was several updates applied, so I installed openchange from the web GUI and again I got error message openchange state is unknown. Follows is snip from the zentyal log pertaining to openchange install.
2014/03/22 15:16:14 INFO> Base.pm:231 EBox::Module::Base::save - Restarting service for module: openchange
2014/03/22 15:16:15 ERROR> GlobalImpl.pm:654 EBox::GlobalImpl::saveAllModules - Failed to save changes in module openchange: Can't locate object method "throw" via package "Can't locate object method "enableInnoDBIfNeeded" via package "EBox::MyDBEngine" at /usr/share/perl5/EBox/OpenChange.pm line 451.
" (perhaps you forgot to load "Can't locate object method "enableInnoDBIfNeeded" via package "EBox::MyDBEngine" at /usr/share/perl5/EBox/OpenChange.pm line 451.
"?) at /usr/share/perl5/EBox/Module/Base.pm line 238, <GEN0> line 3141.
2014/03/22 15:16:15 INFO> GlobalImpl.pm:664 EBox::GlobalImpl::saveAllModules - Saving configuration: webadmin
2014/03/22 15:16:15 INFO> Base.pm:231 EBox::Module::Base::save - Restarting service for module: webadmin
2014/03/22 15:16:17 ERROR> GlobalImpl.pm:738 EBox::GlobalImpl::saveAllModules - The following modules failed while saving their changes, their state is unknown: openchange at Trace begun at /usr/share/perl5/EBox/Exceptions/Base.pm line 79
EBox::Exceptions::Base::stacktrace('EBox::Exceptions::Internal=HASH(0x82c55f0)') called at /usr/share/perl5/EBox/Exceptions/Base.pm line 119
EBox::Exceptions::Base::log('EBox::Exceptions::Internal=HASH(0x82c55f0)') called at /usr/share/perl5/EBox/Exceptions/Internal.pm line 35
EBox::Exceptions::Internal::new('EBox::Exceptions::Internal', 'The following modules failed while saving their changes, their state is unknown: openchange ') called at /usr/share/perl5/EBox/Exceptions/Base.pm line 91
EBox::Exceptions::Base::throw('EBox::Exceptions::Internal', 'The following modules failed while saving their changes, their state is unknown: openchange ') called at /usr/share/perl5/EBox/GlobalImpl.pm line 738
EBox::GlobalImpl::saveAllModules('EBox::GlobalImpl=HASH(0x29d4770)', 'progress', 'EBox::ProgressIndicator=HASH(0x16c6290)') called at /usr/share/perl5/EBox/Global.pm line 95
EBox::Global::AUTOLOAD('EBox::Global=HASH(0x29d3f90)', 'progress', 'EBox::ProgressIndicator=HASH(0x16c6290)') called at /usr/share/zentyal/global-action line 32
eval {...} at /usr/share/zentyal/global-action line 30
I'm going to file a bug as per suggestion from jbahillo, was going to wait for upgrade path for my existing server, but now seriously considering a fresh install to 3.4.
-
The same/similar is happening under 3.3 with Zarafa. Zarafa refused to restart after an update with the same error popping in the logs. I can manually restart zarafa by starting each zarafa-???? service in /etc/init-d/ so it is not a zarafa problem but something else.
-
Yes, same here.
Had upgraded to Core 3.3.7 a couple days ago and it ran initially fine but now, after a hard reboot caused by a power failure, Zarafa does not start with an almost identical error message.
Thanks half_life for the 'life-saving' tip to start Zarafa manually!
-
Yes, same issue here on 3.3, Core version 3.3.7.
Thx @half_life for the /etc/init.d pointer, that got me running again! Phew...
Anyway, the issue on the bug tracker https://tracker.zentyal.org/issues/397 is already marked as rejected with following statement:
this is an already solved dependencies mismatch error. It can be solved upgrading your zentyal-core package
Unfortunately this is NOT the case, I can't upgrade anything, not even with a dist-upgrade, so the error still persists in my setup.
Is anyone else also still experiencing this problem?
-
Yes, same issue here on 3.3, Core version 3.3.7.
-
I have placed my comments on that ticket. I am unable to re-open the ticket but I cannot stand by and allow it to be characterized in such a manner. There is a problem here. It would seem not to matter if you are using Openchange or Zarafa. Since Zarafa will start manually I am left to assume that it is the Zentyal glue logic and the "Can't locate object method "enableInnoDBIfNeeded" error that accompanies the problem.
How about it staff? You have four people with the same story. Will this turn into a push and shove match like the radius issue in 3.0?
-
Hello:
It seems that when published zentyal-core some updated versions of zentyal-zarafa and zentyal-openchange were not published, and they had interrelated changes.
Nevertheless as long as 3.4 has already been published I think that 3.3 will be kept unmantained, and the solution would be to wait for the upgrade to 3.4 or to install a clean 3.4.
Obviously, you could watch in github what changes were applied on zarafa module and apply to the files on your server...
-
Thanks for being upfront. Your fix involves more effort than the one we already employed. That being just restarting Zarafa manually or even re-adding it to the init process. Zarafa users (paid and unpaid) are in reasonable shape. What about your openchange customers?
12.04 is an LTS and is current for another month. How long will you be supporting the 14.04 / Z3.5? packages?
ETA: Sorry for my error, the next Zentyal LTS comes in Sept as 4.0.
-
I am getting the same error as well.
Your response does not fill me with confidence. There is currently no upgrade path from 3.3 to 3.4. You are basically saying we need to migrate to a new installation.
To be blunt about it - Windows support for Server 2003 is coming to an end soon - after eleven years. Six years after it's replacement come out in 2008. Support for Zentyal 3.3 has come to an end after - what? five months? You really expect people to install and configure their servers twice a year?
Also - you are saying a version of Zentyal ceases to be supported on the day a new version comes out? When I was young and foolish I would upgrade to a new release as soon as it was ready - but no more. Let the young install the young, I say - judging by the forums, waiting a bit is a good idea.
-
Same issue with 3.3.7 Core
2014/04/04 10:35:38 INFO> Service.pm:1004 EBox::Module::Service::restartService - Restarting service for module: zarafa
2014/04/04 10:35:39 ERROR> Service.pm:1008 EBox::Module::Service::restartService - Error restarting service: Can't locate object method "enableInnoDBIfNeeded" via package "EBox::MyDBEngine" at /usr/share/perl5/EBox/Zarafa.pm line 489.
2014/04/04 10:35:39 ERROR> Service.pm:1010 EBox::Module::Service::restartService - Can't locate object method "enableInnoDBIfNeeded" via package "EBox::MyDBEngine" at /usr/share/perl5/EBox/Zarafa.pm line 489.
at Trace begun at /usr/share/perl5/EBox/Exceptions/Base.pm line 79
EBox::Exceptions::Base::stacktrace('EBox::Exceptions::Internal=HASH(0x4e62620)') called at /usr/share/perl5/EBox/Exceptions/Base.pm line 119
EBox::Exceptions::Base::log('EBox::Exceptions::Internal=HASH(0x4e62620)') called at /usr/share/perl5/EBox/Exceptions/Internal.pm line 35
EBox::Exceptions::Internal::new('EBox::Exceptions::Internal', 'Can\'t locate object method "enableInnoDBIfNeeded" via package "EBox::MyDBEngine" at /usr/share/perl5/EBox/Zarafa.pm line 489.^J') called at /usr/share/perl5/EBox/Exceptions/Base.pm line 91
EBox::Exceptions::Base::throw('EBox::Exceptions::Internal', 'Can\'t locate object method "enableInnoDBIfNeeded" via package "EBox::MyDBEngine" at /usr/share/perl5/EBox/Zarafa.pm line 489.^J') called at /usr/share/perl5/EBox/Module/Service.pm line 1010
EBox::Module::Service::restartService('EBox::Zarafa=HASH(0x3b761e0)', 'restartModules', 1) called at /usr/share/perl5/EBox/Util/Init.pm line 127
eval {...} at /usr/share/perl5/EBox/Util/Init.pm line 125
EBox::Util::Init::moduleAction('zarafa', 'restartService', 'restart') called at /usr/share/perl5/EBox/Util/Init.pm line 199
EBox::Util::Init::moduleRestart('zarafa') called at /etc/init.d/zentyal line 53
main::main at /etc/init.d/zentyal line 69
-
Same issue here :(
@don: +1
-
I have the same issue as well.
This is my production server .. you mean to say I need to reinstall everything from scratch again .. and loose all my emails?
That's not a solution ..
Please help, we are not getting any emails for 3 days now.
-
+1
I have also the same issue,
Core 3.3.7
No more mail service for the whole family :-(
Please help with a fix or workaround!
Greetings
Stephan
-
This bug seems to have been silently fixed at least for Zarafa users. Openchange? What say you? Thanks staff!
-
+1 having this same problem with openchange crashing
-
Believe this too has been silently fixed as I no longer am having this problem. But know have a new problem, attempting to configure Outlook to use the account, either as "exchange" mail connection or as a Outlook mail only connection I am getting following errors.
This action cannot be completed. The connection to Microsoft Exchange is unavailable. Outlook must be online or connected to complete this action.
I also get messages stating unable to connect to server to get account information or unable to verify account information.
Deleted the test account, recreated, same result. Restarting the service or server get the same results. What is wrong here??? Why is this so freaking hard??
-
Run nmap against the zentyal server from another machine to see what ports are actually open and compare that to the results of netstat -plant (gives you listening services) on the zentyal server.
I am sorry, I can't speak intelligently where as it concerns openchange. I don't have exposure to it or Exchange to be able to tell you what ports should be open. I would start by verifying that network/firewall are configured correctly before looking for more esoteric problems.
-
Firewall is off, not installed as this is sitting behind the firewall for testing purposes.
-
netstat -plant on the server?
-
netstat -plant
root@srvzentyal:~# netstat -plant | grep 465
tcp 0 0 0.0.0.0:465 0.0.0.0:* LISTEN 6522/master
tcp6 0 0 :::465 :::* LISTEN 6522/master
root@srvzentyal:~# netstat -plant | grep 995
tcp 0 0 0.0.0.0:995 0.0.0.0:* LISTEN 6551/dovecot
tcp6 0 0 :::995 :::* LISTEN 6551/dovecot
root@srvzentyal:~# netstat -plant | grep 25
tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN 6522/master
tcp6 0 0 :::25 :::* LISTEN 6522/master
root@srvzentyal:~# netstat -plant | grep 110
tcp 0 0 0.0.0.0:110 0.0.0.0:* LISTEN 6551/dovecot
tcp6 0 0 :::110 :::* LISTEN 6551/dovecot
root@srvzentyal:~# netstat -plant | grep 88
tcp 0 0 0.0.0.0:88 0.0.0.0:* LISTEN 10796/samba
same ports are listed when I do a nmap localhost and from a neighboring server.
Ports listed as needing to be open not listed above are
TCP port 26 - SSL secured SMTP
In short necessary ports are open except 26, I don't know if that is needed or not.