Asbru-cm: Loki - EL7 - Messages while closing some ssh sessions

[popxunga]

Hi Team.

While closing some ssh sessions, I'm seeing messages like this:

[XXX XXXX:xxxxxxxx@xxxxxxxx]/home/xxxxxxxx > exit
Connection to xxx.xxx.xxx.xxx closed.
utf8 "\xE7" does not map to Unicode at /usr/share/asbru-cm/lib/pac_conn line 2008, line 7.
utf8 "\xE0" does not map to Unicode at /usr/share/asbru-cm/lib/pac_conn line 2008, line 8.
utf8 "\xE3" does not map to Unicode at /usr/share/asbru-cm/lib/pac_conn line 2008, line 9.
utf8 "\xE1" does not map to Unicode at /usr/share/asbru-cm/lib/pac_conn line 2008, line 10.
utf8 "\xE3" does not map to Unicode at /usr/share/asbru-cm/lib/pac_conn line 2008, line 12.
utf8 "\xE1" does not map to Unicode at /usr/share/asbru-cm/lib/pac_conn line 2008, line 15.
utf8 "\xE1" does not map to Unicode at /usr/share/asbru-cm/lib/pac_conn line 2008, line 16.
utf8 "\xE1" does not map to Unicode at /usr/share/asbru-cm/lib/pac_conn line 2008, line 17.

Any idea why ?

I could not figure out yet why some trows message like that and other's doesn't.
Better disable the "Close Terminal on disconnection" on Global Preferences while trying to catch them.

Thanks.

[gfrenoy]

Saw this as well sometimes but so far I could not find a way to reproduce it for sure.

[hanspr]

This are encoding problems.

Things to check.

You say some connections, so. Lets find the difference with the ones that do not show messages.
And we have to look for differences that involve non standard ascii characters.

• Do you have save sessions for those connections?
• Do you use a different terminal encoding for those connections?
• Some none standard characters in the title name?

What lines do you have on pac_conn : 2008, because it does not match with anything that would make sense in loki or master.

[popxunga]

Hi @hanspr ...

You spotted it right I guess :+1:

With the "Auto save Session logs" ON, I get the messages.
With the "Auto save Session logs" OFF, I don't get any messages.

I'm using the defaults for terminal encoding on this connection.

The title has Alphanumeric values and - and + char's.
I removed the - and + symbols to test and made no difference.
This are the messages I get with the latest loki build:
utf8 "\xE7" does not map to Unicode at /usr/share/asbru-cm/lib/pac_conn line 2013, line 7.
utf8 "\xE0" does not map to Unicode at /usr/share/asbru-cm/lib/pac_conn line 2013, line 8.
utf8 "\xE3" does not map to Unicode at /usr/share/asbru-cm/lib/pac_conn line 2013, line 9.
utf8 "\xE1" does not map to Unicode at /usr/share/asbru-cm/lib/pac_conn line 2013, line 10.
utf8 "\xE3" does not map to Unicode at /usr/share/asbru-cm/lib/pac_conn line 2013, line 12.
utf8 "\xE1" does not map to Unicode at /usr/share/asbru-cm/lib/pac_conn line 2013, line 15.
utf8 "\xE1" does not map to Unicode at /usr/share/asbru-cm/lib/pac_conn line 2013, line 16.
utf8 "\xE1" does not map to Unicode at /usr/share/asbru-cm/lib/pac_conn line 2013, line 17.

I didn't change anything in the code.

And somewhere during my tests a few minutes ago, these messages appeared in the terminal from where Asbru was launched:

INFO: Using Gnome tray icon
sh: /usr/share/asbru-cm/lib/pac_conn: Permission denied
sh: /usr/share/asbru-cm/lib/pac_conn: Permission denied
sh: /usr/share/asbru-cm/lib/pac_conn: Permission denied

Thanks.

[hanspr]

There is some mismatch in your encodings during all your process.

The server you are connecting is an old server that has a different default encoding that is not UTF8. Or when you are logged, and working, you are collecting bad encoded characters from the source server. Filenames, or text files in the remote server that are encoded incorrectly in the remote server. And those characters are picked up in the terminal with the wrong encoding. Or you open or cat a binary file, etc.

And all this is exposed at the end when that process is reading the file to remove the escape characters from the log file.

There is no way to fix this kind of warnings, because there is a generated mismatch of encodings in all the process that your interactions with the server are producing. As you said it happens in "some" connections, or could be in some interactions.

I have not been able to reproduce, and even if I do, it is not fixable by asbrus code, would have to be fixed in your environment.

In his case the possible solutions that come to mind right now are:

• Check if the server has a different encoding than utf8, and then set the correct encoding translation in the terminal.
• Look for the things that you do: listings, editing, cat files, etc. And visually see if there are some strange characters in the screen.

Regarding the sh: /usr/share/asbru-cm/lib/pac_conn: Permission denied

Could you confirm what are the permissons for that file?, should be 755 I guess.

@gfrenoy

This kind of issues are unfixable. And we can not manage the errors messages (warnings) because they come from internal libraries. If there are mismatched encodings is not like we can test all encodings to see which one does not create an error. And if we get an encoding that does not generate an error, it does not mean we peaked the right one, because the original "page" encodings overlap with each other.

In this cases we either:

• hide them, to avoid displaying them (so we give a clean exit)
• hide them, and see test to see if the process was clean or not, and give a better warning. But we have to consider that we are at the end of a deign process.
• or live with them and document so the users dedicates time to find the mismatch in his environment.

[hanspr]

@popxunga

There is one more experiment we can try. But because I can not reproduce, I do not know that it will "hide the errors", or generate side effects like moving the error to a different section of the code, or that will mess up everything with other encodings when they are correct.

Change the encoding to "raw" in lines 2009,2015

Remove all the code on the square area, that section of code has never worked there.

So try it on the connections that create the issues, and in the ones that not. And the files that were generated.

Regarding the files, the ones that come from the incorrect encodings will have some sort of garbage characters in it, but the ones that do not created problems, should not. If any of the connections that did not have warnings has bad encoded characters, then that would be a bad side effect.

[hanspr]

I've done some crazy tests on my side with this changes and it did not showed warnings. And the rest apparently works fine.

Tell me how did it go with you when you get some time.

[popxunga]

Hi @hanspr ...
The problem may be caused by some accented char's in the banner displayed after login into the remote system. Those char's are not rendered correctly in the ssh session, probably because the text was written somewhere and then transferred into the remote system which does not support the original text encoding.
But just tried the modification suggested above, and I got a clean exit without any messages.
Then I inspected the session saved log file and it looks good (the accented char's are correctly rendered in my system). And I didn't notice any side effect.
Thanks !

[popxunga]

Hi @hanspr ...

This ...
"Regarding the sh: /usr/share/asbru-cm/lib/pac_conn: Permission denied
Could you confirm what are the permissons for that file?, should be 755 I guess."

... was caused & solved already by @gfrenoy while trying to fix other issue.

So don't worry.

Thanks.

[hanspr]

Ok, I will include the changes in the branch where we are migrating the code to a new configuration settings.

[popxunga]

Hi @hanspr ...
Will you mention it here at that time ?
May I close the issue or should I let it open ?
Thanks.

[hanspr]

Let it open, and just follow merge #515 that will require more testing, we are moving away from pac config dir to an asbru config dir, to finally brand everything under asbru.

[popxunga]

Ok ! Thanks.

[gfrenoy]

Can we consider this closed now ?

[popxunga]

Sure 🙂