[Novalug] Icons vanishing from Ubuntu Karmic desktop

[Peter Larsen]

On Fri, 2010-09-17 at 20:08 -0400, James Ewing Cottrell 3rd wrote:
> Peter, this is clearly not your best post.

It's over-simplified and not a doctorate on process guidance - agreed.
But it's correct in the context of the question asked.

> On 9/17/2010 12:10 PM, Peter Larsen wrote:
> > On Thu, 2010-09-16 at 14:38 -0400, Bonnie Dalzell wrote:
> >> Recently I have been experiencing loss of all the icons on my desktop
> >> during a session. when i restart they come back. I have not yet figured
> >> out what may be triggering this.
> > Does this happen at a specific point in time? After running a particular
> > program? After having it loaded for X number of minutes/hours?
> >
> > Do you have error messages in /var/log/messages or /var/log/Xorg.0.log?
> Good start tho, get more info.

Always a good start to be able to say more than: It doesn't work.
Inspecting /var/log should be one of the first thing we all do when we
have a system problem. 

> >> is there a way to reboot x without closing down running programs?
> > Depends on your definition of running programs (that's very much Windows
> > Speak). All gui based programs, such as OpenOffice, Firefox etc. are
> > "owned" by X - including your gnome-session process that you're most
> > likely experiencing problems with.
> What do you mean by "owned"? Ownership to me means File Ownership, what 
> chown changes.

Owned = having a parent. In the context of session based processes there
is an ownership; while it's not "natural" for the processes to act this
way, any process who shares a tty is being forwarded a SIGHUP if an
active pipe/socket is closed. This is why, when your SSH session dies,
that any process you were running in that session dies and goes away.
This is why we have "nohup" and 'screen' which blocks those signals to
allow particular PIDs to ignore the signal and continue. But in the case
of processes associated with a tty (not a daemon) the behavior is as I
described. Since the question is about X sessions this is quite precise
and correct.

Now - can a faulty process fail to terminate? SURE. But it'll end up as
a zombie if unhandled. It cannot be resumed to a different session so if
the process is fully ignoring or not reacting to SIGKILL even, you've
got yourself a "Z". If a process is waiting for IO that will never
happen, you have yourself a perfect unkillable process. 

> Do you mean that all your X Clients are children of the X server? The X 
> Display Manager? Some Menu Launcher?

Trying to simplify sometimes leads to very broad and non-specific
statements. I agree, it's vague but that was on purpose. Most of us
doesn't even talk about X that much anymre - it's the Session
manager/window manager that's important now. GNome for some, KDE for
others - and XCFE for even others - and then there is all the less known
but still effective session managers out there. Choices are good :)

Here's a generalization of how X works in today's Fedora world:

X is loaded by the system process - usually as one of the very last
things initiated by startup. X Loads gdm (again you can use others like
kdm) which basically is the login window/shell. When a user logs in and
uses gnome, gnome-session is run by gdm. This process is the core
process of your desktop, and it loads all the required "background"
processes that makes up the desktop look and feel. A good "ps axf" will
give anyone a good view of how many processes are generated for a normal
gnome login. It's quite a few these days: 

2398 ?        Ssl    0:00 gnome-session
 2469 ?        Sl     1:43  \_ metacity --sm-client-id
10a30c8f846c27591a1277146
 2476 ?        Sl     0:58  \_ gnome-panel
--sm-config-prefix /gnome-panel-kZs4Z
 2490 ?        Sl     0:41  \_ nautilus --sm-client-id
107e2d1d68f07d3bd41254013
 2494 ?        S      0:00  \_ /usr/libexec/gdu-notification-daemon
 2495 ?        Sl     0:01  \_ nm-applet --sm-disable
 2501 ?        S      0:00  \_ /usr/sbin/restorecond -u
 2503 ?        S      0:00  \_ /usr/libexec/gnome-user-share
 2507 ?        Sl     0:16  \_
python /usr/share/system-config-printer/applet.py
 2511 ?        Sl     5:30  \_ python /usr/libexec/daemon_wallpapoz
 2512 ?        Sl     0:03  \_ gnome-power-manager
 2514 ?        Sl     0:00
