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.
Red Hat will back port fixes, just like they do with many, many packages.
The real "Libtards" are the Libertarians!
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.
I had no idea that Linux had a Windows XP mode.
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.
I agree, it doesn't really provide useful information on how to track down the issue. Dealing with syslog was a pain in the ass in some ways to track down problems associated with a particular daemon, but I'm not sure systemd solves the issue.
That said, I see a number of AC posts criticizing you for your views on systemd. It seems every night recently, a troll posts a bunch of AC comments in response to an early post, pretending to have a conversation with itself but contributing nothing of substance. Last night, it was claiming Facebook encourages gun violence and that AK-47s are sold in Facebook's parking lot. The night before, it was posting about how Republicans want people to die and kill people's family members who don't support Republicans. It's almost certainly a single troll who needs to be modded down to -1. Please take note, moderators, and mod the replies accordingly. And to the new management of Slashdot, if you see this, please consider banning the IPs associated with these crapfloods. Thanks!
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.
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. I also did not want to get a system that was a mix of installs from different sources.
My old Ubuntu has served me well for this time. Time to look around for some other distribution then... Mint?
BTW. At work I installed CentOS 6 on a brand new machine, this Thursday. I installed CentOS 7 first but gave it up because of Gnome 3.
"We mustn't be caught by surprise by our own advancing technology" -- Aldous Huxley
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.
Because it (still) points out there is an error? Did exit codes suddenly become deprecated?
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!!!!!
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.
The proper blame is on the mongodb developers since they are the ones who have created the defunct unit file for mongodb. It's not systemd that drops logs, it's mongodb that is configured to not produced any since it's launched with --quiet in the default unit file. Now this is probably done due to it starting as a SysVinit project and on SysVinit one would have do disable stderr since otherwise the console would get completely garbled, just that they forgot that systemd is not as stupid as the older init system.