Bug 480995 - ldm on some machines gets stuck in some cyclic failure
ldm on some machines gets stuck in some cyclic failure
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: ldm (Show other bugs)
10
All Linux
low Severity medium
: ---
: ---
Assigned To: Warren Togami
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-01-21 11:43 EST by John Ellson
Modified: 2014-06-30 09:20 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-12-18 02:39:58 EST
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 John Ellson 2009-01-21 11:43:19 EST
Description of problem:
ldm on some machines gets stuck in some cyclic failure.  The login screen doesn't appear.  We can switch to a console shell, but its still cyclically interrupted.

/var/log/messages shows repeated:
   Jan 21 11:29:31 sol xinetd[2343]: START: ldminfod pid=5158 from=::ffff:172.31.100.101
   Jan 21 11:29:31 sol xinetd[2343]: EXIT: ldminfod status=0 pid=5158 duration=0(sec)

We have multiple ltsp clients, and we've seen this problem on different clients, but strangely never more than one at a time!

Version-Release number of selected component (if applicable):
ldminfod-2.0.27-1.fc10.x86_64

How reproducible:
Seems to depend on client machine and the state of the weather ;-)

Steps to Reproduce:
1. reboot ltsp client
2.
3.
  
Actual results:
/var/log/messages shows repeated:
   Jan 21 11:29:31 sol xinetd[2343]: START: ldminfod pid=5158 from=::ffff:172.31.100.101
   Jan 21 11:29:31 sol xinetd[2343]: EXIT: ldminfod status=0 pid=5158 duration=0(sec)

Expected results:
ldm login screen

Additional info:
Comment 1 Reb 2009-01-21 12:22:52 EST
I have been working with John on this.  The cycle of the display is approximately on for one half second, off one and a half seconds.  The message the clients display is this:

-------------------------
NET: Registered protocol family 10
lo: Disabled Privacy Extensions
hda-intel: Invalid position buffer, using LPIB read method instead.
-------------------------

Similar behaviour occurs on both 32-bit and 64-bit clients.  The message is not always visible, as quite often (particularly on clients connected with a VGA cable vs. DVI) the display does not sync to the signal from the machine before the display cycles off.

Switching to the local shell running on the client machine while this is happening does not cause the flashing to change. Instead, the period of the flashing stays the same but the shell text flashes.  While it is off it seems to buffer a characters or two -- but not during the first half second that it is off.

Finally, when this does *not* happen, what appears to be the same message as above flashes for a VERY short time just prior to the display of the K12Linux login screenappears.
Comment 2 Warren Togami 2009-01-21 13:15:58 EST
Disable ldm in lts.conf.
Boot
switch to a VT shell
Run "X" manually
Does X run and display the grey pattern?
Comment 3 Reb 2009-01-21 17:13:14 EST
In this file:
   /var/lib/tftpboot/ltsp/x86_64/lts.conf
I changed     
    SCREEN_01=ldm
to
    SCREEN_01=shell
When the system started I ran "X" and that resulted
in the expected grey screen (and nothing else).

When I reset the client and fixed lts.conf to turn ldm
back on, I got the problem on the first boot of the client
(it does this more than half the time).  I then switched to
screen 5 (which we have enabled for a local shell). Then,
between the on/off screens I ran "X" and got the same grey
screen -- that flashed just the same.(In reply to comment #2)
> Disable ldm in lts.conf.
> Boot
> switch to a VT shell
> Run "X" manually
> Does X run and display the grey pattern?
Comment 4 Reb 2009-02-11 11:02:52 EST
We're still seeing this problem on occasion.  A reboot of the LTSP server
seems to cure it for a while.
Comment 5 John Ellson 2009-02-11 19:36:55 EST
I was able to get one particular x86_64 client to come up by turning off the
LCD monitor during client reboot.

We had thought that this issue was only with VGA connected monitors, but this one was DVI connected.
Comment 6 Ryan Niebur 2009-02-12 02:15:20 EST
Hi John,

I think that the problem might be that ldm is crashing rather than a problem with X. Could you please set "LDM_SYSLOG=True" and "SYSLOG_HOST=ip.addr.of.server", and then make sure that the server that SYSLOG_HOST points to has remote syslogging turned on? and then the next time this happens please send the syslog output to this bug report. If that still reveals nothing, could you try switching your SCREEN_01 back to shell and running /usr/share/ltsp/screen.d/ldm manually from the shell? Rather than starting and crashing, and starting and crashing, and so on it will only run and crash once, and hopefully have some useful output.

Thanks,
Ryan
Comment 7 David G. 2009-03-12 05:08:41 EDT
Hello,
I got the same problem.
Server:Fedora 9, 2.6.27.19-78.2.30.fc9.i686, Lts 5, installed via packet-manager.
After disabling ldm in the lts.conf file, I start X on the client manually and receive following error:
xauth: error in locking authority file /.Xauthority
Comment 8 Warren Togami 2009-03-12 12:10:18 EDT
David, your post is almost completely meaningless garbage.

> After disabling ldm in the lts.conf file, I start X on the client manually and
> receive following error:
> xauth: error in locking authority file /.Xauthority  

This is expected and has nothing to do with the ldm failure.
Comment 9 François Patte 2009-03-12 18:55:26 EDT
I got this problem with a TC Neoware e140. I was unable to boot the TC with ldm enabled.

I changed the cable connection, from DVI to ANALOGIC, between the TC and the monitor and the problem was solved.

Anyway, the: "EXIT: ldminfod status=0 pid=22507 duration=0(sec)" warning in the log file is still there.
Comment 10 Bug Zapper 2009-11-18 05:49:05 EST
This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '10'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 10's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 10 is 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 please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

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
Comment 11 Bug Zapper 2009-12-18 02:39:58 EST
Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.
Comment 12 John Ellson 2014-06-30 09:20:50 EDT
Ignore me - I'm just trying to clear the "needinfo" spam on this closed bug.

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