SOLVED Getting console on iocage very slow? CSH Uses lots of memory.

[tobiasbp]

Hello there...

I have a iocage jail running on a FreeNAS 11.2-U3 system. The jail runs a bunch of python scripts accessing various systems using REST API's. When I try to log in to the jail using the command iocage console JAIL_NAME from the host system, it takes +60 seconds until I eventually get a prompt on the system (jail). Logging out from the jail, with the command exit also takes a VERY long time. On the FreeNAS host system, the following are the top processes during the slow log from the jail. csh takes a LOT of memory! During login, the memory use rises to +40000M. Any suggestions?

Code:

last pid:  2589;  load averages:  1.59,  1.43,  1.15                                               up 130+04:31:38 10:32:52
123 processes: 2 running, 121 sleeping
CPU: 13.9% user,  0.0% nice,  7.9% system,  0.3% interrupt, 78.0% idle
Mem: 13G Active, 13G Inact, 8425M Laundry, 87G Wired, 3056M Free
ARC: 62G Total, 14G MFU, 44G MRU, 65M Anon, 732M Header, 3200M Other
     53G Compressed, 61G Uncompressed, 1.16:1 Ratio
Swap: 10G Total, 10G Free

  PID USERNAME       THR PRI NICE   SIZE    RES STATE   C   TIME    WCPU COMMAND
  548 root             1 103    0 36745M 31084M CPU3    3   5:13  99.18% csh
  292 root            20  52    0   452M   408M kqread  4  47.6H  20.41% python3.6
5569 root             1  24    0   222M   194M select  1   0:32  17.34% smbd
2541 root             5  24    0   220M   165M select  4   0:01   4.80% smbd
74427 root             1  20    0   223M   195M select  5   0:46   2.24% smbd
94835 root             1  20    0   225M   192M select  0   0:08   0.80% smbd
91621 root             1  24    0   222M   194M select  7   2:19   0.56% smbd
...
...

From the FreeNAS host, I see these processes running in the jail (has id 4) at a time where my scripts are not running (from cron):

Code:

ps -J 4

PID TT  STAT    TIME COMMAND
9098  -  SsJ  0:31.77 /usr/sbin/syslogd -c -ss
9157  -  SsJ  3:39.30 sendmail: accepting connections (sendmail)
9162  -  IsJ  0:03.49 sendmail: Queue runner@00:30:00 for /var/spool/clientmqueue (sendmail)
9178  -  IsJ  0:56.07 /usr/sbin/cron -J 15 -s

Thanks,
Tobias

Edit: More data from top showing memory on system.
Edit: Added list of processes in jail

 

[sretalla]

The memory use explains the time taken.

We need to understand what is (clearly very extremely) broken to cause the memory use.

Does this also occur for a newly created jail on the same host?

What version is the jail?

Does this happen right after a restart of the jail? or does it take some time to become slow after a restart?

 

[tobiasbp]

Does this also occur for a newly created jail on the same host?

It was not like this when the jail was created. Do you want me to create a new jail to confirm?

What version is the jail?

I'm not sure what to answer here. The jail is using release 11.2-RELEASE.

Code:

root@FOOBAR:~ # iocage -v
Version    FreeNAS 11.2-U3

Does this happen right after a restart of the jail? or does it take some time to become slow after a restart?

I have not tried. Should I restart the jail or keep it running for examination purposes?

 

[sretalla]

I have not tried. Should I restart the jail or keep it running for examination purposes?

