[hardy] gdmsetup cause intensive disk activity and take a very long time to open

Confirmed, same happens to me.

GdmSetup doesn't work on my new fresh installation of Ubuntu 8.04 Beta. Symply it doesn't start.

Confirmed for 8.04 beta. It actually causes my hard disc to make lots of noise; a bit like the heads are moving backwards and forwards rapidly as if they're looking for something. Launching from the terminal gives (five times over):

gdmsetup[26218]: CRITICAL: Error opening file: No such file or directory

My apologies, I probably shouldn't have changed the status as I'm not the developer - returning status to 'new'.

Backtrace attached.

snifer@snifer-laptop:~$ dpkg -l | grep gdm
ii gdm 2.20.4-0ubuntu2 GNOME Display Manager
ii gdm-dbgsym 2.20.4-0ubuntu2 debug symbols for package gdm
ii ubuntu-gdm-themes 0.26 Ubuntu GDM themes

Thanks for your report, it seems that there's something broken on your installation, is this an upgraded box or a fresh install? "gdmsetup[10736]: CRITICAL: Error opening file: No such file or directory" can you verify that you have the gdmsetup.glade file on the install path? thanks.

I have a clean installation of Hardy bèta. With all updates including today's.

What happens now is this:
:~$ gksudo gdmsetup
gdmsetup[8070]: CRITICAL: Error opening file: No such file or directory

But strangely, the login screen changer does start now! ??? How can this be?

By the way, there is no gdmsetup file in /usr/bin.

