GNOME Bugzilla – Bug 593775
uses inotify_init1 unconditionnally
Last modified: 2009-09-23 16:52:48 UTC
Created attachment 142219 [details] [review] Fall back to inotify_init if inotify_init1 does not work inotify_init1 was added in the 2.6.27 kernel, and currently gio uses it unconditionnally at runtime if it was found in the headers at build time. However we like to support some older kernel versions (those present in the previous stable release), so this breaks at runtime.
Good catch, and it also explains a Midori segfault I ran into on an embedded platform (the segfault was caused by broken Midori error handling triggered by this glib bug). Matthias, you broke it between 2.20.3 and 2.20.4. Please apply the fix for 2.20 and master.
No, I didn't 'break' it. I simply decided that it makes more sense to require a reasonably new kernel when running a new glib.
I think we should take this patch; this scenario will arise when say you want to run Maemo scratchbox (which uses a chroot) on an older system like RHEL 5, and that is something that I think is quite useful for the GNOME tools to support.
(In reply to comment #2) > No, I didn't 'break' it. I simply decided that it makes more sense to require a > reasonably new kernel when running a new glib. Some remarks on this: - "reasonably new kernel" means in this case < 1 year old. - Why fiddling with kernel requirements done in the middle of a stable series? - Why was it not mentioned it in the NEWS for 2.20.4? - It was therefore also not mentioned in the NEWS for GMAE 2.26.3, and considering the old kernels sometimes used on embedded devices, I'd have stayed aligned with GMAE 2.26.2 on an embedded platform I'm maintaining if I'd have known about this issue.
(In reply to comment #3) > I think we should take this patch; this scenario will arise when say you want > to run Maemo scratchbox (which uses a chroot) on an older system like RHEL 5, > and that is something that I think is quite useful for the GNOME tools to > support. There's no Scratchbox specific problem here. The problem appears when your libc supports inotify_init1(), but your kernel does not. Cross-compiling with a recent toolchain using the toolchain libc for an embedded device with a 1 year old kernel is a scenario that is affected, but that's unrelated to whether you use Scratchbox or traditional cross-compiling. This bug report comes from Debian, and Debian 5.0 -> 6.0 upgrades are actually one major scenario where users will run into problems.
(In reply to comment #5) > (In reply to comment #3) > > I think we should take this patch; this scenario will arise when say you want > > to run Maemo scratchbox (which uses a chroot) on an older system like RHEL 5, > > and that is something that I think is quite useful for the GNOME tools to > > support. > > There's no Scratchbox specific problem here. Agree, I was just trying to give a very GNOME-related example. Another one is the Fedora autobuilders which are EL5 and create mock chroots IIRC. (Now I do think the Debian upgrade process is busted because live major OS upgrades while the user is logged in is just never going to be more than 92% reliable, but that's another story)
(In reply to comment #6) > (Now I do think the Debian upgrade process is busted because live major OS > upgrades while the user is logged in is just never going to be more than 92% > reliable, but that's another story) This bug is completely unrelated to the upgrade process. It is about being able to run current applications using a kernel from the previous release, and running applications from the previous release using a current kernel. There are so many cases where this happens, do we need to list them all?
(In reply to comment #6) > (In reply to comment #5) > > (In reply to comment #3) > > > I think we should take this patch; this scenario will arise when say you want > > > to run Maemo scratchbox (which uses a chroot) on an older system like RHEL 5, > > > and that is something that I think is quite useful for the GNOME tools to > > > support. > > > > There's no Scratchbox specific problem here. > > Agree, I was just trying to give a very GNOME-related example. > > Another one is the Fedora autobuilders which are EL5 and create mock chroots > IIRC. AC_CHECK_FUNCS(inotify_init1) should work correctly in all chroot environments. > (Now I do think the Debian upgrade process is busted because live major OS > upgrades while the user is logged in is just never going to be more than 92% > reliable, but that's another story) The problem is bigger: For this problem here it would be required to reboot to a more recent kernel immediately after upgrading. If you do not want/can reboot immediately, or if you do not have a working recent kernel, that's a real problem. And where I ran into this issue was actually not on Debian, but on an embedded device for which I do not have a kernel >= 2.6.27 available at the moment.
Comment on attachment 142219 [details] [review] Fall back to inotify_init if inotify_init1 does not work Feel free to commit the patch; also to the stable branch. I dislike adding ifdefs for supporting old, broken stuff. But in this case, the ifdef is already there...
Committed to master (cc4970c) and glib-2-20 (86f5a93).