\_ /usr/libexec/polkit-gnome-authentication-agent-1
 2522 ?        Sl     0:43  \_ pidgin --session
106dd449acd875f33e12831791449126
 2523 ?        Sl     0:24  \_ rhythmbox --sm-client-id
10ee0b1b7f6d72ccd1282319
 2526 ?        Sl     0:00
\_ /usr/libexec/evolution/2.28/evolution-alarm-notif
 2529 ?        S      0:00  \_ /usr/bin/seapplet
 2646 ?        Sl     0:00  \_ abrt-applet
 2757 ?        Sl     0:01  \_ gpk-update-icon
 2760 ?        Sl     0:00  \_ gnome-volume-control-applet

These are all children of the gnome-session process. And these children
will ALL receive the same SIGHUP/KILL that is sent to gnome-session this
this process owns the tty. Since the session is owned (forked/created)
by gdm, the default setting for Fedora kills gdm on logout which means
EVERY gnome session active will be terminated, and so will their
children ("startup"/init detects the dead/killed gdm and restarts it).

> All very common, but they could be started from the command line of 
> another window, or even from another machine.
> > So killing the parent/owner means
> > killing all the children too.
> No Way! YOU KNOW BETTER! When a parent dies, all children are simply 
> re-parented to process 1, init.

As I laid out above, in the given context quite correct. But I frankly
admit that I made the statement quite generally and it could be
construed that this is the case for EVERY process - tty or no tty. And
you're quite correct if there's no tty (ie. a daemon) the children isn't
killed. A good example of that is sshd. Kill sshd while you're on, and
you're still going because the forked child of sshd is still active and
keeps serving existing connections.

> OK, when the X Server dies, all clients now have Nothing To Talk To. So 
> most of them just die, but they don't *have to*.

For X they WILL die. The design of Unix/Linux was meant to make tty
bound processes die if the owner (parent) of the tty (I think some calls
that "master" not sure) dies. Any signal passed to the parent will be
passed to the children usually through the shared tty/socket. So far
I've NEVER seen a gnome-session based process not die if gnome-session
is killed. Since the process' purpose is to manage/write to that tty
somehow - no tty means no process. It should and must terminate if the
tty goes away.

> The could easily wait and attempt to reopen a connection if they wanted 
> to. Of course, none that I know of do.

A connection to what? The gnome-session children aren't using a separate
socket to talk to X/Gnome. They're using the parent socket - the SAME
socket - that got killed. 

> So effectively, killing the X Server kills all the X Clients, but it is 
> a secondary effect, not a primary one.

You need to differentiate between daemons (non tty processes) and
foreground processes that has ttys associated with them. If you want a
parallel, if I have two processes over a IP socket and one of the
processes dies and sends FIN - the other process in theory has a choice
to remain open but it'll NEVER get to resume that same session again.
Since the kernel will send any process waiting in a 'select' a HUP
signal, this should be quite automatic. But as you know, I can always
code myself an exception and ignore it. But those are RARE exceptions.
This was a general answer.

> > However, all your daemons and system keeps
> > going. If your distro is fairly new, the ctrl-alt-backspace to kill X
> > has been disabled (it's easy to enable again if you which). It's a quick
> > way to restore a desktop but yes, it means killing any work in progress
> > doing so.
> I'd call that a Gratuitous Change, but that's just my opinion.

Yeah - I tend to agree. I have re-enabled that feature too ;)

> > Also, if your problem is gnome-session, logging in/out will restart that
> > too.
> >
> >> I am using Ubuntu Karmic (9.10).
> > Time to upgrade?
> Wake Up! Time To Die!

If I'm not careful I'll go into Monty Python overdrive on that one :)

-- 
Best Regards
  Peter Larsen

Wise words of the day:
Those who don't understand Linux are doomed to reinvent it, poorly.
	-- unidentified source
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : http://calypso.tux.org/pipermail/novalug/attachments/20100917/254c5f96/attachment.bin