On Wed, Sep 22, 2021 at 01:31:11PM +0000, Michael Matz wrote:
Hello,
On Wed, 22 Sep 2021, Adam Majer wrote:
On Tue, Sep 21, 2021 at 11:01:46AM +0200, Manfred Schwarb wrote:
Am 21.09.21 um 10:47 schrieb Manfred Schwarb:
But the question remains: what about performance? If I have a small program that is called in a loop, is performance severely hampered?
Your bottleneck will be an additional exec() call.
Nope. It execve's a specific binary and to find out which it needs to open, read and parse all the associated config files on each execution.
That might still not pose a significant problem, but that needs to be measured instead of just be hoped upon. (Generally I do like the libalternatives approach, but maybe not for /bin/sh, as you say).
Yes, I believe that it's a little heavy for /bin/sh because it happens on *every* execution. This adds up if you put it on 1m servers and run them for a year. And there is no appreciable benefit for doing this (at least I can't imagine one). But in general, the overhead seems to be the exec call. I just did a small benchmark that just execs /bin/true either directly or via /bin/alts and it's as expected. https://gist.github.com/AdamMajer/89e1402d26024f5ebddb25d19d2f0890 The main benefit for libalternatives over update-alternatives is that each user can override the default. Another is that the selection is not fragile -- you can snapshots of / and restore /etc and /home from a different time and things will not fall apart like with update-alternatives. The negative is mostly that extra exec() overhead (and if you ever find it's significantly more in some scenario, it's a bug :). Another issue is it's not immediately clear *what* you are running since execution depends no the argv[0] and config file and not target binary of a symlink. This is an issue with things like AppArmor. - Adam