Slashdot Mirror
Linux Kernel 2.6.32 LTS Reaches End of Life In February 2016 (softpedia.com)
An anonymous reader writes: The oldest long-term supported Linux kernel branch finally reaches end of life next month, but before going into the deepest darkest corners of the Internet, it just dropped one more maintenance release, Linux kernel 2.6.32.70 LTS. Willy Tarreau dropped the news about the release of Linux kernel 2.6.32.70 LTS on January 29, 2016, informing all us that this will most likely be the last maintenance release in the series, as starting with February 2016 it will no longer be supported with security patches and bugfixes. Linux 2.6 first came out in December, 2003, and 2.6.16 (the first long-term release) in March 2006.
What happens to RHEL6?
EL6 will still be supported by Red Hat and Scientific Linux for many years to come.
There are alternatives, like Gentoo, but for inexplicable reasons, Gentoo has dropped support for kernel 3.2, which is currently the kernel with the longest remaining support (until May 2018).
4.4, the second most LTS, is too bleeding edge for many. If the goal is to keep a system with max uptime, but still get critical kernel fixes if and only if needed, the best bet might be to stay at EL6 for now.
Please no. The swallowing of stderr makes it very difficult to troubleshoot startup problems. Just today I had a simple problem that was very hard to find because of systemd:
# systemctl start mongod ; echo $?
0
# journalctl -u mongod
Jan 30 20:58:29 storage3.maui.ascentis-prod.com systemd[1]: Starting SYSV: Mongo is a scalable, document-oriented database....
Jan 30 20:58:29 storage3.maui.ascentis-prod.com runuser[5767]: pam_unix(runuser:session): session opened for user mongod by (uid=0
Jan 30 20:58:29 storage3.maui.ascentis-prod.com mongod[5760]: Starting mongod: [FAILED]
Jan 30 20:58:29 storage3.maui.ascentis-prod.com systemd[1]: mongod.service: control process exited, code=exited status=1
Jan 30 20:58:29 storage3.maui.ascentis-prod.com systemd[1]: Failed to start SYSV: Mongo is a scalable, document-oriented database.
Jan 30 20:58:29 storage3.maui.ascentis-prod.com systemd[1]: Unit mongod.service entered failed state.
Jan 30 20:58:29 storage3.maui.ascentis-prod.com systemd[1]: mongod.service failed.
Notice starting it exited with no error, and there's no clue as to what happened in the journal!
They already do that. The 2.6.32 kernel that you get in RHEL 6 is not exactly the same 2.6.32 that you get from kernel.org. There are many backported features already implemented that the upstream kernel does not include.
Did you have a /var/lib/mongo/mongo.lock file? If so, the problem was your own fault.
You are correct. That was the problem, but I still don't think systemd should have exited with a 0 (no error) or swallowed the log message that clearly stated the problem. When I ran "sudo mongod mongod -f /etc/mongod.conf" the problem was clearly output to the console. After deleting the lock file, systemd was able to start MongoDB.
I've seen this problem on dozens of servers since we have nearly 300 MongoDB instances. systemd makes life much harder.
systemctl start mongod
Well there's your problem, you've mangled your languages. If you'd used:
systemctl start mondieu
you'd have got the response you were expecting:
# Bonjour, je m'appelle Linus.
Dice no longer own Slashdot.
Here, let me get you a paper towel or something for you to clean yourself up with--you look a bit foolish with all that foam hanging from your mouth.
Il n'y a pas de Planet B.
or swallowed the log message that clearly stated the problem
Sounds like someone hasn't setup systemd to their liking. In it's most verbose form journald will capture more and log more than any previous system including saving outputs from the console that previously were lost and capturing messages before syslog starts.
But you need to read the manual first, and if you don't like the defaults complain to the maintainer of your distribution, and has nothing to do with systemd itself which will only swallow logs if you tell it to.
The DEFAULT drops errors logged from the historical source errors are reported to.
That's FUCKING STUPID.
It's like putting a land mine in a dog owner's yard, then telling him he should have had a bunch of military engineers sweep his yard for mines before his dog got blown to bits.
NO YOU FUCKING MORON YOU DON'T PLACE THE MINES IN THE FIRST FUCKING PLACE!!!!!
I still run an old Ubuntu LTS install with Linux 2.6.32, but that is mostly because so that I would not have to run a Ubuntu version with that abomination called "Unity" or Gnome 3. I could not see that Ubuntu had offered any upgrade path to another LTS release that would not force any of that crap upon me.
My mom runs 10.04 and is a long way away, so I tested in a VM
do-release-upgrade
Which brought the VM to 12.04, then I ran it again, bringing the VM to 14.04.
Then something like
sudo apt-get install mate-desktop
And it worked. I did the entire process multiple times to be sure, and documented it on a web site somewhere.
One issue was in trying to remove Unity via sudo apt-get remove unity.
In one instance it caused an issue, in another it worked. Might have been a mistake I made.
But there is an update path available.
also did not want to get a system that was a mix of installs from different sources.
I did have to add the Mate repo if I recall, but they're pretty trust-worthy; I wouldn't consider it problematic.
Worth a try!
9 out of 10 times when something goes wrong in your system it's your own damn fault. That's what logs are for, to inform you where you made the mistake.
By your logic, the only output we should get is a segfault to show that the program barfed, for only then it's the programmer's fault and for everything else, well, sucks to be you, why did you make that mistake?
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.