mystery solved: unclean shutdown causes redo.log to be owned by root:root

[jml75]

Hello guys,

I'm on Debian Sarge with the default 2.6.8 kernel.

I upgraded to 4.0.4 from 3.1.4 and I'm having the same file ownership problem than you guys. Almost each time I shutdown the zimbra services, redo.log ownership's gets changed to root:root. But this was happening to from time to time in version 3.1.4 of zimbra.

What's new thought is the mailboxes index ownership issue. Like raj2569 mentioned, when the ownership of a mailbox's index gets changed to root:root, I get the exact same error message from web mail when I try to send a message and all mails gets stuck in the deffered queue for this account.

If I rebuild the index or if I change the permissions of the index files, it's all good again.

But what's bogging me is that it's happening every days since the upgrade and it's affecting what seems to be random mail boxes.

So did any of you tried the current kernel from debian testing, version 2.6.17-2? Did it fix your problem? Or if it is really a kernel problem, wich debian kernel do you recommend me to use?

Thanx for your help guys!

Jonathan

[rainynight65]

I am running Debian 3.1 with a 2.6.19 Kernel, and I still have this problem. Is there more to it than just the kernel?

[phoenix]

Originally Posted by rainynight65

I am running Debian 3.1 with a 2.6.19 Kernel, and I still have this problem. Is there more to it than just the kernel?

Not as far as I know, did you ask on a Debian group/mailing list to see if the bug has been fixed?

[jammy]

Originally Posted by jml75

Hello guys,
But what's bogging me is that it's happening every days since the upgrade and it's affecting what seems to be random mail boxes.

So did any of you tried the current kernel from debian testing, version 2.6.17-2? Did it fix your problem? Or if it is really a kernel problem, wich debian kernel do you recommend me to use?

I just had it happen when I upgraded to 4.5 from 4.02. I'm running the 2.6.17 kernel - and I guess people are having the problem with 2.6.19 so it doesn't seem to totally be the kernel.

I'm thinking it's not totally random for user accounts - maybe it's the people that were actually logged in when you tried to shut it down? Or it was people currently receiving an email..

The only user i've noticed the problem with so far with this upgrade was my own account, and I was logged in with imap.

[jbwiv]

Guys,

I'm on Debian Sarge (2.6.8-022) and seeing this problem. However, per the bugzilla notes I should be seeing zeros in this output but am not:

mailhost:/# grep Uid /proc/12108/task/*/status
/proc/12108/task/12108/status:Uid: 1006 1006 1006 1006
/proc/12108/task/12109/status:Uid: 1006 1006 1006 1006
/proc/12108/task/12110/status:Uid: 1006 1006 1006 1006
/proc/12108/task/12111/status:Uid: 1006 1006 1006 1006
/proc/12108/task/12112/status:Uid: 1006 1006 1006 1006
/proc/12108/task/12113/status:Uid: 1006 1006 1006 1006
/proc/12108/task/12114/status:Uid: 1006 1006 1006 1006
/proc/12108/task/12115/status:Uid: 1006 1006 1006 1006

Am I missing something? Do I need to upgrade my kernel? What are the risks?

Thanks

Jbwiv

[jbwiv]

Ahh...ok, the previous post showed the output for the java process that runs "org.apache.catalina.startup.Bootstrap start". When I look at the output for the process running "com.zimbra.cs.launcher.TomcatLauncher", I see:

mailhost:/# grep Uid /proc/10211/task/*/status
/proc/10211/task/10211/status:Uid: 1006 1006 1006 1006
/proc/10211/task/10216/status:Uid: 0 0 0 0
/proc/10211/task/10218/status:Uid: 0 0 0 0
/proc/10211/task/10219/status:Uid: 0 0 0 0
/proc/10211/task/10224/status:Uid: 0 0 0 0
/proc/10211/task/10225/status:Uid: 0 0 0 0
/proc/10211/task/10236/status:Uid: 0 0 0 0
/proc/10211/task/10237/status:Uid: 0 0 0 0
/proc/10211/task/11398/status:Uid: 0 0 0 0
/proc/10211/task/11401/status:Uid: 1006 1006 1006 1006
/proc/10211/task/11402/status:Uid: 1006 1006 1006 1006
/proc/10211/task/11405/status:Uid: 1006 1006 1006 1006
/proc/10211/task/11408/status:Uid: 1006 1006 1006 1006
/proc/10211/task/11409/status:Uid: 1006 1006 1006 1006
/proc/10211/task/11410/status:Uid: 1006 1006 1006 1006
/proc/10211/task/11411/status:Uid: 1006 1006 1006 1006

