In above commt I added CHECK_C_SOURCE where fcntl(fd, F_DUPFD_CLOEXEC, 0); is used and we define HAVE_IB_F_DUPFD_CLOEXEC only if call succeeds. In InnoDB then we use #if defined(F_DUPFD_CLOEXEC) && defined(HAVE_IB_F_DUPFD_CLOEXEC). If that is not enough I do not know what to do.

danblack, as far as I can tell, nothing was merged yet. The compile-time check that you added in MDEV-8743 is still there:

#ifdef F_DUPFD_CLOEXEC

	int fd2 = fcntl(fd, F_DUPFD_CLOEXEC, 0);

#else

	int fd2 = dup(fd);

#endif

I agree with you that replacing the above compile-time check with a little more sophisticated compile-time check is not helping anyone who uses binary packages that were compiled on a newer kernel.

Theoretically, we could add a run-time check (an if before the #else), but then we would have to test that on an antiquated kernel, preferably in our continuous integration system.

In the end, it boils down to the MariaDB platform roadmap. https://mariadb.org/about/maintenance-policy/ does not say anything about underlying operating systems. I believe that we try to support all supported versions on all ‘relevant’ operating system platforms. According to https://wiki.centos.org/HowTos/EOL the support of CentOS 5 ended on March 31, 2017, more than 11 months before MDEV-8743 was pushed to the MariaDB code base. This would seem to confirm that nobody should be using a CentOS 5 kernel in production.

I agree marko, adding testing framework for unsupported kernels that happen to map to the policies of single VPS provider seems a little extreme. The source compile could work (if they use 2.6.18 headers) for these users but that may be beyond what I see as the normal demographic for GoDaddy users.

MDEV-16548 when/if it gets on the roadmap will incidentally fix this for those users by removing the code.

The oldest GNU/Linux distributions that MariaDB Corporation supports are as follows:

We also support ‘Generic Linux’, but I would expect that to refer to a reasonably recent kernel. Linux "kernel 2.6.32 was released on December 3, 2009 already.

The out-of-support Linux kernel 2.6.18 was released on September 20, 2006. Because it does not make sense to add a run-time check for an out-of-support Linux kernel that is more than 12 years old, I am closing this ticket as ‘Won’t Fix’.

Fixed in 10.5.