Opened 8 years ago

Closed 7 years ago

Last modified 6 years ago

#103 closed defect (fixed)

No active session found

Reported by: Bruno Bigras Owned by: Antoine Martin
Priority: major Milestone: 0.10
Component: Server Keywords:
Cc:

Description (last modified by Antoine Martin)

shifter 0.9.11 from the Ubuntu repo
Kubuntu 9.10 karmic (amd64)

I don't see the session on the client side.

Maybe it's related to this error (see attached log) :

2010/18/04 18:04:40 ValueError: invalid literal for int() with base 10: 'S \xb7'

Attachments (1)

shifter_server.log (15.1 KB) - added by Bruno Bigras 8 years ago.

Download all attachments as: .zip

Change History (10)

comment:1 Changed 8 years ago by Antoine Martin

Resolution: worksforme
Status: newclosed

It is! Thanks for the debug info. I cannot test as I don't have such entries in my /var/log/wtmp

This (untested) workaround should fix it for you though: r2288

You can either download the changeset as a patch or wait for the next release (very soon).
Thank you for your report. Do you want a free account?

Last edited 6 years ago by Antoine Martin (previous) (diff)

comment:2 Changed 8 years ago by Bruno Bigras

Resolution: worksforme
Status: closedreopened

With the latest code, the error changed but is similar:

2010/18/04 19:26:06 LocalX11ServerUtil.found_display(bruno,:S �,,1270222291) failed to parse display number: ':S �', invalid literal for int() with base 10: 'S \xb7'
Last edited 6 years ago by Antoine Martin (previous) (diff)

Changed 8 years ago by Bruno Bigras

Attachment: shifter_server.log added

comment:3 Changed 8 years ago by Antoine Martin

The latest code is meant to display this error when it encounters what seems like an invalid session in /var/log/wtmp
It should continue to process your wtmp file and process any valid entries it finds and hopefully find your local display.

If your local display is still not being found, maybe your wtmp file is corrupted (unlikely but possible) or maybe pyutmp or python-utmp (whichever one you are using I cannot tell from the logfile - fixed in r2291) is having problems parsing it.

There is a test you can run which will exercise whichever implementation you are using: utmp_test.py
On my systems, I get entries like:

7 1636 tty1 :0 antoine :0 0 None 1259350454 (0, 0, 0, 0)

With python-utmp and:

USER_PROCESS 2043 tty7 :0 antoine :0 0 None 1271601409.0 0

with pyutmp.
The important part here is the :0 which is shown in both cases.

Thanks again for you detailed report.

Last edited 6 years ago by Antoine Martin (previous) (diff)

comment:4 Changed 8 years ago by Antoine Martin

Here is another potential workaround for you: r2292 adds support for parsing the output from the 'last' command. It is not as complete, but should be enough to detect your local display.

To use it, start the server with the command line switch:

shifter_server --debug-mode --getutents=last_getutents

(you must be running svn code or apply the patch above)

Last edited 6 years ago by Antoine Martin (previous) (diff)

comment:5 Changed 8 years ago by Antoine Martin

Released 0.9.11 with the fix earlier. Note that you may still need to use the workaround wtmp override:

shifter_server --debug-mode --getutents=last_getutents
Last edited 7 years ago by Antoine Martin (previous) (diff)

comment:6 Changed 8 years ago by Antoine Martin

The above workaround should work, this is what I get if I run last:

antoine  tty1         :0               Mon Apr 19 13:11   still logged in

There should not be any funny characters in there.
The important part is the ':0', I have assumed that all versions of last print 'still logged in' for doing the parsing...

comment:7 Changed 7 years ago by Antoine Martin

Resolution: fixed
Status: reopenedclosed

Closing as this area has seen improvements:

  • client can now pass the DESKTOP_SESSION variable to the server via a root window property: r2611
  • we properly parse utmp records from "last" to capture the start-datetime: r2612

Also, not received any other error reports.

Last edited 6 years ago by Antoine Martin (previous) (diff)

comment:8 Changed 7 years ago by Antoine Martin

We don't even log errors anymore when we find a "0.0" display: r2565

Last edited 6 years ago by Antoine Martin (previous) (diff)

comment:9 Changed 6 years ago by Antoine Martin

Description: modified (diff)
Note: See TracTickets for help on using tickets.