Bug 712544 - startx causes autostart error messages related to Desktop Session Settings
startx causes autostart error messages related to Desktop Session Settings
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: lxsession (Show other bugs)
15
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Christoph Wickert
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2011-06-10 20:21 EDT by jurek.bajor
Modified: 2012-08-07 15:47 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-08-07 15:47:49 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
lxde nm-applet-autostart-and-startx-files (9.55 KB, text/plain)
2011-06-12 02:57 EDT, jurek.bajor
no flags Details
gui logged in with no autostart apps configured (1.49 KB, application/octet-stream)
2011-06-18 10:20 EDT, jurek.bajor
no flags Details

  None (edit)
Description jurek.bajor 2011-06-10 20:21:52 EDT
Description of problem:

$ cat .startx.log
...
(==) Using system config directory "/usr/share/X11/xorg.conf.d"
GNOME_KEYRING_CONTROL=/tmp/keyring-L6Wo32
SSH_AUTH_SOCK=/tmp/keyring-L6Wo32/ssh
GNOME_KEYRING_PID=1828
Applet requires SELinux be enabled to run.   <============================
E: main.c: Daemon startup failed.            <============================
GNOME_KEYRING_CONTROL=/tmp/keyring-L6Wo32
SSH_AUTH_SOCK=/tmp/keyring-L6Wo32/ssh
...

Version-Release number of selected component (if applicable):

$ yum list "lxsession*"
Installed Packages
lxsession.i686                  0.4.5-3.fc15    @koji-override-0/$releasever
lxsession-edit.i686             0.1.1-5.fc15    @koji-override-0/$releasever

How reproducible:
start LXDE

Steps to Reproduce:
1. $ startx > ~/.startx.log 2>&1
2.
3.
  
Actual results:

error messages as above

Expected results:

In case of error message:
  Applet requires SELinux be enabled to run.
this message should indicate from which Applet it comes from (in particular if
there were multiple SELinux applets to autostart), e.g.
SELinux Troubleshooter: Applet requires SELinux be enabled to run.

In case of error message:
  E: main.c: Daemon startup failed.
