Bug 190946 - gdm - BackgroundProgram nearly useless in FC5
gdm - BackgroundProgram nearly useless in FC5
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: gdm (Show other bugs)
5
All Linux
medium Severity medium
: ---
: ---
Assigned To: Ray Strode [halfline]
Mike McLean
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-05-06 20:52 EDT by Michal Jaegermann
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-05-11 14:46:43 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Michal Jaegermann 2006-05-06 20:52:29 EDT
Description of problem:

gdm configuration file in /etc/gdm/custom.conf has the following lines

# Program to run to draw the background in the standard greeter.  Perhaps
# something like an xscreensaver hack or some such.
# BackgroundProgram=
# if this is true then the background program is run always, otherwise it is
# only run when the BackgroundType is 0 (None).
# RunBackgroundProgramAlways=false

The problem is that with 'BackgroundProgram' set to something which
is supposed to paint that background and standard greeter try as I might
there is nothing changing in a login background.  This is in a sharp contrast
to the situation in FC4, which is using gdm-2.6.0.5-6, and earlier versions
where 'BackgroundProgram' works as expected.

One of possible issues that 'BackgroundProgram' runs with gdm.gdm id while
owner of a background of a login screen is probably not that.  But even
making that program setuid root does not change anything.  With
'RunBackgroundProgramAlways' set to true when 'BackgroundType' is 0 or 3
("None" or "Image") I am seeing only a black background does not matter
what I am trying.  With 'BackgroundType' 1 or 2 one gets a dark blue colour
and that is it.

The only way I found that it is possible to use 'BackgroundProgram' is
to use it with 'BackgroundType' 1 or 3 and that program to make a link,
which may change, to some picture file.  With this link supplied as
'BackgroundImage' in /etc/gdm/custom.conf one can see, sometimes, effects.

Even here an execution rate looks like throttled, so if one has more than
one server and would like to provide different backgrounds in an order to
be able to distinguish them visually, which is one of "normal" applications
of this facility, then this does not work as a link is not switched when
the second server is starting because this is "too fast".  Big sigh!

Version-Release number of selected component (if applicable):
gdm-2.14.4-1.fc5.1

How reproducible:
always

Expected results:
When I am running a program to set background it sets it and it runs
when it is told to run.
Comment 1 Michal Jaegermann 2006-05-11 14:46:43 EDT
After diving in gdm documentation I found that there are now new
configuration options:

BackgroundProgramInitialDelay
BackgroundProgramRestartDelay

with default values beeing in both cases apparently 30 although
experiments, when BackgroundProgramRestartDelay was not explicitely
set, would suggest that this delay is much longer (over a minute).
Setting those configuration options, respectively, to 0 and 1 has
effects I was after. At least with gdm-2.15.0-1 from rawhide
installed on a test system.

Frankly, a default of 30 for BackgroundProgramInitialDelay I am finding
somewhat puzzling.

The catch is that I am pretty sure that one FC5 machine I run into
that for the first time I really could not change that background 
but maybe I was not waiting long enough and I cannot at this moment
retest that there.  OTOH on another FC5 (x86_64 this time) changing
background this way did work without explicit settings for
BackgroundProgramInitialDelay and/or BackgroundProgramRestartDelay
so I am a bit baffled.

In any case I think that this can be considered closed even if some
loose ends appear to exist.

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