After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 593775 - uses inotify_init1 unconditionnally
uses inotify_init1 unconditionnally
Status: RESOLVED FIXED
Product: glib
Classification: Platform
Component: gio
2.21.x
Other Linux
: Normal normal
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2009-09-01 09:55 UTC by Josselin Mouette
Modified: 2009-09-23 16:52 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Fall back to inotify_init if inotify_init1 does not work (615 bytes, patch)
2009-09-01 09:55 UTC, Josselin Mouette
accepted-commit_now Details | Review

Description Josselin Mouette 2009-09-01 09:55:55 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.
Comment 1 Adrian Bunk 2009-09-15 11:05:09 UTC
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.
Comment 2 Matthias Clasen 2009-09-16 00:41:46 UTC
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.
Comment 3 Colin Walters 2009-09-16 00:48:33 UTC
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.
Comment 4 Adrian Bunk 2009-09-16 06:07:37 UTC
(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.
Comment 5 Adrian Bunk 2009-09-16 06:21:45 UTC
(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.
Comment 6 Colin Walters 2009-09-16 15:07:38 UTC
(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)
Comment 7 Josselin Mouette 2009-09-16 15:22:51 UTC
(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?
Comment 8 Adrian Bunk 2009-09-16 16:13:33 UTC
(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 9 Matthias Clasen 2009-09-21 14:44:29 UTC
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...
Comment 10 Josselin Mouette 2009-09-23 16:52:48 UTC
Committed to master (cc4970c) and glib-2-20 (86f5a93).