Re: [gdm-list] gdmflexiserver questions

Reid Rivenburgh wrote:
2. I noticed my machine was slowly using up memory.  It seems that
everytime I run "gdmflexiserver -s", I get a whole new X session
running.  When I log back in as me, it doesn't go away, so they're
building up over time.  At the moment, I have six metacity processes
running (and I run fvwm!), which is how I've been monitoring this.
I've noticed that when I run "gdmflexiserver -s", it almost
immediately shows the gdm login screen, but then I see a new X server
starting, and after a few seconds, I again see the gdm login.  I
thought at first that it was just killing and restarting the X server
for some reason, but now I suspect it's creating a new one each time.
Does anyone know why this might be happening?

What you are seeing might be switch Xserver rather than killing
and restarting Xserver.

In fact, login screen is running like a real gnome-session,
called greeter-session. When starting gdmflexiserver, it will
detect whether or not greeter-session exists. If yes, just
switch to there. Otherwise, create a new greeter-session and
then switch.

That's what seems to be broken for me right now.  It looks like it's
showing the existing greeter-session, but then it starts a new one.
After testing that a few times this morning, now I get this in my
xterm when trying to run gdmflexiserver:

% gdmflexiserver

** (gdmflexiserver:30519): WARNING **: Unable to determine session:
Unable to lookup session information for process '30519'
** (gdmflexiserver:30519): DEBUG: seat id is not set; can't switch sessions

And I get a dialog that says "Could not identify the current session."
 So now it's not just starting new, extraneous X servers, it's
completely broken.  I don't know what might have broken it.  If you
know of any log file info or anything else that could help diagnose
this, let me know.  I haven't manually killed any processes, and I
still have 8 metacity processes running that should all be associated
with gdm sessions.

You probably meet the same issue as me before. Please refer to
ConsoleKit problem.

Session is identified by a cookie, which is stored in envrionment
variable "XDG_SESSION_COOKIE". Cookie is created by session leader,
such as gdm-session-worker for gnome-session, gdm-simple-greeter
for greeter-session. But "XDG_SESSION_COOKIE" is likely lost in
their child process or grandchild process. Once loss, a session
can't be identified.

3. Assuming I can get things running properly, I've been a little
confused about what scripts run when.  I was hoping the
gdm/Init/Default and related scripts get run every time I run the
gdmflexiserver command.  It doesn't seem like they do, though.  Is
that correct?  Basically, after running gdmflexiserver, I want to turn
off the monitor after sleeping for a short time.  I get the feeling
that DPMS doesn't work if you simply change VT to a display that
thinks the monitor is already off (i.e. past the idle time) unless you
hit a key or move the mouse to reset the idle counter.

You can try with GPM display management. That would be easier
than writing a script. What you need to do is just set from

Also, GPM can be even run on login screen. When you stay on
login screen for a long time, monitor will sleep after a
specified idleness time.

Yes, that would be ideal.  I even added a default DPMS line to my
xorg.conf.  But what I'm afraid is happening is as I explained above
(which could be wrong): If I switch from the VT with my X session to
an existing gdm-greeter session using gdmflexiserver, it seems like
the gdm X server thinks it's been idle for a long period of time and
as a result doesn't ever turn off the monitor.  If I hit a key or move
the mouse, that resets the idle counter and it will.  If a new X
server were to be started, then that wouldn't be a possibility, of
course, but it would also take several seconds to start up and show
the login.  (Not that that's how gdm/gdmflexiserver works, just
stating it.)

When a session transfers from inactive to active state, perhaps
some applications aren't aware of this. In your case, if
applications are able to receive "ActiveChanged" from
"org.freedesktop.ConsoleKit.Session" and then reset timer,
things would be OK. AFAIK, HAL seems to already do in this
way. Request action from inactive session would be refused
by HAL.

Could you file a bug to let maintainer evaluate?

4. When I try to run a gdmflexiserver command, I get this:

% gdmflexiserver --command VERSION

** (gdmflexiserver:15043): WARNING **: No longer supported

Is that supposed to happen?

You could try with
$gdmflexiserver --version

Well, that's a workaround for that one!  But I've seen references to
other commands you can pass in, too.  I seem to be collecting gdm
sessions, so I was wondering if I could use a gdm command to list them
and possibly delete extras.  No matter what I do, though, I get the
"no longer supported" message.

Since GDM 2.22 scratched and rewrote, some interfaces changed a
lot, Old socket-based command controlling is replaced by dbus
interface.I suspect references you said is only for old GDM.

I encourage you propose your idea or even patch to maintainer.
Here's a TODO list.

Probably preceding user switching button should be added too.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]