Pedro: It's a fresh Hardy beta install, all updates applied. I've applied the following updates since my last post (from Synaptic's history):

Commit Log for Thu Mar 27 13:46:03 2008

Upgraded the following packages:
gnome-utils (2.20.0.1-1ubuntu2) to 2.20.0.1-1ubuntu3
gstreamer0.10-plugins-good (0.10.7-2) to 0.10.7-3
hal (0.5.11~rc2-1ubuntu4) to 0.5.11~rc2-1ubuntu5
initscripts (2.86.ds1-14.1ubuntu41) to 2.86.ds1-14.1ubuntu42
libhal-storage1 (0.5.11~rc2-1ubuntu4) to 0.5.11~rc2-1ubuntu5
libhal1 (0.5.11~rc2-1ubuntu4) to 0.5.11~rc2-1ubuntu5
libpolkit-dbus2 (0.7-2ubuntu4) to 0.7-2ubuntu5
libpolkit-grant2 (0.7-2ubuntu4) to 0.7-2ubuntu5
libpolkit2 (0.7-2ubuntu4) to 0.7-2ubuntu5
libusplash0 (0.5.16) to 0.5.17
locales (2.7.9-3) to 2.7.9-4
network-manager-gnome (0.6.6-0ubuntu1) to 0.6.6-0ubuntu2
policykit (0.7-2ubuntu4) to 0.7-2ubuntu5
sysv-rc (2.86.ds1-14.1ubuntu41) to 2.86.ds1-14.1ubuntu42
sysvutils (2.86.ds1-14.1ubuntu41) to 2.86.ds1-14.1ubuntu42
usplash (0.5.16) to 0.5.17

Now, as Pjotr12345 reported (considering the updates applied), gdmsetup is now shown when loaded, but I still get the "No such file..." message several times.

snifer@snifer-laptop:~$ sudo updatedb
snifer@snifer-laptop:~$ locate gdmsetup.glade
/usr/share/gdm/gdmsetup.glade

I think I found the problem: gdmsetup looks for .gtk-bookmarks in your home directory, but, since it's loaded as root, it looks for the file in /root and it doesn't exists there. To the people with this problem, please try to copying this file from your home directory to /root to confirm that this is the problem and report your results. Now gdmsetup should load without the "No such file..." messages, or at least it did for me.

I've just tested loading gdmsetup (with 'gksu gdmsetup' command) without moving .gtk-bookmarks, and it loads fine without any error messages now. I looked in the /root directory (as root) to see if .gtk-bookmarks had been created by some other method, but it still doesn't exist there.

Having said that, on previous attempts I would get exactly what Pjotr12345 reported.

I too have a clean Hardy install with all updates applied.

gdmsetup doesn't load for me. I have a system that was upgraded from gutsy and it definitely worked in gutsy.

woah! I also noticed crazy disc activity. After about 2 minutes it eventually started

David Grant : Is your Hardy up-to-date? I can also still reproduce the high disk activity bug and the VERY long delay before gdmsetup opens up. If you can reproduce this with latest Hardy, can you open a new bug report and subscribe me (saivann)?

Yes, my Hardy is very up-to-date. Can't we just remove the dupe status instead of opening a new bug?

David, please post the output of

 dpkg -l | awk '/libgnomeui/ {printf "%-3s %-20s %s\n",$1,$2,$3}'

david@centurion:~$ dpkg -l | awk '/libgnomeui/ {printf "%-3s %-20s %s\n",$1,$2,$3}'
ii libgnomeui-0 2.22.1.0-0ubuntu1
ii libgnomeui-common 2.22.1.0-0ubuntu1
ii libgnomeui32 1.4.2-37ubuntu1
ii libgnomeuimm-2.6-1c2a 2.22.0-1

Thanks a lot

Confirmed with a clean Hardy RC install.

Also confirmed with a clean installation of Hardy Release Candidate.

I hope this will be fixed in time for the final release.

This bug is a consequence of a longstanding upstream bug:

http://bugzilla.gnome.org/show_bug.cgi?id=164786 (gdm frontend runs entirely as root)

Notice that this upstream bug was opened in 2005, currently shows an assigned status, a priority=high and a severity=major.

This bug has been the source of annoyances for ubuntu users for a long time as can be seen by
https://bugs.launchpad.net/ubuntu/+bug/27156

The reason it manifests itself in a more direct fashion now is due to tracker. The delay you are seeing is related with the indexing tracker does the first time it is run for a user.

ps aux | grep root shows gvfs and trackerd processes running as root, that started just after running gksu gdmsetup in my normal account.

ls -al /root/.config/tracker
ls -al /root/.local/share/tracker
ls -al /root/.gvfs

also confirms this.

Thanks for all your work. Could tracker be disabled by default for the root user?

Also confirm this with a clean install of Hardy final release. It takes a long time to load gdmsetup and the intensive ticking of the hard drive while loading.

Confirmed for a clean installation of Hardy final. Can this be fixed in 8.04.1?

Confirmed on a cleanly installed Hardy AMD64.

Confirmed again on a clean installation of Hardy final.

As an extra twist, "Login Window" is not displayed on the "Administration" menu, although according to the menu editor it is there.

Thanks for your participation but please don't confirm a bug more than once, one confirmation is enough. We should keep bug reports as short and relevant as possible to help developers.

Saïvann Carignan wrote:
> Thanks for your participation but please don't confirm a bug more than
> once, one confirmation is enough. We should keep bug reports as short
> and relevant as possible to help developers.

I thought it would help to have information that the problem is not a
quirl of a single physical system.

Ian

the issue seems to be due to libtracker, it's trying to use tracker but should not autostart it if it's not running

I really have to ask now (out of genuine curiosity), wtf does tracker have to do with gdm (or even, gdmsetup for that matter)? isn't it a user-level app anyway? what is there to index over there? (I guess we are talking about the tracker indexing/search tool)

I just upgrade from 7.10 to 8.04 LTS yesterday.
The gdmsetup runs normally yesterday before I disable the indexing.
When I run the gdmetup, it shows no error message, but Sebastien says, it triggers a trackerd up to search for something (I don't know).
So, if I run the indexing, then gdmsetup runs without any delay or disk busy.
My question is : is the indexing so important in this new version gdm? what's the possible impact to disable it? (especially on this gdmsetup tool)

ps: I am a totally newbie, if I ask the wrong question here, please feel free to give comments.

gdm doesn't use tracker directory, the dialog uses gtk fileselector widgets which have a search files entry in the sidebar, that feature is using tracker when available, now when the dialog is create the widgets are initialized, gtk uses libtracker to know if tracker is available and somewhat it gets started, not sure if that's gtk using libtracker wrongly or a libtracker bug though

calling a single method in libtracker will trigger launch of trackerd via dbus activation.

This cannot be fixed at the tracker end as there is no way to turn off said activation - its an intrinsic property of all dbus services

In this particular case the best we can do is prevent indexing by tracker if activated as root

that's something several users complained about and why we stopped building nautilus using it, the api to query if tracker is running should not be using dbus which trigger the autoactivation then but rather using a lock file on the disk or something which indicates if tracker is running or not

do you know why tracker is doing any work at all there since the watching and indexing key are not enable on hardy?

We agreed to just disable the automagic tracker activation over dbus by not installing the .service file any more.

that's not a gdm bug

I get this same bug in the release version.

Yes, I also get this on the Final release/production version of Hardy.

Seems to me that whatever is causing this should be fixed or at a minimum something should be put in place to tell the user what is going on when they initially click on the login window function and it takes several minutes to open. And this fix should be put in place so that it is incorporated into the installation process of the O/S (i.e. a revamped ISO image of Hardy needs to be offered, not only to fix this but numerous other problems), so that new coming users of Ubuntu are not PUT OFF by these type of bugs.

Thanks.

Confirmed the bug... and removing libtracker-gtk0 fixed it. Thanks

Does this mean that every time I do an installation of Hardy on a new computer that this is just 1 more thing that I have to put on my either mental or written listing to change in order to get this to work correctly or will this libtracker-gtk0 package be fixed so that it willNOT install during the installation of the O/S by default ?

Thanks.

libracker-gtk0 is needed for Tracker, which *is* installed by default. It's
just a bug that needs to be fixed in it, I guess.

However not everyone also has this problem either. I've asked about, and
others don't have it.

Sebastien, is a proposed solution available for this bug? I think this is very worthwhile to have fixed in hardy, though I doubt that 8.04.1 is a realistic target here; maybe we should be targeting 8.04.2?

trivial change is to not install the dbus service so tracker will not been automatically started when not required

Accepted into -proposed, please test and give feedback here

Sebastien's proposed patch works for me, though I'm not sure whether it sacrifices any functionality of tracker in any way, i.e. whether tracker needs this "autostart" feature under any circumstances.

there is an autostart installed which run it when the session starts, there is no reason the autoactivation should be required

Tested on a clean Hardy installation and on a old Hardy installation and it seems to work perfectly. I don't really use tracker so I don't know if there is side effects caused by this patch in tracker.

I tested it on a vanilla install of 8.04, then enabled hardy-proposed,
updated, and the fix worked okay.

Copied to hardy-updates.

Needs to be fixed in Intrepid ASAP.

This feels as the wrong solution to me. Many apps may assume that Tracker will start by dbus activation. The 'right' fix is to make the Tracker backend of the filechooser not launch Tracker, merely see if it is installed (check if it is dbus activatable)[1]. Then if the user enters a query then Tracker will be launched by dbus activation as it should.

[1]: Like the deskbar Tracker module does. Should be easy to port to C.

the issue is that checking if tracker is running using libtracker will active the index, that's creating issue for users who desactivated the service because they don't use it and that's not giving any useful informations anyway because the indexer starts

I see. So either use dbus directly without libtracker, add a peek_tracker_running() method to libtracker, or disable dbus activation. The simple solution is of course understandable for Hardy, but may break other apps (the deskbar handler relies on the activation file for instance). For intrepid a proper fix should be possible. DBus activation is indeed a double edged sword :-)

why do you think that applications starting tracker over dbus is a good idea? users don't expect to get their system to start doing lot of io for the day just because they used deskbar-applet or nautilus search, especially when they disabled the tracker autostart to avoid that. autostarting tracker when using deskbar-applet is also a bad user experience because it'll always return an empty list which will lead the user to think the tool is just buggy, you really need to let time to index things before using it so autostarting it when you need datas is not something useful

I don't necessarily think that it is a good idea to autostart an
indexer. I am just pointing out that some apps rely on it. I say again
"DBus activation
is indeed a double edged sword" :-)

Is there any progress on this?

> Is there any progress on this?

Ok a fresh install of Intrepid alpha5, I didn't encountered the trouble.

To the best of my recall, I do not remember seeing this bug on version 8.04.1 of Hardy the last time I did a test installation of it. However, that HAS been quite a while back.

I do not yet use Hardy because, I still believe Gutsy is the most reliable release.

Thanks.

I just confirmed that this is still an issue in intrepid.

This bug was fixed in the package tracker - 0.6.6-2ubuntu1

---------------
tracker (0.6.6-2ubuntu1) jaunty; urgency=low

  * Merge from debian unstable, remaining changes:
    - debian/sysctl.d/30-tracker.conf:
      + add sysctl for increased inotify limits (broken out from procps).
    - debian/rules:
      + Enable sqlite external db instead of qdbm.
    - debian/control:
      + Do not build-depend on universe dependencies:
        libunac1-dev, libqdbm-dev.
      + add versionized dependency on procps
      + depend on python-gnome2-desktop (for patch 05_gnomedesktop.patch)
    - debian/tracker.py:
      + Added an apport hook to ignore tracker-extract crashes, since they
        are caused by setrlimit terminating tracker-extract when it raises
        it's cpu/memory limit.
    - In debian/tracker.install:
      + Install tracker.py in /usr/share/apport/package-hooks/
    - tracker-0.6.6/debian/tracker.postinst:
      + start procps to apply "sysctl.d/30-tracker.conf"
    - debian/patches:
      + email-crasher.patch: Patch by upstream, fix crash on mail indexing.
      + 03_dont_activate_indexing_and_watching.patch: don't active indexing nor
        watching as decided by the technical board
      + 02_no_kde_autostart.patch: Do not autostart trackerd in Kde, as they
        have strigi.
      + 04_Correct_spelling_of_additional.patch: spelling fixes
      + 05_gnomedesktop.patch: use python module gnomedesktop directly rather
        than deskbar.core.gnomedesktop python module
    - debian/tracker.install:
      + don't install the dbus service so tracker is not automatically
        started when other software try to see if it's already running
        (lp: #204770)
  * new recommends on odt2txt
  * drop o3read dependency (no longer in the archive)

tracker (0.6.6-2) unstable; urgency=low

  * debian/control
    - Add Build-Depends on pkg-config.
    - Add Vcs-* fields.
    - Replace Recommends on o3read with odt2txt.
  * debian/patches/01-secure_tmpdir.patch
    - Use mktemp to create a secure tmpdir for the msword filter.
      Thanks to Jon Dowland for the patch. Closes: #473733
  * Add symbols files for libtrackerclient0 and libtracker-gtk0.
  * debian/patches/02-static_keywords_reply.patch
    - Make _keywords_reply a static function to not export it in the public
      API.
  * debian/patches/03-prefer_odt2txt.patch
    - Use odt2txt to index OpenOffice documents. Closes: #478091

 -- Michael Vogt <email address hidden> Thu, 13 Nov 2008 15:34:51 +0100

Accepted into intrepid-proposed, please test and give feedback here. Please see https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

I tested tracker 0.6.6-1ubuntu5.1 from proposed and I can confirm that it fixes this bug. It is no longer activated by gdmsetup. Directories like /root/.cache/tracker, /root/.local/share/tracker and /root/.config/tracker are no longer created when launching gdmsetup, unlike version 0.6.6-1ubuntu5. Gdmsetup seems to work fine, and tracker was able to find files in my home directory.

This bug was fixed in the package tracker - 0.6.6-1ubuntu5.1

---------------
tracker (0.6.6-1ubuntu5.1) intrepid-proposed; urgency=low

  * debian/tracker.install:
    - don't install the dbus service so tracker is not automatically started
      when other software try to see if it's already running (lp: #204770)

 -- Michael Vogt <email address hidden> Thu, 27 Nov 2008 17:18:43 +0100