Uh, works for me.  What is the new shortcut that you are setting the switch
workspace action to?  What distro are you running on?  Do you have any old
daemons running before you start Gnome (e.g. gconfd, bonobo-activation-server,
etc.)?  What version of Metacity and gconf are you running?  How reproducible is
this?

I was switching between <Mod4>Left and <Ctrl><Alt>Left (actually I'd like to
havet both -- <Mod4>Left is easier to type, but requires two hands as there is
only one <Mod4> on my laptop's keyboard).

The distro is Debian unstable.  I do not think I have any old daemons running --
usually I just boot, log in with KDM (I don't use GDM because of
http://bugzilla.gnome.org/show_bug.cgi?id=139757) and get my GNOME desktop.
I then tend to live in that desktop for a while (suspending and resuming the
laptop), and I also tend to do apt-get upgrades daily from Debian unstable
without restarting GNOME.

Metacity is version 2.8.1 (Debian package 1:2.8.1-4).  gconf is version 2.6.4-2.

<rant>
Why oh why does Bugzilla ask me for "Version details" and "Distribution" and
later just discard the data that I enter there, so that I have to answer these
questions again?
</rant>

The bug was reproducible 100% (I've tried 4 or 5 times) yesterday.

Note that if I go to Applications -> Desktop Preferences -> Windows and change
the key used for dragging windows around with the mouse, the change takes effect
immediatelly.  If I go to Keyboard Shortcuts and change the key for "Hide all
windows and focus desktop", the change takes effect immediatelly.  Ditto for
"Switch to workspace 1".  Ditto for "Switch to workspace on the left".

Wait a minute.  I am completely sure that this did not work for me yesterday.
I switched between <Mod4> and <Ctrl><Alt> three or four times (trying to
figure out which one was more convenient for me), and was wery frustrated when
the changes did not take effect and I had to restart metacity several times.

Bug 154006 is also unreproducible today, although when I switched from 8 to 10
and then from 10 to 12 workspaces on the next day, I also had to restart
metacity (both times -- I logged out and logged in once, and did killall
metacity the second time).  I suppose these bugs should be merged.

I've had some problems in the past with gconf clients not being notified
about configuration changes.  Symptoms used to include stick-it notes not
changing visibility when I click on the applet, and desktop theme switching
not working.  But the bug (mishandling of SIGHUP in gconfd) has been fixed
a while ago, and I haven't had any problems like that lately.

I've had gconf changes not take effect for me before when upgrading to a newer
version.  So I think I've seen the same thing (but I noticed with trying to
change different configuration options), but I'm really not sure where to refile
this bug.

As far as the bugzilla stuff...um, it's due to bug 152157--which I should be
shot for not fixing.

*** Bug 154006 has been marked as a duplicate of this bug. ***

See also bug 143152.

95% likely this is a dup of bug 143152, and it's just a general issue of gconf
notifications somehow stopping. I have no clue at all what could be causing it
though, and it's so unreproduceable we are probably screwed.

I do believe it happens, since we have a number of reports, I've even seen it
myself.

I wonder if it's metacity-specific or just specific to apps that are
long-running or something like that.

It happened again.  The full sequence of events is as follows: yesterday I
rebooted the laptop, logged in into a GNOME session, suspended the laptop.  This
morning I resumed it, ran the daily apt-get upgrade and decided to change
keyboard shortcuts again.  Metacity ignored my changes.  Changing the number of
workspaces does not work either.

gconf notifications do work for other applications, e.g. the sticky notes
applet.  Those are also long-running, but so far I have only observed this
problem in metacity.  Slight correction: I have seen similar problems with
other apps as well, but that was due to bug 148028 which has been fixed a
while ago.  Since then I've only seen problems with metacity.

If I killall -USR1 gconfd-2 I can see in syslog that gconf changes the value of
/apps/metacity/general/num_workspaces, but does not notify any listeners.  If
I click on the sticky notes applet icon, I can see that a listener is notified.

I cannot tell if this is a bug in metacity, or in gconf.

Among the packages that I upgraded today was evolution.  Its postinst script
does

     kill -s HUP `pidof gconfd-2` >/dev/null 2>&1 || true

SIGHUP used to trigger but 148028.  I will try restarting metacity and trying to
reproduce this bug by sending SIGHUP to gconfd.

I managed to reproduce the bug:

  1. killall metacity (so preferences start working again)
  2. killall -USR1 gconfd-2 (so I can see what's happening in syslog)
  3. play with the number of workspaces (to verify that notifications work)
  4. killall -HUP gconfd-2
  5. play with the number of workspaces (notifications continue to work for a
brief while)
  6. notice the "gconfd (...): Reloading all databases" message in syslog, with
a whole bunch of other messages about saving and loading listener states
  7. play with the number of workspaces -- notifications do not work any more

Syslog messages from step 3 (when notifications do work):

Oct 20 14:41:44 perlas gconfd (mg-3269): Setting
/apps/metacity/general/num_workspaces in xml:readonly:/etc/gconf/gconf.xml.mandatory
Oct 20 14:41:44 perlas gconfd (mg-3269): Setting
/apps/metacity/general/num_workspaces in xml:readwrite:/home/mg/.gconf
Oct 20 14:41:44 perlas gconfd (mg-3269): /apps/metacity/general/num_workspaces
was writable in xml:readwrite:/home/mg/.gconf
Oct 20 14:41:44 perlas gconfd (mg-3269): Notified listener metacity (3992977494)
of change to key `/apps/metacity/general/num_workspaces'

Relevant excepts from step 6 (when gconfd reacts to SIGHUP):

Oct 20 14:41:45 perlas gconfd (mg-3269): Reloading all databases
...
Oct 20 14:41:45 perlas gconfd (mg-3269): Saving listener metacity (3992977494)
to log file
...
Oct 20 14:41:45 perlas gconfd (mg-3269): Sync completed without errors
...
Oct 20 14:41:45 perlas gconfd (mg-3269): Added listener from-saved-state
(4110417927)
Oct 20 14:41:45 perlas gconfd (mg-3269): Attempting to update listener from
saved state file, old connection 3992977494, new connection 4110417927
...
Oct 20 14:41:45 perlas gconfd (mg-3269): Saving listener from-saved-state
(4110417927) to log file
...

Syslog messages from step 7 (notifications do not work any more):

Oct 20 14:41:46 perlas gconfd (mg-3269): Setting
/apps/metacity/general/num_workspaces in xml:readonly:/etc/gconf/gconf.xml.mandatory
Oct 20 14:41:46 perlas gconfd (mg-3269): Setting
/apps/metacity/general/num_workspaces in xml:readwrite:/home/mg/.gconf
Oct 20 14:41:46 perlas gconfd (mg-3269): /apps/metacity/general/num_workspaces
was writable in xml:readwrite:/home/mg/.gconf

Notice that there is no "Notified listener ..." message.

HTH.

I can't seem to get gconf to provide more verbose information with the -USR1
signal, but I can otherwise duplicate.  Note that "a little while" in step 5
appears to be approximately 30 seconds for me.

I'm going to reassign to gconf, though I'm not quite sure that's right so they
can feel free to reassign back.

*** Bug 156749 has been marked as a duplicate of this bug. ***

*** Bug 156685 has been marked as a duplicate of this bug. ***

Not sure but perhaps related to #153948 ("preload breaks the saved_state") that
causes a breakage for the workspace applet for sure.

*** Bug 153948 has been marked as a duplicate of this bug. ***

Yes bug 153948 is a duplicate; the information you provided in that bug looks
like it may be really useful too.

doh, I don't agree with the #153948 is a dup in fact, this bug is in the middle
on metacity bug and #153948 is a problem with gconf. Perhaps this bug should be
reassigned to gconf ?

Sebastien: Um... This bug has already been reassigned to gconf.

oops, sorry I was adding a comment and apparently I've read contact and the Cc
set to metacity and forgotten the assignee.
BTW this bug is really a major annoyance for user, almost every day somebody on
IRC is asking why changing the background, or a shorcut or the number of
workspace doesn't work ... has anybody planned to work on this ? If not any hint
on where to start for people who would like to help but don't have a gconf
internals knowledge ?

*** Bug 160902 has been marked as a duplicate of this bug. ***

I'm updating the title with the one from #153948 which reflects better the issue
imho

is there any objection to put this bug with a 2.10 milestone ? Almost every day
somebody ask on IRC why GNOME need to be restarted to change the number of
workspace, the current theme, etc ... 

I agree, this is definitely a showstopper bug (and isn't as likely to be noticed
on the 2.8.x milestone, sigh...).  I briefly tried taking a look at the sources,
but was not familiar enough to make any progress at this point.  Can anyone
provide some pointers on what might be going wrong here?

For all we know this has never worked since GNOME 2.0... so I'm not sure it
stops the release, based on precedent ;-) Still, I would love to see it fixed.

gconfd maintains a hash of corba connections (apps) interested in particular keys.
It logs this hash to a file called saved_state, so if gconfd crashes it is
supposed to recover the list of listeners.

So all I can think of is, it goes wrong someway. Either it doesn't save or
doesn't successfully load the saved_state file. But that should only matter if
gconfd is somehow crashing or exiting...

Or maybe there's some way that the hash gets mangled or lost at runtime, though
it seems fairly simple in principle...

2.0 didn't have an sighup handler to reload the gconf base (which is a 2.8
feature), now the feature is here and used (some distros reload the base after
each schema installation by example, so basically every time you install/update
an app with a schema you break your desktop) ...

*** Bug 159727 has been marked as a duplicate of this bug. ***

Hmm, that was an annoying bug. Fixed on HEAD and gnome-2-8:

2005-02-06  Mark McLoughlin  <mark@skynet.ie>

        Fix bug #154005 - "preload breaks saved state", caused
        by a bug in the way the listeners tree was constructed.

        * gconf/gconf-listeners.c:
        (ltable_entry_new): take a list of path elements
        and index to the entry and construct the full
        path for that entry.
        (ltable_insert): update for above so that we
        don't pass use the wrong path for full_name.

thanks for fixing it!

*** Bug 123267 has been marked as a duplicate of this bug. ***