I'm not sure that we'll find anything easily and I don't see value in trying to do a memory dump to preserve what's currently going on (I personally don't want to trawl through 40GB of dump to get to something meaningful, so let's just experiment with a restart and go from there.

I'm not sure what to answer here. The jail is using release 11.2-RELEASE.

That's clear enough, I was wanting to confirm that the version of the jail wasn't still 9.10 or older.

Do you want me to create a new jail to confirm?

I think that might help to see if the problem is specific to the host or to the jail.

 

[tobiasbp]

...., so let's just experiment with a restart and go from there.

I have started and stopped the jail. Works as it should. iocage console JAILNAME still takes a long time (Don't know how long). Quitting with CTRL+C while waiting for the jail console, exits the process, and gets me a console in the jail. So, the memory is taken up by something external to the jail (Not sure of the terminology here)?

Logging out from the jail, still uses lots of memory and takes a long time.

Thanks,
Tobias

 

[sretalla]

OK, so next would be to work out if a new jail also has the problem... please share the outcome of creating a new jail.

 

[tobiasbp]

OK, so next would be to work out if a new jail also has the problem... please share the outcome of creating a new jail.

I have created a jail from scratch with no apparent issues

Code:

iocage create --name foobar-jail -r 11.2-RELEASE dhcp=on vnet=on ip4_addr="DHCP"
dhcp requires bpf, setting to yes!
foobar-jail successfully created!


# iocage start foobar-jail
* Starting foobar-jail
  + Started OK
  + Configuring VNET OK
  + DHCP Address: 172.22.33.120/24
  + Starting services OK

# iocage console foobar-jail
FreeBSD 11.2-STABLE (FreeNAS.amd64) #0 r325575+9a3c7d8b53f(HEAD): Wed Mar 27 12:41:58 EDT 2019

Welcome to FreeBSD!

Release Notes, Errata: https://www.FreeBSD.org/releases/
Security Advisories:   https://www.FreeBSD.org/security/
FreeBSD Handbook:      https://www.FreeBSD.org/handbook/
FreeBSD FAQ:           https://www.FreeBSD.org/faq/
Questions List: https://lists.FreeBSD.org/mailman/listinfo/freebsd-questions/
FreeBSD Forums:        https://forums.FreeBSD.org/

Documents installed with the system are in the /usr/local/share/doc/freebsd/
directory, or can be installed later with:  pkg install en-freebsd-doc
For other languages, replace "en" with a language code like de or fr.

Show the version of FreeBSD installed:  freebsd-version ; uname -a
Please include that output and any error messages when posting questions.
Introduction to manual pages:  man man
FreeBSD directory layout:      man hier

Edit /etc/motd to change this login announcement.
root@foobar-jail:~ # ls -lha
total 51
drwxr-xr-x   2 root  wheel     6B Jun 22  2018 .
drwxr-xr-x  18 root  wheel    22B May  8  2019 ..
-rw-r--r--   2 root  wheel   957B Jun 22  2018 .cshrc
-rw-r--r--   1 root  wheel   149B Jun 22  2018 .k5login
-rw-r--r--   1 root  wheel   395B Jun 22  2018 .login
-rw-r--r--   2 root  wheel   474B Jun 22  2018 .profile

exit

#iocage destroy foobar-jail
This will destroy jail foobar-jail
Are you sure? [y/N]: y
Stopping foobar-jail
Destroying foobar-jail

Thanks!

 

[sretalla]

OK, so it's your specific jail that's the issue... how hard would it be for you to put those scripts in a new jail? (maybe it's just easier to do that than to try to work out what's happening in that jail... or maybe it will show up the part of the setup that breaks it)

 

[tobiasbp]

Sorry for the delay. I'm now back at work (and this issue).

I'm planning to upgrade to the latest version of FreeNAS on the jail host this weekend. I'll see if this makes a change to the way the jail behaves when logging in/out. I should probably to a reebot forst, to see if that changes anything (For the jail) before upgrading.

I'm wondering what csh does when logging in/out. Could that be investigated somehow? (EDIT: It reads the contents of the file .history and keeps it in RAM. See below.)

 

[sretalla]

Since your problem is jail specific, I very much doubt that upgrading the FreeNAS version will fix anything.

Can you try to re-create your script setup in a new jail?

 

[tobiasbp]

Since your problem is jail specific, I very much doubt that upgrading the FreeNAS version will fix anything.

I agree, but I need to upgrade anyway, so I might as well see if it changes anything.

Can you try to re-create your script setup in a new jail?

Yes, I'll do so if rebooting/upgrading does nothing (Like we expect). The jail used to behave normally. This problem is "new" (I don't log in to the jail very often).

Thanks,
Tobias

 

[tobiasbp]

Hello again.... I was finally able to find a suitable time for upgrading. As expected, upgrading/rebooting changed noting. I still see the same excessive use of RAM by csh when trying access the jail with iocage console JAIL-NAME.

After the upgrade, I can no longer get at console in the jail. This is what I get in /var/log/messages:

Code:

Dec 28 19:34:50 SERVER-NAME kernel: pid 37810 (csh), uid 0: exited on signal 11

How can I investigate what csh is doing when I log in?

 

[tobiasbp]

OK, so it's your specific jail that's the issue...

From the host, a directory holding around 6TB is shared. From the jail, the data is accessible via a dir in /var. The dir was empty when I created the jail, and has been growing ever since. Could that somehow cause the problems I'm seeing? csh needs to cache/look at all the data in the growing dir?

Thanks,
Tobias

 

[sretalla]

Can you move that data aside on the host and restart the jail with the data not present?

Maybe your application is somehow wanting to cache the data or make some kind of metadata summary and isn't releasing the memory.

 

[tobiasbp]

Can you move that data aside on the host and restart the jail with the data not present?

Maybe your application is somehow wanting to cache the data or make some kind of metadata summary and isn't releasing the memory.

I can't move the data, but I could shut down the jail, and the reconfigure it so it can not access the dirs on the host. What do you think about doing that?

 

[sretalla]

That sounds like a reasonable step. Let's see how it goes.

 

[tobiasbp]

That sounds like a reasonable step. Let's see how it goes.

Issue identified. It's not related to the shared dir. The issue is a 3.5GB .history file. I have renamed it to .history.old so it will not be used bu the csh. I can get a console on the jail as before.

In .history I see find commands, which must be ones issued by one of my automation scripts. looks like it's unicode related to me. In this part: ...<U+0083>Â<U+0082>Ã<U+0082>Â<U+0098>rsted\ \[CG2]/, the stuff before rsted should be the danish character "Ø". The script in question builds a hierarchy of client dirs.

Looking at the timestamps for the 'bad' commands, they seem to all to share the same one: '1559914262'. I'm assuming that having the same timestamp more than once is unexpected. Notice how each command get bigger and bigger.

There seems to be 30 of these:
root@xxx:~ # grep 1559914262 .history.old | wc -l 30

In fact, there are 4 timestamps that have multiple entries. Looking at the timestamps, the 4 incidents happened around the same time.

Code:

  30 #+1559914262
  29 #+1559914281
  28 #+1559914791
  28 #+1559914823

This post appears to describe the same thing happening with tsch on Debian GNU/Linux.

In .login i have added the following line: setenv LANG en_US.UTF-8
I wonder if could be related to the issue (Since it appears to be unicode related)?

I'll monitor the new .history and take take a look at my (python) scripts again and see what I can figure out. Thank you for the moral support @sretalla.

Code:

...
...
#+1559914262
find Ørsted\ \[CG2]/
#+1559914262
find Ã<U+0083>Â<U+0083>Ã<U+0082>Â<U+0083>Ã<U+0083>Â<U+0082>Ã<U+0082>Â<U+0083>Ã<U+0083>Â<U+0083>Ã<U+0082>Â<U+0082>Ã<U+0083>Â
<U+0082>Ã<U+0082>Â<U+0083>Ã<U+0083>Â<U+0083>Ã<U+0082>Â<U+0083>Ã<U+0083>Â<U+0082>Ã<U+0082>Â<U+0082>Ã<U+0083>Â<U+0083>Ã
<U+0082>Â<U+0082>Ã<U+0083>Â<U+0082>Ã<U+0082>Â<U+0083>Ã<U+0083>Â<U+0083>Ã<U+0082>Â<U+0083>Ã<U+0083>Â<U+0082>Ã<U+0082>Â
<U+0083>Ã<U+0083>Â<U+0083>Ã<U+0082>Â<U+0082>Ã<U+0083>Â<U+0082>Ã<U+0082>Â<U+0082>Ã<U+0083>Â<U+0083>Ã<U+0082>Â<U+0083>Ã
<U+0083>Â<U+0082>Ã<U+0082>Â<U+0082>Ã<U+0083>Â<U+0083>Ã<U+0082>Â<U+0082>Ã<U+0083>Â<U+0082>Ã<U+0082>Â<U+0083>Ã<U+0083>Â
<U+0083>Ã<U+0082>Â<U+0083>Ã<U+0083>Â<U+0082>Ã<U+0082>Â<U+0083>Ã<U+0083>Â<U+0083>Ã<U+0082>Â<U+0082>Ã<U+0083>Â<U+0082>Ã
<U+0082>Â<U+0083>Ã<U+0083>Â<U+0083>Ã<U+0082>Â<U+0083>Ã<U+0083>Â<U+0082>Ã<U+0082>Â<U+0082>Ã<U+0083>Â<U+0083>Ã<U+0082>Â
<U+0082>Ã<U+0083>Â<U+0082>Ã<U+0082>Â<U+0082>Ã<U+0083>Â<U+0083>Ã<U+0082>Â<U+0083>Ã<U+0083>Â<U+0082>Ã<U+0082>Â<U+0083>Ã
<U+0083>Â<U+0083>Ã<U+0082>Â<U+0082>Ã<U+0083>Â<U+0082>Ã<U+0082>Â<U+0082>Ã<U+0083>Â<U+0083>Ã<U+0082>Â<U+0083>Ã<U+0083>Â
<U+0082>Ã<U+0082>Â<U+0082>Ã<U+0083>Â<U+0083>Ã<U+0082>Â<U+0082>Ã<U+0083>Â<U+0082>Ã<U+0082>Â<U+0098>rsted\ \[CG2]/
#+1559914262
find Ã<U+0083>Â<U+0083>Ã<U+0082>Â<U+0083>Ã<U+0083>Â<U+0082>Ã<U+0082>Â<U+0083>Ã<U+0083>Â<U+0083>Ã<U+0082>Â<U+0082>Ã<U+0083>Â
<U+0082>Ã<U+0082>Â<U+0083>Ã<U+0083>Â<U+0083>Ã<U+0082>Â<U+0083>Ã<U+0083>Â<U+0082>Ã<U+0082>Â<U+0082>Ã<U+0083>Â<U+0083>Ã
<U+0082>Â<U+0082>Ã<U+0083>Â<U+0082>Ã<U+0082>Â<U+0083>Ã<U+0083>Â<U+0083>Ã<U+0082>Â<U+0083>Ã<U+0083>Â<U+0082>Ã<U+0082>Â
<U+0083>Ã<U+0083>Â<U+0083>Ã<U+0082>Â<U+0082>Ã<U+0083>Â<U+0082>Ã<U+0082>Â<U+0082>Ã<U+0083>Â<U+0083>Ã<U+0082>Â<U+0083>Ã
<U+0083>Â<U+0082>Ã<U+0082>Â<U+0082>Ã<U+0083>Â<U+0083>Ã<U+0082>Â<U+0082>Ã<U+0083>Â<U+0082>Ã<U+0082>Â<U+0083>Ã<U+0083>Â
<U+0083>Ã<U+0082>Â<U+0083>Ã<U+0083>Â<U+0082>Ã<U+0082>Â<U+0083>Ã<U+0083>Â<U+0083>Ã<U+0082>Â<U+0082>Ã<U+0083>Â<U+0082>Ã
<U+0082>Â<U+0083>Ã<U+0083>Â<U+0083>Ã<U+0082>Â<U+0083>Ã<U+0083>Â<U+0082>Ã<U+0082>Â<U+0082>Ã<U+0083>Â<U+0083>Ã<U+0082>Â
<U+0082>Ã<U+0083>Â<U+0082>Ã<U+0082>Â<U+0082>Ã<U+0083>Â<U+0083>Ã<U+0082>Â<U+0083>Ã<U+0083>Â<U+0082>Ã<U+0082>Â<U+0083>Ã
<U+0083>Â<U+0083>Ã<U+0082>Â<U+0082>Ã<U+0083>Â<U+0082>Ã<U+0082>Â<U+0082>Ã<U+0083>Â<U+0083>Ã<U+0082>Â<U+0083>Ã<U+0083>Â
<U+0082>Ã<U+0082>Â<U+0082>Ã<U+0083>Â<U+0083>Ã<U+0082>Â<U+0082>Ã<U+0083>Â<U+0082>Ã<U+0082>Â<U+0083>Ã<U+0083>Â<U+0083>Ã
<U+0082>Â<U+0083>Ã<U+0083>Â<U+0082>Ã<U+0082>Â<U+0083>Ã<U+0083>Â<U+0083>Ã<U+0082>Â<U+0082>Ã<U+0083>Â<U+0082>Ã<U+0082>Â
<U+0083>Ã<U+0083>Â<U+0083>Ã<U+0082>Â<U+0083>Ã<U+0083>Â<U+0082>Ã<U+0082>Â<U+0082>Ã<U+0083>Â<U+0083>Ã<U+0082>Â<U+0082>Ã
<U+0083>Â<U+0082>Ã<U+0082>Â<U+0083>Ã<U+0083>Â<U+0083>Ã<U+0082>Â<U+0083>Ã<U+0083>Â<U+0082>Ã<U+0082>Â<U+0083>Ã<U+0083>Â
<U+0083>Ã<U+0082>Â<U+0082>Ã<U+0083>Â<U+0082>Ã<U+0082>Â<U+0082>Ã<U+0083>Â<U+0083>Ã<U+0082>Â<U+0083>Ã<U+0083>Â<U+0082>Ã
<U+0082>Â<U+0082>Ã<U+0083>Â<U+0083>Ã<U+0082>Â<U+0082>Ã<U+0083>Â<U+0082>Ã<U+0082>Â<U+0082>Ã<U+0083>Â<U+0083>Ã<U+0082>Â
<U+0083>Ã<U+0083>Â<U+0082>Ã<U+0082>Â<U+0083>Ã<U+0083>Â<U+0083>Ã<U+0082>Â<U+0082>Ã<U+0083>Â<U+0082>Ã<U+0082>Â<U+0083>Ã
<U+0083>Â<U+0083>Ã<U+0082>Â<U+0083>Ã<U+0083>Â<U+0082>Ã<U+0082>Â<U+0082>Ã<U+0083>Â<U+0083>Ã<U+0082>Â<U+0082>Ã<U+0083>Â
<U+0082>Ã<U+0082>Â<U+0082>Ã<U+0083>Â<U+0083>Ã<U+0082>Â<U+0083>Ã<U+0083>Â<U+0082>Ã<U+0082>Â<U+0083>Ã<U+0083>Â<U+0083>Ã
<U+0082>Â<U+0082>Ã<U+0083>Â<U+0082>Ã<U+0082>Â<U+0082>Ã<U+0083>Â<U+0083>Ã<U+0082>Â<U+0083>Ã<U+0083>Â<U+0082>Ã<U+0082>Â
<U+0082>Ã<U+0083>Â<U+0083>Ã<U+0082>Â<U+0082>Ã<U+0083>Â<U+0082>Ã<U+0082>Â<U+0098>rsted\ \[CG2]/
find Ã<U+0083>Â<U+0083>Ã<U+0082>Â<U+0083>Ã<U+0083>Â<U+0082>Ã<U+0082>Â<U+0083>Ã<U+0083>Â<U+0083>Ã<U+0082>Â<U+0082>Ã<U+0083>Â
<U+0082>Ã<U+0082>Â<U+0083>Ã<U+0083>Â<U+0083>Ã<U+0082>Â<U+0083>Ã<U+0083>Â<U+0082>Ã<U+0082>Â<U+0082>Ã<U+0083>Â<U+0083>Ã
<U+0082>Â<U+0082>Ã<U+0083>Â<U+0082>Ã<U+0082>Â<U+0083>Ã<U+0083>Â<U+0083>Ã<U+0082>Â<U+0083>Ã<U+0083>Â<U+0082>Ã<U+0082>Â
<U+0083>Ã<U+0083>Â<U+0083>Ã<U+0082>Â<U+0082>Ã<U+0083>Â<U+0082>Ã<U+0082>Â<U+0082>Ã<U+0083>Â<U+0083>Ã<U+0082>Â<U+0083>Ã
<U+0083>Â<U+0082>Ã<U+0082>Â<U+0082>Ã<U+0083>Â<U+0083>Ã<U+0082>Â<U+0082>Ã<U+0083>Â<U+0082>Ã<U+0082>Â<U+0083>Ã<U+0083>Â
<U+0083>Ã<U+0082>Â<U+0083>Ã<U+0083>Â<U+0082>Ã<U+0082>Â<U+0083>Ã<U+0083>Â<U+0083>Ã<U+0082>Â<U+0082>Ã<U+0083>Â<U+0082>Ã
<U+0082>Â<U+0083>Ã<U+0083>Â<U+0083>Ã<U+0082>Â<U+0083>Ã<U+0083>Â<U+0082>Ã<U+0082>Â<U+0082>Ã<U+0083>Â<U+0083>Ã<U+0082>Â
<U+0082>Ã<U+0083>Â<U+0082>Ã<U+0082>Â<U+0082>Ã<U+0083>Â<U+0083>Ã<U+0082>Â<U+0083>Ã<U+0083>Â<U+0082>Ã<U+0082>Â<U+0083>Ã
<U+0083>Â<U+0083>Ã<U+0082>Â<U+0082>Ã<U+0083>Â<U+0082>Ã<U+0082>Â<U+0082>Ã<U+0083>Â<U+0083>Ã<U+0082>Â<U+0083>Ã<U+0083>Â
<U+0082>Ã<U+0082>Â<U+0082>Ã<U+0083>Â<U+0083>Ã<U+0082>Â<U+0082>Ã<U+0083>Â<U+0082>Ã<U+0082>Â<U+0083>Ã<U+0083>Â<U+0083>Ã
<U+0082>Â<U+0083>Ã<U+0083>Â<U+0082>Ã<U+0082>Â<U+0083>Ã<U+0083>Â<U+0083>Ã<U+0082>Â<U+0082>Ã<U+0083>Â<U+0082>Ã<U+0082>Â
<U+0083>Ã<U+0083>Â<U+0083>Ã<U+0082>Â<U+0083>Ã<U+0083>Â<U+0082>Ã<U+0082>Â<U+0082>Ã<U+0083>Â<U+0083>Ã<U+0082>Â<U+0082>Ã
<U+0083>Â<U+0082>Ã<U+0082>Â<U+0083>Ã<U+0083>Â<U+0083>Ã<U+0082>Â<U+0083>Ã<U+0083>Â<U+0082>Ã<U+0082>Â<U+0083>Ã<U+0083>Â
<U+0083>Ã<U+0082>Â<U+0082>Ã<U+0083>Â<U+0082>Ã<U+0082>Â<U+0082>Ã<U+0083>Â<U+0083>Ã<U+0082>Â<U+0083>Ã<U+0083>Â<U+0082>Ã
<U+0082>Â<U+0082>Ã<U+0083>Â<U+0083>Ã<U+0082>Â<U+0082>Ã<U+0083>Â<U+0082>Ã<U+0082>Â<U+0082>Ã<U+0083>Â<U+0083>Ã<U+0082>Â
<U+0083>Ã<U+0083>Â<U+0082>Ã<U+0082>Â<U+0083>Ã<U+0083>Â<U+0083>Ã<U+0082>Â<U+0082>Ã<U+0083>Â<U+0082>Ã<U+0082>Â<U+0083>Ã
<U+0083>Â<U+0083>Ã<U+0082>Â<U+0083>Ã<U+0083>Â<U+0082>Ã<U+0082>Â<U+0082>Ã<U+0083>Â<U+0083>Ã<U+0082>Â<U+0082>Ã<U+0083>Â
<U+0082>Ã<U+0082>Â<U+0082>Ã<U+0083>Â<U+0083>Ã<U+0082>Â<U+0083>Ã<U+0083>Â<U+0082>Ã<U+0082>Â<U+0083>Ã<U+0083>Â<U+0083>Ã
<U+0082>Â<U+0082>Ã<U+0083>Â<U+0082>Ã<U+0082>Â<U+0082>Ã<U+0083>Â<U+0083>Ã<U+0082>Â<U+0083>Ã<U+0083>Â<U+0082>Ã<U+0082>Â
<U+0082>Ã<U+0083>Â<U+0083>Ã<U+0082>Â<U+0082>Ã<U+0083>Â<U+0082>Ã<U+0082>Â<U+0083>Ã<U+0083>Â<U+0083>Ã<U+0082>Â<U+0083>Ã
<U+0083>Â<U+0082>Ã<U+0082>Â<U+0083>Ã<U+0083>Â<U+0083>Ã<U+0082>Â<U+0082>Ã<U+0083>Â<U+0082>Ã<U+0082>Â<U+0083>Ã<U+0083>Â
<U+0083>Ã<U+0082>Â<U+0083>Ã<U+0083>Â<U+0082>Ã<U+0082>Â<U+0082>Ã<U+0083>Â<U+0083>Ã<U+0082>Â<U+0082>Ã<U+0083>Â<U+0082>Ã
<U+0082>Â<U+0083>Ã<U+0083>Â<U+0083>Ã<U+0082>Â<U+0083>Ã<U+0083>Â<U+0082>Ã<U+0082>Â<U+0083>Ã<U+0083>Â<U+0083>Ã<U+0082>Â
<U+0082>Ã<U+0083>Â<U+0082>Ã<U+0082>Â<U+0082>Ã<U+0083>Â<U+0083>Ã<U+0082>Â<U+0083>Ã<U+0083>Â<U+0082>Ã<U+0082>Â<U+0082>Ã
<U+0083>Â<U+0083>Ã<U+0082>Â<U+0082>Ã<U+0083>Â<U+0082>Ã<U+0082>Â<U+0083>Ã<U+0083>Â<U+0083>Ã<U+0082>Â<U+0083>Ã<U+0083>Â
<U+0082>Ã<U+0082>Â<U+0083>Ã<U+0083>Â<U+0083>Ã<U+0082>Â<U+0082>Ã<U+0083>Â<U+0082>Ã<U+0082>Â<U+0083>Ã<U+0083>Â<U+0083>Ã
<U+0082>Â<U+0083>Ã<U+0083>Â<U+0082>Ã<U+0082>Â<U+0082>Ã<U+0083>Â<U+0083>Ã<U+0082>Â<U+0082>Ã<U+0083>Â<U+0082>Ã<U+0082>Â
<U+0082>Ã<U+0083>Â<U+0083>Ã<U+0082>Â<U+0083>Ã<U+0083>Â<U+0082>Ã<U+0082>Â<U+0083>Ã<U+0083>Â<U+0083>Ã<U+0082>Â<U+0082>Ã
<U+0083>Â<U+0082>Ã<U+0082>Â<U+0082>Ã<U+0083>Â<U+0083>Ã<U+0082>Â<U+0083>Ã<U+0083>Â<U+0082>Ã<U+0082>Â<U+0082>Ã<U+0083>Â
<U+0083>Ã<U+0082>Â<U+0082>Ã<U+0083>Â<U+0082>Ã<U+0082>Â<U+0082>Ã<U+0083>Â<U+0083>Ã<U+0082>Â<U+0083>Ã<U+0083>Â<U+0082>Ã
<U+0082>Â<U+0083>Ã<U+0083>Â<U+0083>Ã<U+0082>Â<U+0082>Ã<U+0083>Â<U+0082>Ã<U+0082>Â<U+0083>Ã<U+0083>Â<U+0083>Ã<U+0082>Â
<U+0083>Ã<U+0083>Â<U+0082>Ã<U+0082>Â<U+0082>Ã<U+0083>Â<U+0083>Ã<U+0082>Â<U+0082>Ã<U+0083>Â<U+0082>Ã<U+0082>Â<U+0083>Ã
<U+0083>Â<U+0083>Ã<U+0082>Â<U+0083>Ã<U+0083>Â<U+0082>Ã<U+0082>Â<U+0083>Ã<U+0083>Â<U+0083>Ã<U+0082>Â<U+0082>Ã<U+0083>Â
<U+0082>Ã<U+0082>Â<U+0082>Ã<U+0083>Â<U+0083>Ã<U+0082>Â<U+0083>Ã<U+0083>Â<U+0082>Ã<U+0082>Â<U+0082>Ã<U+0083>Â<U+0083>Ã
<U+0082>Â<U+0082>Ã<U+0083>Â<U+0082>Ã<U+0082>Â<U+0082>Ã<U+0083>Â<U+0083>Ã<U+0082>Â<U+0083>Ã<U+0083>Â<U+0082>Ã<U+0082>Â
<U+0083>Ã<U+0083>Â<U+0083>Ã<U+0082>Â<U+0082>Ã<U+0083>Â<U+0082>Ã<U+0082>Â<U+0083>Ã<U+0083>Â<U+0083>Ã<U+0082>Â<U+0083>Ã
<U+0083>Â<U+0082>Ã<U+0082>Â<U+0082>Ã<U+0083>Â<U+0083>Ã<U+0082>Â<U+0082>Ã<U+0083>Â<U+0082>Ã<U+0082>Â<U+0082>Ã<U+0083>Â
<U+0083>Ã<U+0082>Â<U+0083>Ã<U+0083>Â<U+0082>Ã<U+0082>Â<U+0083>Ã<U+0083>Â<U+0083>Ã<U+0082>Â<U+0082>Ã<U+0083>Â<U+0082>Ã
<U+0082>Â<U+0082>Ã<U+0083>Â<U+0083>Ã<U+0082>Â<U+0083>Ã<U+0083>Â<U+0082>Ã<U+0082>Â<U+0082>Ã<U+0083>Â<U+0083>Ã<U+0082>Â
<U+0082>Ã<U+0083>Â<U+0082>Ã<U+0082>Â<U+0098>rsted\ \[CG2]/
#+1559914262
...
...

 

[tobiasbp]

I have been able to replicate. Seems like once you have unicode characters in .history, those lines will be duplicated when the file is updated on logout. Notice the lines with the following timestamp: #+1577978948

Code:

...
...
#+1577978601
tail -400 .history.old
#+1577978621
more .history.old
#+1577978948
æøå
#+1577978948
æøå
#+1577978948
æøÃÂ¥
#+1577978948
ÃÂæÃÂøÃÂÃÂ¥
#+1577978948
ÃÂÃÂÃÂæÃÂÃÂÃÂøÃÂÃÂÃÂÃÂ¥
...
...

So, if I ever use unicode characters (with my configuration) with tsch, I will get an exponentially growing .history file? Is my system misconfigured? If so, which parametr(s) do I need to change?

In .login I have removed the following line: setenv LANG en_US.UTF-8. I can no longer enter unicode characters on the command line, so the problem of having unicode characters in .history can no longer happen.

This prevents me from showing the proper file names (with unicode characters), which is quite annoying.

 

[sretalla]

I'm no expert in unicode character sets and their use, so will need to leave it to others to respond.

 

[tobiasbp]

I'm no expert in unicode character sets and their use, so will need to leave it to others to respond.

Maybe I should write a new post about this issue. It might also be a an issue in FreeNAS proper (Unicode characters are allowed in the shell). I have not (dated to) test it.

Thank you for your help.