@LaM and @BerT666:I don't think, that that can or should be the test to find out, if a kernel-version is affected by this bug or not.
- data-transfer of 500 GB up to 1 TB...
- or instruct all users to put as much operation on it as possible at the same time...
That's IT technically destructive for the own reputation, "Oh yeah, please help me to crash the server"
@Carlos:You reached my magic uptime mark today with with more than 6 days uptime.
I'll probably give 3.19.0-58 a try, when you've got an uptime longer than 14 days without any issues...
Sorry, that you are the guinea pig (laboratory-technically seen)
@jwilliams1976:hotsummer55 wrote as answer towards your post @April 09, 2016, 11:24:04 am, that he/she tested 'ip route ls' with:
Not sure about this .I tested this against know bad kernel linux-image-3.19.0-49-generic.And it did not produce any problems when running ip rule show.
What kernel are you running now
and Carlos (alias pcready.cl) tested and wrote as answer towards your post @ April 09, 2016, 04:47:11 pm
use the command on the kernel linux-image-3.19.0-56-generic and nothing happened, and that is an affected version according to the forums...
And if my interpretation is right, then both kernels are affected by the bug of this forum thread 'CPU soft lockup', but regarding towards their reply not by the 'ip' bug you posted. Sorry I can't test it, but the Ubuntu launchpad bug track + the Zentyal forum thread towards the 'ip' bug, you posted, are covering perfectly and are identical towards the won cognition.
So 'ip' bug occurs in these relevant kernels:
3.
16.0-52, 3.
16.0-53 (Zentyal 4.1)
and
3.
19.0-37 (probably Zentyal 4.2)
and have been fixed in:
>= 3.
16.0-55.74 (Zentyal 4.1)
and
>= 3.
19.0-39.44 (Zentyal 4.2)
Don't get me wrong a re-occurrence of this 'ip' bug is definitely possible, and then only you have tested 3.19.0-53 towards that 'ip' bug.
But when I simply type this into my commandline:
██ root@dcrc-dcx1:/var/log
██ 13:31:03 ᛤ dpkg --list | grep linux-image
rc linux-image-3.19.0-25-generic 3.19.0-25.26~14.04.1 amd64 Linux kernel image for version 3.19.0 on 64 bit x86 SMP
rc linux-image-3.19.0-39-generic 3.19.0-39.44~14.04.1 amd64 Linux kernel image for version 3.19.0 on 64 bit x86 SMP
rc linux-image-3.19.0-41-generic 3.19.0-41.46~14.04.2 amd64 Linux kernel image for version 3.19.0 on 64 bit x86 SMP
rc linux-image-3.19.0-42-generic 3.19.0-42.48~14.04.1 amd64 Linux kernel image for version 3.19.0 on 64 bit x86 SMP
ii linux-image-3.19.0-43-generic 3.19.0-43.49~14.04.1 amd64 Linux kernel image for version 3.19.0 on 64 bit x86 SMP
ii linux-image-3.19.0-47-generic 3.19.0-47.53~14.04.1 amd64 Linux kernel image for version 3.19.0 on 64 bit x86 SMP
ii linux-image-3.19.0-49-generic 3.19.0-49.55~14.04.1 amd64 Linux kernel image for version 3.19.0 on 64 bit x86 SMP
ii linux-image-3.19.0-51-generic 3.19.0-51.58~14.04.1 amd64 Linux kernel image for version 3.19.0 on 64 bit x86 SMP
ii linux-image-3.19.0-56-generic 3.19.0-56.62~14.04.1 amd64 Linux kernel image for version 3.19.0 on 64 bit x86 SMP
ii linux-image-3.19.0-58-generic 3.19.0-58.64~14.04.1 amd64 Linux kernel image for version 3.19.0 on 64 bit x86 SMP
rc linux-image-extra-3.19.0-25-generic 3.19.0-25.26~14.04.1 amd64 Linux kernel extra modules for version 3.19.0 on 64 bit x86 SMP
rc linux-image-extra-3.19.0-39-generic 3.19.0-39.44~14.04.1 amd64 Linux kernel extra modules for version 3.19.0 on 64 bit x86 SMP
rc linux-image-extra-3.19.0-41-generic 3.19.0-41.46~14.04.2 amd64 Linux kernel extra modules for version 3.19.0 on 64 bit x86 SMP
rc linux-image-extra-3.19.0-42-generic 3.19.0-42.48~14.04.1 amd64 Linux kernel extra modules for version 3.19.0 on 64 bit x86 SMP
rc linux-image-extra-3.19.0-43-generic 3.19.0-43.49~14.04.1 amd64 Linux kernel extra modules for version 3.19.0 on 64 bit x86 SMP
ii linux-image-extra-3.19.0-47-generic 3.19.0-47.53~14.04.1 amd64 Linux kernel extra modules for version 3.19.0 on 64 bit x86 SMP
ii linux-image-extra-3.19.0-49-generic 3.19.0-49.55~14.04.1 amd64 Linux kernel extra modules for version 3.19.0 on 64 bit x86 SMP
ii linux-image-extra-3.19.0-51-generic 3.19.0-51.58~14.04.1 amd64 Linux kernel extra modules for version 3.19.0 on 64 bit x86 SMP
ii linux-image-extra-3.19.0-56-generic 3.19.0-56.62~14.04.1 amd64 Linux kernel extra modules for version 3.19.0 on 64 bit x86 SMP
ii linux-image-extra-3.19.0-58-generic 3.19.0-58.64~14.04.1 amd64 Linux kernel extra modules for version 3.19.0 on 64 bit x86 SMP
ii linux-image-generic-lts-vivid 3.19.0.58.41 amd64 Generic Linux kernel image
██ root@dcrc-dcx1:/var/log
██ 13:31:11 ᛤ
Then I don't even get offered a linux-image-3.19.0-53-generic. There's only a linux-image-3.19.0-51-generic and a linux-image-3.19.0-56-generic. (I have both installed in my system as you see). Probably you mean 3.19.0-51. So I just want to make sure, that we are all on the same page, and not mistaken by a kernel version mix up.
So now -56 and -49 have been tested towards the 'ip' bug by hotsummer55 and Carlos. And they didn't find any issues on their system.
But here one time all affected versions of the 'CPU soft lockup' bug, we are dealing with in this forum thread, as far as I know and carried together quickly:
linux-image-3.19.0-49 (e.g.
https://tracker.zentyal.org/issues/4977 , in this forum thread and by my own experience )
linux-image-3.19.0-51 (in this forum thread and by my own experience)
linux-image-3.19.0-56 (in this forum thread and by my own experience)
and Carlos is currently 'long-term'
testing linux-image-3.19.0-58, and finding indirectly out for us, if it is safe to switch back to the main kernel upstream.
I don't know the background of your Zentyal system, if you upgraded from Zentyal 4.1 with kernel 3.
16.0-
53 or ran it with 3.
19.0-
37, which is by the way also not available among my installable kernels, but then definitely yes, it was affected by the 'ip' bug.
So to quote you:
[..] but on any versions with the bug it just loops and never exits. Zentyal must use this command somewhere and after a while it eats up all CPU and memory resources and results in the CPU soft hang.
Quick way to test it instead of waiting a week for Zentyal to crap out.
and:
The 'ip route ls' command I mentioned earlier has worked for me to test that the bug exists or does not in a given kernel.
and to quote me:
Na' sorry, I don't think, that your mentioned bug https://bugs.launchpad.net/ubuntu/+source/linux-lts-utopic/+bug/1514785 has got anything to do with it.
So for me everything seems to speak against the theory, that the 'CPU soft lockup' bug, we're having issues with, in common has anything to do with the 'ip' bug, you experienced with your system(s). I'd just like to avoid following down a wrong path. That's all.
By the way you are running currently definitely a bug affected kernel version with 3.19.0-49. But 9 days is great, I never made it that long.
But I would love to have verified:
- that the bug is gone
- and finding a quick test to verify, if a system is affected by this bug or not
So the only most plausible test procedure seems to be at the moment to bring as much concurrent user activity on the system as possible, which is very semi-optimal.
And I am very sorry for the fact, that I can't test by myself.
But if I risk any further inconvenience on that system probably my head gets chopped of.
I mean I have 2x Zarafa (not to be mistaken with Zentyal) on CentOS servers running virtualized on KVM since middle of 2011, ticking like a Switzer clockwork, and never experienced any issues, no update issues, works like a charm. Only through the cat and mouse game caused by MS Office updates, which lead to problems with MS Outlook's connector compatibility, but was always fixed immediately by Zarafa with a client-connector update. But that's also only client-sided and has nothing to do with the server itself.
Since Zarafa announced to not to support officially MS Outlook as Email/Groupware client anymore, Zentyal seems to be the only alternative, to set up something beside the cost intensive MS licenses trap.
I tested SoGO 3 (
http://sogo.nu/ ) as well in the beginning of the year... email fine, groupware functionality stuffed up with MS Outlook, so that I won't really recommend to use it productive.
Since 2 months it is a nightmare with the Zentyal system, every morning system checks and to evaluate, if the traffic still flows.
Zentyal is on a good way, that's for sure... But this bug costs really nerves.
It would be great, if Zentyal would give away a free commercial test lab license to play around with for such purposes, while being subscripted and maintaining a productive system. That'll be great.