Running kraftkit without `sudo` runs much slower

[gabrielmocanu]

Describe the bug

After running the hello-world application I tried to use kraft ps command. Running kraft ps takes much longer(2 seconds) than sudo kraft ps.

Steps to reproduce

git clone --depth=1 https://github.com/unikraft/app-helloworld.git;
cd app-helloworld;
kraft build --plat qemu --arch x86_64;
kraft run

kraft ps

Also, I think this is the same with all kraft commands. Running as sudo it much faster.

Expected behavior

Both kraft ps and sudo kraft ps commands should run at the same fast.

Which architectures were you using or does this bug affect?

x86_64

Which operating system were you using or does this bug affect?

linux/debian

Relevant log output

No response

[antoineco]

@gabrielmocanu I noticed a similar behavior recently. Is kraft version also slow?

[gabrielmocanu]

@gabrielmocanu I noticed a similar behavior recently. Is kraft version also slow?

Nope. For kraft version I don't see this problem.

[craciunoiuc]

I can't reproduce this :cry:

@nderjung has no chance to reproduce because his computer does not support more than one user

@antoineco can you investigate this when you have time?

[razvand]

@antoineco , @gabrielmocanu , @nderjung , @craciunoiuc , I can also reproduce it on my side:

This basically hangs:

kraft run

This gives out an error:

$ sudo kraft run
select target: helloworld (qemu-x86_64)
could not start and wait for QEMU process: exit status 1

[craciunoiuc]

@antoineco , @gabrielmocanu , @nderjung , @craciunoiuc , I can also reproduce it on my side:

This basically hangs:

kraft run

This gives out an error:

$ sudo kraft run
select target: helloworld (qemu-x86_64)
could not start and wait for QEMU process: exit status 1

In your first case, it hangs, yes, we need to fix this

In the second case, I think I also saw this behaviour on @StefanJum 's laptop. It's because of a very old qemu version. He had 4 (I remember you have 2).

When he tried the container which has 7, it worked fine.

[StefanJum]

In the second case, I think I also saw this behaviour on @StefanJum 's laptop. It's because of a very old qemu version. He had 4 (I remember you have 2).

When he tried the container which has 7, it worked fine.

@craciunoiuc note that this did not happen only for qemu 4, it also happens for qemu latest version,8.0.2, which I also tried.

[craciunoiuc]

qemu 8.0.2 deprecates an argument we currently use everywhere, that I know it doesn't work 😅

[nderjung]

We have now added better error reporting to the QEMU invocation which will tell you what the underlying error is. Worth re-trying to get a better handle on the issue at hand.

[antoineco]

On the current staging, kraft ps without sudo still takes >10s to return, and returns without any information instead of failing:

The output with sudo, just as a reference:

[nderjung]

Have you incorporated the latest file/group permission changes from #630 ? (i.e. updating /var/kraftkit to use group kraftkit)

[craciunoiuc]

Or change the runtime directory 🪄

[antoineco]

I built kraft from staging and ran it.

If the user needs to fiddle with permissions manually on their machine the issue isn't "fixed".

[nderjung]

Agree. KraftKit should be re-chown-ing the runtimedir if it is UID=0 and the group differs from one set in the settings.

[antoineco]

Also, my current system doesn't have a kraftkit group, so even if kraftkit was attempting something like that, it would fail. Where does this requirement come from?

[nderjung]

This becomes more complicated. Understandably, KraftKit should resolve this issue by itself such that users spend zero to minimal amounts of time troubleshooting, especially between versions. I think adding a group to the host would be best covered under a more general kraft setup command that could be used to properly install / update the host based on its environment and requirements such as these. (And re-run after upgrades).

For now, the kraftkit group is handled by the installation script. This should be migrated to a kraft setup command that is first subcommand that is called after its installation and can be used also during upgrades.

[antoineco]

What about the requirement for this group, where does it come from? If the user needs to run commands that access resources on the filesystem which they don't have permissions on, running those commands requires sudo anyway, regardless of whether the group is kraftkit or root.

[nderjung]

Not if a common group is added that a user is part of and the group owns these resources. This is the idea behind chowning the runtime directory /var/kraftkit. Then multiple users can read and write to this common path.

By far the easiest solution here is to change --runtime-dir config value to somewhere owned by the user such that they do not have to use sudo.

[antoineco]

Absolutely. IMO this should be the default (e.g. HOME directory), and multi-user should be an opt-in mode that people need to set up.

[nderjung]

In fact we have a mechanism for looking up the state directory (it's just never used) This should be set when the config is first created:

https://github.com/unikraft/kraftkit/blob/e212961dbe4e91c793f650a14d3a1d3f1596d4c5/config/config_file.go#L72-L93

[craciunoiuc]

These look good, but I think the actual fix for this is to find out in which command it blocks, and make it exit early with an error. I think I can look into this

[craciunoiuc]

I think we can safely close this

If anyone still has this issue they can just reset their ~/.config/kraftkit/config.yaml file, or just change the runtime_dir path inside it