Bug 4854 - traceback when trying to get public session info
Summary: traceback when trying to get public session info
Status: CLOSED FIXED
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: VSM Server (show other bugs)
Version: trunk
Hardware: PC Unknown
: P2 Normal
Target Milestone: 4.2.0
Assignee: Pierre Ossman
URL:
Keywords: hean01_tester, prosaic
Depends on:
Blocks:
 
Reported: 2013-10-16 14:59 CEST by Pierre Ossman
Modified: 2014-04-01 16:03 CEST (History)
1 user (show)

See Also:
Acceptance Criteria:


Attachments

Description Pierre Ossman cendio 2013-10-16 14:59:28 CEST
Getting this both from tl-mount-localdrives as well as tl-session-param:

bash-4.2$ tl-session-param -a /
Traceback (most recent call last):
  File "/opt/thinlinc/bin/tl-session-param", line 149, in <module>
    I111IiIi ( )
  File "/opt/thinlinc/bin/tl-session-param", line 105, in I111IiIi
    IiIiIi = get_public_sessioninfo ( IiII1IiiIiI1 )
  File "/opt/thinlinc/modules/thinlinc/ctccommon.py", line 140, in get_public_sessioninfo
    display )
  File "/usr/lib64/python2.7/xmlrpclib.py", line 1224, in __call__
    return self.__send(self.__name, args)
  File "/usr/lib64/python2.7/xmlrpclib.py", line 1578, in __request
    verbose=self.__verbose
  File "/usr/lib64/python2.7/xmlrpclib.py", line 1264, in request
    return self.single_request(host, handler, request_body, verbose)
  File "/usr/lib64/python2.7/xmlrpclib.py", line 1294, in single_request
    response = h.getresponse(buffering=True)
  File "/usr/lib64/python2.7/httplib.py", line 1045, in getresponse
    response.begin()
  File "/usr/lib64/python2.7/httplib.py", line 409, in begin
    version, status, reason = self._read_status()
  File "/usr/lib64/python2.7/httplib.py", line 373, in _read_status
    raise BadStatusLine(line)
httplib.BadStatusLine: ''

This is on Fedora 19 with build 4115.
Comment 1 Pierre Ossman cendio 2013-10-16 15:02:42 CEST
This is in vsmserver.log:

2013-10-16 14:53:23 ERROR vsmserver: Unhandled XMLRPC exception: <type 'exceptions.UnicodeEncodeError'> 'ascii' codec can't encode character u'\xe5' in position 1: ordinal not in range(128) Traceback (most recent call last):
  File "/opt/thinlinc/modules/thinlinc/vsm/async.py", line 112, in iii11
    obj . handle_read_event ( )
  File "/usr/lib64/python2.7/asyncore.py", line 449, in handle_read_event
    self.handle_read()
  File "/usr/lib64/python2.7/asynchat.py", line 140, in handle_read
    self.found_terminator()
  File "/opt/thinlinc/modules/thinlinc/vsm/xmlrpc.py", line 530, in found_terminator
    self . handle_request ( )
  File "/opt/thinlinc/modules/thinlinc/vsm/xmlrpc.py", line 544, in handle_request
    self . handle_method ( )
  File "/opt/thinlinc/modules/thinlinc/vsm/vsmserverchannel.py", line 109, in handle_method
    self . params )
  File "/opt/thinlinc/modules/thinlinc/vsm/handler_getpublicsessioninfo.py", line 16, in handle
    IiII1IiiIiI1 = pwd . getpwnam ( IiII1IiiIiI1 ) . pw_name
UnicodeEncodeError: 'ascii' codec can't encode character u'\xe5' in position 1: ordinal not in range(128)


So it seems to be a variant of bug 4316. Perhaps systemd is starting vsmserver in a weird locale?
Comment 4 Pierre Ossman cendio 2013-12-13 12:48:37 CET
Fixed in r28199 and r28200.
Comment 5 Henrik Andersson cendio 2014-03-20 09:32:50 CET
I need a valid test case for this bug, is it enough running tl-session-param within a sessions as a user with non ascii character in username ?
Comment 6 Pierre Ossman cendio 2014-03-20 12:38:48 CET
(In reply to comment #5)
> I need a valid test case for this bug, is it enough running tl-session-param
> within a sessions as a user with non ascii character in username ?

Yes. That tests the bug in vsm. To test the fix in ctccommon you have to have a broken vsmserver that closes the connection without any reply (or writes garbage).
Comment 7 Henrik Andersson cendio 2014-03-21 10:46:39 CET
(In reply to comment #6)
> (In reply to comment #5)
> > I need a valid test case for this bug, is it enough running tl-session-param
> > within a sessions as a user with non ascii character in username ?
> 
> Yes. That tests the bug in vsm. To test the fix in ctccommon you have to have a
> broken vsmserver that closes the connection without any reply (or writes
> garbage).

Verified using a raise in getpublicsessioninfo handler.
Comment 8 Henrik Andersson cendio 2014-03-21 10:58:17 CET
Tested using build 4298. Works as expected.

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