iocage console is very slow

[chmeeedalf]

Running iocage console <jail> is much much slower than running jexec ioc-<jail>. I ktrace'd a run of iocage console <jail> and saw a long list of forking:

• git (2 times)
• ldconfig (2 times)
• cc (2 times)
• ld.lld
• objdump
• sysctl
• zpool
• zfs (19 time)
• jls (5 times)
• jexec
• login
• setfib
• login
• sh
• resizewin
• sh

All of this takes more than 3 seconds.

Running jexec ioc-<jail> takes under 1 second, with no forking, just a single exec() to the shell.

Questions:

• Why does it run git?
• Why the compiler?
• Why 19 zfs runs?
• Why 5 jls?

Additionally, the first 0.87 seconds of clock time is in the first python process, which seems like a long time, too, on a 2GHz ARM Cortex-A72.

[Defenso-QTH]

Those are called by the standard module library ctypes: ldconfig, cc, objdump.
This behaviour is documented: https://docs.python.org/3.11/library/ctypes.html#module-ctypes

On Linux, find_library() tries to run external programs (/sbin/ldconfig, gcc, objdump and ld) to find the library file. It returns the filename of the library file.

iocage uses it here:

iocage/iocage_lib/utils.py

Lines 5 to 6 in efabda2

	def load_ctypes_library(name, signatures):
	library_name = find_library(name)

For the rest, the code is pretty much self-explanatory since it's python. I am looking forward to your contributions to improve the situation!

[chmeeedalf]

The git part is not clear. From what I can see it should only be called if the jail is a plugin, and none of my jails are plugins.

Running jls 5 times seems a bit excessive to me, as well, along with zfs 19 times. From examining my ktrace of this one run, jls takes ~0.01s, all the zfs calls take ~0.7s, 0.15s in the ctype bits, 0.05s in git, and the rest is in python, so roughly 2 seconds is spent in python. For a wrapper to jexec ('-f' not used, so not forcing the jail to start) all of that execution list seems excessive.

I haven't dug into the code too much, in the past I've only looked at some of the networking bits, but I'll take another look when I have time.

[Defenso-QTH]

I think the zfs part has significant room for improvement. There is a cache system in the code that, if I understand correctly, is supposed to speed things up but I am not sure if it really works, but it is not small. We could also maybe reduce overhead by having python call the zfs lib directly instead of spawning zfs(8) processes.

For the git part it's unclear for me too. But the plugin part needs to be reworked to untie it from the company that originally developed the tool.

Edit: the call to git comes from the git module, it is not in the code of iocage.

[Defenso-QTH]

@dgeo can you maybe mark #97, #99 and #100 as prerequisites for closing this issue?

[dgeo]

done, maybe #67 could help here too, but no time here to start this…