Hi all,
we tried to modify gdm-2.16.0-56.el5.src.rpm (Red Hat) settings
MAX_CONNECTIONS to 100.
It doesn't work. Maybe we have done something wrong, but when our 2 server FOG
were online
again, the SunRays got no login screens. So we stopped this experiment.
When we start the FOG again with
I setup a service request at Red Hat.
This is the answer:
Red Hta do not have gdm version with MAX_CONNECTIONS set to 100. You may try
using third party gdm or recompiling the gdm from source after changes the
MAX_CONNECTIONS values in source code. But please note that as per Red hat
I'm testing with fedora 14 for the time being.
I tried replacing the gdm with the one provided with the SRS install but
that did not work well. I have to look into why a bit more.
Karl
On 02/16/11 02:10, Detlev Habicht wrote:
I setup a service request at Red Hat.
This is the answer:
Red
On 02/08/11 09:24, Meik Hellmund wrote:
in Debian you just do:
apt-get build-dep gdm(install all libraries etc neccessary for building
gdm)
apt-get source gdm (get the source)
cd gdm-2.20.11
vi daemon/gdm-net.c (change the parameter)
dpkg-buildpackage -b -uc
On 02/08/11 16:24, Meik Hellmund wrote:
On Tue, 8 Feb 2011 15:58:43 +0100
Detlev Habicht habi...@ims.uni-hannover.de wrote:
We have to recompile gdmdynamic?
Yes, in fact all of gdm
Or is there a config file somewhere in the system?
there is a comment in daemon/gdm-net.c:
this
Hello again,
i am a little bit confused. Maybe i have made a mistake.
And maybe a second time :-}
Normally i install the gdm from Sun.
Maybe i have forgotten this the last time.
So i find now from Red Hat this: gdm-2.16.0-56.el5
Sun has this: gdm-2.16.7-2.1_01.sunray.x86_64.rpm
Maybe some of
You should not normally install the version of gdm included with the product
manually.
That version will be installed automatically by the installer *if appropriate*.
I believe the only appropriate situation for installing that version is on SLES
10, which had a significantly downrev version
On Fri, 04 Feb 2011 17:44:20 +0100
Carsten John cj...@mpi-bremen.de wrote:
Hi folks,
we are still having problems.
What I found out in the meantime is that definitely gdm is the problem.
It works for about a day (or a few days?). Then suddenly gdm does not
provide login service any
We have to recompile gdmdynamic?
Or is there a config file somewhere in the system?
Detlev
P.S.: I am using Red Hat.
Am 08.02.2011 um 15:35 schrieb Meik Hellmund:
On Fri, 04 Feb 2011 17:44:20 +0100
Carsten John cj...@mpi-bremen.de wrote:
Hi folks,
we are still having problems.
What
On Tue, 8 Feb 2011 15:58:43 +0100
Detlev Habicht habi...@ims.uni-hannover.de wrote:
We have to recompile gdmdynamic?
Yes, in fact all of gdm
Or is there a config file somewhere in the system?
there is a comment in daemon/gdm-net.c:
this should be configurable ..but it seems nobody
Hello,
we have similar problems and maybe the same.
I can also see the gdm user for example.
Mostly we see this problem when a user tries to login
via smartcard or want to go to another terminal (with the smartcard).
Sometimes this problem appears for a smartcard and so the
problem goes with
On 02/04/2011 06:28 PM, Bob Doolittle wrote:
Can you please share the output of gdmflexiserver --command VERSION?
-Bob
Hi Bob,
root@capella: ~ #
gdmflexiserver --command VERSION
GDM 2.20.10
thx
Carsten
___
SunRay-Users mailing list
Can you please share the output of gdmflexiserver --command VERSION?
-Bob
On 02/04/11 11:44, Carsten John wrote:
Hi folks,
we are still having problems.
What I found out in the meantime is that definitely gdm is the problem.
It works for about a day (or a few days?). Then suddenly gdm does
We've had this happen randomly, but it doesn't sound like it's as bad as you
have it.
When it happens, I just go into the web console and kill the session. The user
has to unplug power from the DTU, but after that, it functions normally
-Original Message-
From:
On 01/19/11 15:13, Carl Holzhauer wrote:
We've had this happen randomly, but it doesn't sound like it's as bad as you
have it.
When it happens, I just go into the web console and kill the session. The
user has to unplug power from the DTU, but after that, it functions normally
Hi everybody,
in the meantime I found out, that no new logins are possible even with a
newly connected DTU (so there are no hanging sessions involved).
The DTU that was never connected after the last reboot also remains in
26D when connected.
thx
Carsten
A few things to check:
- Does gdmdynamic -l list the same set of displays as utsession -p?
- Do you see an Xnewt process for every display in gdmdynamic -l?
-Bob
On 01/19/11 10:34, Carsten John wrote:
Hi everybody,
in the meantime I found out, that no new logins are possible even with a
newly
On 01/19/2011 05:38 PM, Bob Doolittle wrote:
A few things to check:
- Does gdmdynamic -l list the same set of displays as utsession -p?
Not really...
Server 1: 23 displays occur in both outputs, 4 are unique to gdmdynamic
and 17 to utsession.
Server 2: 18 displays occur in both outputs, 5
On 01/19/11 16:19, Elmar Prüße wrote:
On 01/19/2011 05:38 PM, Bob Doolittle wrote:
A few things to check:
- Does gdmdynamic -l list the same set of displays as utsession -p?
Not really...
Server 1: 23 displays occur in both outputs, 4 are unique to gdmdynamic and 17
to utsession.
Server 2:
I think I've found at least one major culprit.
There is a line in gdm.conf that configures a backup script to be run if
the X Server fails.
FailsafeXServer=/etc/gdm/failsafeXServer
In order to be able to run an emergency xserver on the failing display
without having gdm interfere, it checks
20 matches
Mail list logo