So it appears I am affected? If so, is there a guaranteed kernel version that'll fix this? I run OpenVZ...their current stable is 2.6.9-023 and current development is 2.6.18.

Thanks guys.

Jbwiv

[voltcraft]

I have the same problem on my debian server I'm running 2.6.18-3-vserver-686, a precompiled binary. Sometimes I can make a clean shutdown and then restart the server normally, especially when I try tomcat start|stop.

Are these permissions correct?

root     18020  0.0  0.0  1580  308 ?        Ss   Mar05   0:00 /opt/zimbra/libexec/zmtomcatmgr start -Xms149m -Xmx149m -client -XX:NewRatio=2 -Djava.awt.headless=true
zimbra   18021 13.2 22.0 476676 112120 ?     S    Mar05 183:51 /opt/zimbra/jdk1.5.0_08/bin/java -Xms149m -Xmx149m -client -XX:NewRatio=2 -Djava.awt.headless=true -Dcatalina.base=/opt/zimbra/apache-tomcat-5.5.15 -Dcatalina.home=/opt/zimbra/apache-tomcat-5.5.15 -Djava.io.tmpdir=/opt/zimbra/apache-tomcat-5.5.15/temp -Djava.library.path=/opt/zimbra/lib -Djava.endorsed.dirs=/opt/zimbra/apache-tomcat-5.5.15/common/endorsed -classpath /opt/zimbra/apache-tomcat-5.5.15/bin/bootstrap.jar:/opt/zimbra/apache-tomcat-5.5.15/bin/commons-logging-api.jar:/opt/zimbra/lib/jars/zimbra-launcher.jar com.zimbra.cs.launcher.TomcatLauncher

grep Uid /proc/18021/task/*/status

/proc/18021/task/18021/status:Uid:      1000    1000    1000    1000
/proc/18021/task/18028/status:Uid:      0       0       0       0
/proc/18021/task/18029/status:Uid:      0       0       0       0
/proc/18021/task/18030/status:Uid:      0       0       0       0
/proc/18021/task/18036/status:Uid:      0       0       0       0
/proc/18021/task/18037/status:Uid:      0       0       0       0
/proc/18021/task/18038/status:Uid:      0       0       0       0
/proc/18021/task/18039/status:Uid:      0       0       0       0
/proc/18021/task/18167/status:Uid:      0       0       0       0
/proc/18021/task/18170/status:Uid:      1000    1000    1000    1000
/proc/18021/task/18171/status:Uid:      1000    1000    1000    1000

Am I running a buggy kernel or are some permissions wrong?

[jbwiv]

Originally Posted by voltcraft

Am I running a buggy kernel or are some permissions wrong?

Based on what I've read, it looks like you're affected as well.

I'd love to get one of the Zimbra guy's feedback on this an my question above...assuming we are affected (and it appears that this is so) what kernel is guaranteed to fix the problem? Are either of the OpenVZ-compatible kernel versions I mentioned above sufficient?

Thanks guys.

Jbwiv

[marcmac]

(We did see this on debian, too, even though the bug doesn't mention it. This is why there will be no network version for Debian, btw).

We didn't do a comprehensive survey of linux kernels - we upgraded SuSE to 2.6.5-7.257-smp, and the problem went away. If your distro ships with an old kernel (SuSE 9) or a criminally old kernel (Debian) upgrade to the latest version you can get.

If your distro doesn't offer a kernel with the fix for this, perhaps you should build your own, or take it up with the maintainers of the distro.

[jbwiv]

Originally Posted by marcmac

(We did see this on debian, too, even though the bug doesn't mention it. This is why there will be no network version for Debian, btw).

Sigh...ok, well, trying to upgrade my kernel and I've hosed Zimbra (apparently).

Quick question...what are the security implications of leaving this unpatched?