dbus fails to start on FUSE filesystems

[Rudd-O]

Binary package hint: dbus

Here's the upstream bug report

https://bugs.freedesktop.org/show_bug.cgi?id=15922

The net effect is that people using FUSE root filesystems or whose /var is in FUSE filesystem can't use dbus or any dbus applications.

The bug hasn't been addressed in intrepid ibex at all. This bug should be addressed in both distributions.

It has a patch for which I have created an ubuntu build. Will upload it next.

[Johnp-redhat (johnp-redhat)]

I have a feeling this has to do with the non-caching userdb code path. Please look at bug #15588 and compile with caching on to see if this issue is fixed. For reference bug #15589 has the noncaching issue. Basically userinfo structures need to become objects with references.

[jwyzer (johnwyzer)]

I recompiled with --enable-userdb-cache but that did not solve the problem. :-(

[Johnp-redhat (johnp-redhat)]

did you apply the patch also? If not then that flag won't actually do anythin. That was part of the bug.

[jwyzer (johnwyzer)]

Yes, I applied that patch :-(

[jwyzer (johnwyzer)]

is there anything I can do to help finding the problem here?

[jwyzer (johnwyzer)]

Having a look at valgrind's
--snip--
Thread 1: status = VgTs_Runnable
==3603== at 0x4822B8E: realloc (vg_replace_malloc.c:429)
==3603== by 0x32641: dbus_realloc (dbus-memory.c:601)
==3603== by 0x32E69: reallocate_for_length (dbus-string.c:364)
==3603== by 0x32F14: set_length (dbus-string.c:404)
==3603== by 0x332B2: _dbus_string_lengthen (dbus-string.c:872)
==3603== by 0x334DC: append (dbus-string.c:1020)
==3603== by 0x33572: _dbus_string_append (dbus-string.c:1050)
==3603== by 0x3C8B2: _dbus_directory_get_next_file (dbus-sysdeps-util-unix.c:761)
==3603== by 0x3E63: update_directory (activation.c:577)
==3603== by 0x41E0: bus_activation_new (activation.c:771)
==3603== by 0x6602: process_config_every_time (bus.c:497)
==3603== by 0x68E2: bus_context_new (bus.c:615)
==3603== by 0x1B2A1: main (main.c:443)
--snap--

I did a

--snip--

$ gdb /usr/bin/dbus-daemon
GNU gdb 6.7.1-debian
Copyright (C) 2007 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu"...
Using host libthread_db library "/lib/libthread_db.so.1".
(gdb) break _dbus_directory_open
Breakpoint 1 at 0x3c5ee: file dbus-sysdeps-util-unix.c, line 637.
(gdb) break _dbus_directory_get_next_file
Breakpoint 2 at 0x3c756: file dbus-sysdeps-util-unix.c, line 727.
(gdb) run --session --nofork
Starting program: /usr/bin/dbus-daemon --session --nofork
Breakpoint 1 at 0x3c5db: file dbus-sysdeps-util-unix.c, line 630.
Breakpoint 2 at 0x3c743: file dbus-sysdeps-util-unix.c, line 720.
Warning:
Cannot insert breakpoint 1.
Error accessing memory address 0x3c5db: Input/output error.
Cannot insert breakpoint 2.
Error accessing memory address 0x3c743: Input/output error.

--snap--

Any idea what that is?

[jwyzer (johnwyzer)]

Created an attachment (id=16746)
changes readdir_r buffer for fuse file system (and maybe others)

[jwyzer (johnwyzer)]

With my latest attachment / patch, dbus works for me with the root file system on fuse.
It was a bit odd to track down - it turned out that in the calculation of the buffer for readdir_r the maximum length for a filename had a value of 0.

[jwyzer (johnwyzer)]

hmm. any opinion on the patch and/or the problem?
Feedback appreciated.

[Rudd-O (rudd-o)]

Binary package hint: dbus

HEre's the upstream bug report

https://bugs.freedesktop.org/show_bug.cgi?id=15922

It has a patch for which I have created an ubuntu build. Will upload it next.

[Rudd-O (rudd-o)]

Oh, the patch will eventually get into dbus trunk, but for the moment it would be wise to consider the tens of thousands of people using ntfs3g and tens of people using zfs as root filesystem, for which dbus fails now.

[Rudd-O (rudd-o)]

Here is the debdiff. It's against hardy-proposed, which I think should also be shoved into hardy-updates.

Now it's just a matter of going forward with the publication of the fix :-)

[Rudd-O (rudd-o)]

Oh, this debdiff should also be mashed into intrepid ibex. But I'm not running it, so I can't do much about it. The bug fix is backported from dbus 1.2.x anyway.

[James Westby (james-w)]

Hi,

The procedure for getting a stable release update can be seen
at

  http://wiki.ubuntu.com/StableReleaseUpdates

Thanks,

James

[Rudd-O (rudd-o)]

I read that page before submitting the bug. I just wanted to file it so it doesn't get lost -- I'm sure other people are willing to pick up where I left off, and I just wanted to make it easier for the intrepid team to incorporate this bugfix. Currently I'm battling a bug in dpkg-source that won't let it work at all. I reported it recently.

Maybe after I've fixed dbus and moved to cvs fuse, maybe then I can pick this up again. But I'm definitely not installing intrepid ibex just to make a package for it.

[DaveAbrahams (boostpro)]

I can confirm this problem and that the patch fixes it.

FWIW, *my* only FUSE filesystem is mounted at /usr

[DaveAbrahams (boostpro)]

I can confirm that this bug also affects anyone who has /usr on a FUSE filesystem. Please integrate Rudd-O's patch.

[Hp-pobox (hp-pobox)]

This code requires some care:
http://womble.decadentplace.org.uk/readdir_r-advisory.html

There is no indication in the standard that fpathconf should ever be returning 0:
http://www.opengroup.org/onlinepubs/009695399/functions/pathconf.html

Surely this is a bug in fuse.

Not sure falling back to PATH_MAX is safe. In fact I think it isn't. readdir_r will smash the stack if the filename is longer than the buffer...

[Scott James Remnant (Canonical) (canonical-scott)]

See this most recent comment from Havoc:

------- Comment #11 From Havoc Pennington 2009-03-01 08:42:50 PST [reply] -------

This code requires some care:
http://womble.decadentplace.org.uk/readdir_r-advisory.html

There is no indication in the standard that fpathconf should ever be returning
0:
http://www.opengroup.org/onlinepubs/009695399/functions/pathconf.html

Surely this is a bug in fuse.

Not sure falling back to PATH_MAX is safe. In fact I think it isn't. readdir_r
will smash the stack if the filename is longer than the buffer...

[Martin Pitt (pitti)]

This should be fixed by 1.4.6 according to upstream NEWS.

dbus (1.4.6-1ubuntu1) natty; urgency=low

  * Merge with Debian unstable. Remaining Ubuntu changes:
    - Install into / rather than /usr.
    - debian/dbus.postinst: Use upstart call instead of invoking the init.d
      script for checking if we are already running.
    - Add debian/dbus.upstart.
    - 0001-activation-allow-for-more-variation-than-just-system.patch,
      0002-bus-change-systemd-activation-to-activation-systemd.patch,
      0003-upstart-add-upstart-as-a-possible-activation-type.patch,
      0004-upstart-add-UpstartJob-to-service-desktop-files.patch,
      0005-activation-implement-upstart-activation.patch: Patches from Scott
      James Remnant to implement Upstart service activation. Not upstream.
    - 20_system_conf_limit.patch: Increase max_match_rules_per_connection for
      the system bus to 5000 (LP #454093)
    - 81-session.conf-timeout.patch: Raise the service startup timeout from 25
      to 60 seconds. It may be too short on the live CD with slow machines.
  * debian/rules: Fix creation of /usr/lib/libdbus-1.so symlink.
  * debian/libdbus-1-dev.install: Put back .pc.

 -- Martin Pitt <email address hidden> Thu, 24 Feb 2011 16:41:36 +0100