it is not clear from which autostart applet it comes from.
The message is related to Network (Network Manager's nm-applet), and appears
when starting LXDE *regardless* of Network applet being selected for Autostart
in Preferences - Desktop Session Settings, which is wrong.
That error message should be corrected - what is E: ? what program main.c is
from ?

Additional info:
Comment 1 Christoph Wickert 2011-06-11 03:51:12 EDT
(In reply to comment #0)
> In case of error message:
>   Applet requires SELinux be enabled to run.
> this message should indicate from which Applet it comes from (in particular if
> there were multiple SELinux applets to autostart), e.g.
> SELinux Troubleshooter: Applet requires SELinux be enabled to run.

This has nothing to do with lxsession. Please file a bug against setroubleshoot.

> In case of error message:
>   E: main.c: Daemon startup failed.
> it is not clear from which autostart applet it comes from.

I don't know either. The only way to find out is to disable *all* autostart programs, enable them one by one and look at the list of processes and when the massage appears.

> The message is related to Network (Network Manager's nm-applet), and appears
> when starting LXDE *regardless* of Network applet being selected for Autostart
> in Preferences - Desktop Session Settings, which is wrong.

This is because lxsession starts both the files from the global autostart in /ect/xdg/autostart and form the personal one ~/.config/autostart while the latter should overwrite the first. Can you please verify this assumption? Because of this you will also have to move files from  the global autostart directory out of the way while testing.

> That error message should be corrected - what is E: ? what program main.c is
> from ?

Once you know please file a bug on the package in question. The only problem with lxsession I can see here is that it seems to start programs it shouldn't. Right?
Comment 2 Christoph Wickert 2011-06-11 04:54:08 EDT
One more thing to test: Are these errors really related to starty or do they also appear when LXDE is started from a display manager?
Comment 3 jurek.bajor 2011-06-11 07:52:49 EDT
(In reply to comment #1)
> (In reply to comment #0)
> > In case of error message:
> >   Applet requires SELinux be enabled to run.
> > this message should indicate from which Applet it comes from (in particular if
> > there were multiple SELinux applets to autostart), e.g.
> > SELinux Troubleshooter: Applet requires SELinux be enabled to run.
> 
> This has nothing to do with lxsession. Please file a bug against
> setroubleshoot.

OK. I will pass it to SELinux and its maintainer.

> 
> > In case of error message:
> >   E: main.c: Daemon startup failed.
> > it is not clear from which autostart applet it comes from.
> 
> I don't know either. The only way to find out is to disable *all* autostart
> programs, enable them one by one and look at the list of processes and when
> the massage appears.
> 

You jump to conclusion to quickly. I have already test it exactly this way,
one by one, and the conclusion is as described below.

> > The message is related to Network (Network Manager's nm-applet), and appears
> > when starting LXDE *regardless* of Network applet being selected for Autostart
> > in Preferences - Desktop Session Settings, which is wrong.
> 
> This is because lxsession starts both the files from the global autostart in
> /ect/xdg/autostart and form the personal one ~/.config/autostart while the
> latter should overwrite the first. Can you please verify this assumption?
> Because of this you will also have to move files from  the global autostart
> directory out of the way while testing.

I have already done that via Preferences - Desktop Session Settings as I said
above, by disabling one by one, and finding the offender.
I do not, and should not, manipulate the config files directly, whether
systemwide or locally.

> 
> > That error message should be corrected - what is E: ? what program main.c is
> > from ?
> 
> Once you know please file a bug on the package in question. The only problem
> with lxsession I can see here is that it seems to start programs it shouldn't.
> Right?

That's the problem, I guess. The lxsession is the "driver" program that starts
programs configured for autostart in Preferences - Desktop Session Settings.
So, if Network is disabled there, it should not start it.
But, as I said above, the error message is issued *regardless* of autostart
configuration (on ir off).
So what causes nm-applet to autostart ? Now, which applet is responsible for
the error message ? Lxsession or nm-applet ?
I tested it, delivered test results to you. My role  is finished.
Now somebody, a programmer, should look into it.
If you do not feel ready for htis, pass it to upstream maintainer, first of
lxsession as a "driver" program. After correcting the autostart error, she
will also determine if the error comes form her package, if not, then she will
pass the torch to us ir directly to nm-applet maintainer.
JB
Comment 4 Christoph Wickert 2011-06-11 08:48:33 EDT
(In reply to comment #3)
> OK. I will pass it to SELinux and its maintainer.

Not SELinux, setroubleshoot. Different packages, different maintainers.

> You jump to conclusion to quickly. I have already test it exactly this way,
> one by one, and the conclusion is as described below.

Then why do you ask if you already found out which application it is?

> I have already done that via Preferences - Desktop Session Settings as I said
> above, by disabling one by one, and finding the offender.
> I do not, and should not, manipulate the config files directly, whether
> systemwide or locally.

I'm afraid you have to. Let me explain:
Global autostart is in /ect/xdg/autostart and your personal autostart is in ~/.config/autostart. When you disable a program in lxsession-edit, lxsesion-edit copies the file from the global to the personal autostart and 
adds a line "Hidden=True" to is. According to the spec at
http://standards.freedesktop.org/autostart-spec/latest/ar01s02.html#id2469451
lxsession should no longer start the desktop file.

There also is the problem of the "OnlyShowIn" or "NotShowIn" keys. "OnlyShowIn=LXDE;XFCE" starts a program only in LXDE and Xfce. "NotShowIn=GNOME;" starts a program in all sessions but GNOME. lxsession does honor these keys, however lxsession does not. This is a known limitation and on the Todo list for the next release.

So in order to find out if 
- lxsession-edit changed the file incorrectly or
- lxsession started it incorrectly or
- it has something to do with Only/NotShowIn,
we need to look at the files themselves. We need to at least look at them and compare the global with the personal files, not necessarily to edit them.

> > Once you know please file a bug on the package in question. The only problem
> > with lxsession I can see here is that it seems to start programs it shouldn't.
> > Right?
> 
> That's the problem, I guess. The lxsession is the "driver" program that starts
> programs configured for autostart in Preferences - Desktop Session Settings.

Correct.

> So, if Network is disabled there, it should not start it.

Correct.

> But, as I said above, the error message is issued *regardless* of autostart
> configuration (on ir off).
> So what causes nm-applet to autostart ? 

Three options:
1. lxsession-edit didn't disable it properly.
2. lxsession started it although it was properly disabled.
3. It was started by something else, e.g. through dbus activation

> Now, which applet is responsible for
> the error message ? Lxsession or nm-applet ?

nm-applet

> I tested it, delivered test results to you. My role  is finished.
> Now somebody, a programmer, should look into it.

I'm sorry, as explained above you really need to look at the *.desktop files before somebody else can take over.

> If you do not feel ready for htis, pass it to upstream maintainer, first of
> lxsession as a "driver" program. After correcting the autostart error, she
> will also determine if the error comes form her package, if not, then she will
> pass the torch to us ir directly to nm-applet maintainer.

If you can quickly test if you have this error in another desktop environment, too when np-applet is disabled, I consider it save to file a bug against NetworkManager-gnome.
Comment 5 jurek.bajor 2011-06-12 02:57:53 EDT
Created attachment 504296 [details]
lxde nm-applet-autostart-and-startx-files
Comment 6 jurek.bajor 2011-06-12 02:59:54 EDT
Here are the global and local autostart config files -
see attachment nm-applet-autostart-and-startx-files.txt .

I went back to F14 and GNOME 2 and tested autostart with nm-applet - no error
message of this kind.

JB
Comment 7 Christoph Wickert 2011-06-17 16:44:13 EDT
F14 and GNOME 2 is much different because it uses a different version of networkmanager-gnome (0.8 vs. 0.9).

I think you have a valid point that the error message from sealert should mention the application. So please file a bug against setroubleshoot.

There also is something wrong with nm-applet, it definitely should not produce that many error messages. Please file a bug against networkmanager-gnome. However it would be interesting to know if you also get these messages when you start your sesion from a display manager (see comment 

Once you have filed these bugs please add their URLs to the "See also" field.

Thanks for provding the autostart files. Unfortunately we still don't know what is causing the "Daemon startup failed" message. I don't get that message, you are the only one to find out. Please disable *all* autostart programs for testing, global and personal ones.
Comment 8 Christoph Wickert 2011-06-17 16:45:06 EDT
(In reply to comment #7)
> However it would be interesting to know if you also get these messages when you
> start your sesion from a display manager (see comment 

Sorry, that was supposed to read "(see comment 2)".
Comment 9 jurek.bajor 2011-06-18 10:15:39 EDT
(In reply to comment #7)
> F14 and GNOME 2 is much different because it uses a different version of
> networkmanager-gnome (0.8 vs. 0.9).
> 
> I think you have a valid point that the error message from sealert should
> mention the application. So please file a bug against setroubleshoot.

Done. See URLs.

> 
> There also is something wrong with nm-applet, it definitely should not produce
> that many error messages. Please file a bug against networkmanager-gnome.

Done. See URLs.

> However it would be interesting to know if you also get these messages when
> you start your sesion from a display manager (see comment 

See attachment xsession-errors-no-autostart-apps.

> 
> Once you have filed these bugs please add their URLs to the "See also" field.

Done.

> 
> Thanks for provding the autostart files. Unfortunately we still don't know 
> what is causing the "Daemon startup failed" message. I don't get that 
> message, you are the only one to find out. Please disable *all* autostart 
> programs for testing, global and personal ones.

All autostart apps disabled in Preferences - Desktop Session Setting.
After that I also:
$ rm ~/.config/autostart/*
Then restarted with GUI login.

See attachment xsession-errors-no-autostart-apps.
JB
Comment 10 jurek.bajor 2011-06-18 10:20:23 EDT
Created attachment 505393 [details]
gui logged in with no autostart apps configured
Comment 11 jurek.bajor 2011-06-18 12:03:14 EDT
(In reply to comment #9)

> > Thanks for provding the autostart files. Unfortunately we still don't know 
> > what is causing the "Daemon startup failed" message. I don't get that 
> > message, you are the only one to find out. Please disable *all* autostart 
> > programs for testing, global and personal ones.
> 
> All autostart apps disabled in Preferences - Desktop Session Setting.
> After that I also:
> $ rm ~/.config/autostart/*
> Then restarted with GUI login.
> 
> See attachment xsession-errors-no-autostart-apps.
> JB

Well, I just noticed looking at Preferences - Desktop Session Settings again
that almost all the autostart apps are activated (checked off) again,
automagically ?
I assume they got activated by looking at /etc/xdg/autostart/ ?

And some were started as well, e.g.:
$ ps aux |grep -i polkit
root       647  0.0  0.4  24672  3404 ?        Sl   15:39   0:00 /usr/libexec/polkit-1/polkitd
jb        1299  0.0  0.5  27752  4132 ?        Sl   15:40   0:00 /usr/libexec/lxpolkit
$ cat /etc/xdg/autostart/lxpolkit.desktop
...
Exec=/usr/libexec/lxpolkit
Icon=gtk-dialog-authentication
NotShowIn=GNOME;KDE;

but others were not, e.g.:
$ ps aux |grep -i seapplet

and NetworkManager was not as well (I started it manually to have Internet
connection with '/etc/init.d/NetworkManager restart').

And there are no local autostart apps configured as expected:
$ ls -l .config/autostart/
total 0

So ..., I would say that this does not feel right ...
Something has oerwritten my global configuration in Preferences - Desktop Session Settings, so I assume that if I restart LXDE (GUI login or text login
followed by startx) I get all these autostart apps running again ...
This is not what I wanted when I turned them all off !
Let's see.
JB
Comment 12 jurek.bajor 2011-06-18 12:25:27 EDT
(In reply to comment #11)
> (In reply to comment #9)
> 
> > > Thanks for provding the autostart files. Unfortunately we still don't know 
> > > what is causing the "Daemon startup failed" message. I don't get that 
> > > message, you are the only one to find out. Please disable *all* autostart 
> > > programs for testing, global and personal ones.
> > 
> > All autostart apps disabled in Preferences - Desktop Session Setting.
> > After that I also:
> > $ rm ~/.config/autostart/*
> > Then restarted with GUI login.
> > 
> > See attachment xsession-errors-no-autostart-apps.
> > JB
> 
> Well, I just noticed looking at Preferences - Desktop Session Settings again
> that almost all the autostart apps are activated (checked off) again,
> automagically ?
> I assume they got activated by looking at /etc/xdg/autostart/ ?
> 
> And some were started as well, e.g.:
> $ ps aux |grep -i polkit
> root       647  0.0  0.4  24672  3404 ?        Sl   15:39   0:00
> /usr/libexec/polkit-1/polkitd
> jb        1299  0.0  0.5  27752  4132 ?        Sl   15:40   0:00
> /usr/libexec/lxpolkit
> $ cat /etc/xdg/autostart/lxpolkit.desktop
> ...
> Exec=/usr/libexec/lxpolkit
> Icon=gtk-dialog-authentication
> NotShowIn=GNOME;KDE;
> 
> but others were not, e.g.:
> $ ps aux |grep -i seapplet
> 
> and NetworkManager was not as well (I started it manually to have Internet
> connection with '/etc/init.d/NetworkManager restart').
> 
> And there are no local autostart apps configured as expected:
> $ ls -l .config/autostart/
> total 0
> 
> So ..., I would say that this does not feel right ...
> Something has oerwritten my global configuration in Preferences - Desktop
> Session Settings, so I assume that if I restart LXDE (GUI login or text login
> followed by startx) I get all these autostart apps running again ...
> This is not what I wanted when I turned them all off !
> Let's see.
> JB

Well, I restarted LXDE thru GUI login, and as before restart:
$ ps aux |grep -i polkit
root       647  0.0  0.4  24672  3404 ?        Sl   15:39   0:00 /usr/libexec/polkit-1/polkitd
jb        4107  0.0  0.4  27436  3476 ?        Sl   18:04   0:00 /usr/libexec/lxpolkit

but why not this (it was checked off to autostart ...):
$ ps aux |grep -i seap

but a new one here (as expected):
$ ps aux |grep -i net
...
root      2692  0.0  0.7  29144  5588 ?        Ssl  16:31   0:00 /usr/sbin/NetworkManager --no-daemon

and another new one (es expected, but notably at first approach):
$ ps aux |grep -i sea
jb        1267  0.0  1.0  98752  8028 ?        S<sl 15:40   0:00 pulseaudio -D

and also:
$ ls -l .config/autostart
total 0
which I understood should have been propagated with those now active autostart
apps ...

and I include this (note the error message here again):
$ $ cat .xsession-errors 
E: main.c: Daemon startup failed.
GNOME_KEYRING_CONTROL=/tmp/keyring-wehf1e
SSH_AUTH_SOCK=/tmp/keyring-wehf1e/ssh
GNOME_KEYRING_CONTROL=/tmp/keyring-wehf1e
SSH_AUTH_SOCK=/tmp/keyring-wehf1e/ssh
Applet requires SELinux be enabled to run.
GNOME_KEYRING_CONTROL=/tmp/keyring-wehf1e
SSH_AUTH_SOCK=/tmp/keyring-wehf1e/ssh
GPG_AGENT_INFO=/tmp/keyring-wehf1e/gpg:0:1
GNOME_KEYRING_CONTROL=/tmp/keyring-wehf1e
SSH_AUTH_SOCK=/tmp/keyring-wehf1e/ssh
GPG_AGENT_INFO=/tmp/keyring-wehf1e/gpg:0:1
** Message: applet now removed from the notification area

(nm-applet:4095): libnotify-WARNING **: Failed to connect to proxy

(nm-applet:4095): Gdk-CRITICAL **: gdk_visual_get_red_pixel_details: assertion `GDK_IS_VISUAL (visual)' failed

(nm-applet:4095): Gdk-CRITICAL **: gdk_visual_get_green_pixel_details: assertion `GDK_IS_VISUAL (visual)' failed

(nm-applet:4095): Gdk-CRITICAL **: gdk_visual_get_blue_pixel_details: assertion `GDK_IS_VISUAL (visual)' failed

** (lxpanel:4081): WARNING **: Group count mismatch, ctrls = 1, groups = 1, symbols = 2

** Message: applet now embedded in the notification area

----------
It looks like somewhat erratic behavior and confusing ...
JB
Comment 13 Fedora End Of Life 2012-08-07 15:47:51 EDT
This message is a notice that Fedora 15 is now at end of life. Fedora
has stopped maintaining and issuing updates for Fedora 15. It is
Fedora's policy to close all bug reports from releases that are no
longer maintained. At this time, all open bugs with a Fedora 'version'
of '15' have been closed as WONTFIX.

(Please note: Our normal process is to give advanced warning of this
occurring, but we forgot to do that. A thousand apologies.)

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen
this bug and simply change the 'version' to a later Fedora version.

Bug Reporter: Thank you for reporting this issue and we are sorry that
we were unable to fix it before Fedora 15 reached end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora, you are encouraged to click on
"Clone This Bug" (top right of this page) and open it against that
version of Fedora.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

The process we are following is described here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Note You need to log in before you can comment on or make changes to this bug.