VNC Wayland not receiving -SYS_NICE functionalities (docker)

Technical Support
, ,
1

I am trying to set setschedparam for thread priority and getting:

setschedparam failure (1)
setschedparam failure (22)

etc…

I used to get this error until I added the --SYS_NICE flag into my run command for my docker container, giving it permissions. This was on Torizon 5.7.

Now, on Torizon 6.8, when I use wayland to run my executable, I am getting these setchedparam failures again.

This ONLY OCCURS when I run my executable from the wayland terminal.

When I run the executable from terminal with

docker exec -it container-name bash

Then go to the executable and execute it, I get NO failures and it is able to set the thread prio just fine.

Why is it that wayland backend now in Torizon 6.8 is not able to set thread priority, while I can when I’m directly in the docker container?

.
This is the entrypoint for my container:
/usr/bin/entry.sh --developer --tty=/dev/tty7 (entry.sh is unmodified from toradex container)
.
In both the wayland and the container directly, $ capsh --print provides this output (which shows that the cap_sys_nice flag exists) :

Bounding set =cap_chown,cap_dac_override,cap_dac_read_search,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_linux_immutable,cap_net_bind_service,cap_net_broadcast,cap_net_admin,cap_net_raw,cap_ipc_lock,cap_ipc_owner,cap_sys_module,cap_sys_rawio,cap_sys_chroot,cap_sys_ptrace,cap_sys_pacct,cap_sys_admin,cap_sys_boot,cap_sys_nice,cap_sys_resource,cap_sys_time,cap_sys_tty_config,cap_mknod,cap_lease,cap_audit_write,cap_audit_control,cap_setfcap,cap_mac_override,cap_mac_admin,cap_syslog,cap_wake_alarm,cap_block_suspend,cap_audit_read

.
.

Relevant system info:

torizon@INAV99111:~$ sudo tdx-info
Password:

Software summary
------------------------------------------------------------
Bootloader:               U-Boot
Kernel version:           5.15.148-rt74-6.8.0-devel+git.284966e8d6ee #1-TorizonCore SMP PREEMPT_RT Tue Aug 9 12:56:10 UTC 2022
Kernel command line:      root=LABEL=otaroot rootfstype=ext4 quiet logo.nologo vt.global_cursor_default=0 plymouth.ignore-serial-consoles splash fbcon=map:3 ostree=/ostree/boot.1/torizon/82e8b66a4282ea53d2fa6604f7eb1e17b368a15db0f22928c18c474453c697f9/0
Distro name:              NAME="TorizonCore with PREEMPT_RT"
Distro version:           VERSION_ID=6.8.0-devel-202408-build.25
Distro variant:           VARIANT="Docker"
Hostname:                 INAV99111
------------------------------------------------------------

Hardware info
------------------------------------------------------------
HW model:                 Toradex Verdin iMX8M Plus on Verdin Development Board
Toradex version:          0063 V1.1B
Serial number:            15336335
Processor arch:           aarch64
------------------------------------------------------------
2

Hi, I’m the Toradex AI Assistant. The Toradex Support team will follow up with you shortly!

Did you like my answer?

:+1: :-1:

The issue you’re experiencing with setting thread priority using setschedparam in Torizon 6.8 when running your executable from the Wayland terminal, but not when running directly in the Docker container, could be related to how capabilities and permissions are managed in the Wayland environment compared to a direct container shell.

Here are a few points to consider:

  1. Wayland Environment: When running applications in a Wayland session, the environment might impose additional restrictions or lack certain capabilities that are otherwise available when running directly in the container shell. This could be due to how the Wayland compositor or the Weston container is configured.

  2. Capabilities: Although your capsh --print output shows that cap_sys_nice is available, the Wayland session might not be utilizing the same capability set as the direct container shell. Ensure that the Wayland session is started with the necessary capabilities.

  3. Entrypoint Script: The entrypoint script /usr/bin/entry.sh might be setting up the environment in a way that affects capability usage. Check if there are any differences in how the environment is set up when running through Wayland versus directly in the container.

  4. Docker Run Options: Double-check the Docker run options used to start the Weston container. Ensure that the --cap-add=SYS_NICE or equivalent options are correctly applied when the container is started, especially if the Wayland session is initiated as part of the container startup.

  5. Wayland and Weston Configuration: Review the configuration files for Wayland and Weston to see if there are any settings that might affect process capabilities or permissions.

If these suggestions do not resolve the issue, it might be necessary to further investigate the differences in environment setup between the Wayland session and the direct container shell. Additionally, consulting Toradex support or community forums might provide more specific insights related to Torizon 6.8 and Wayland.

Please, also check if these links can help you solve your problem:

Verdin iMX8MP: not HDMI on custom image.

3

I would like to add some more findings:

in the wayland terminal, it does not default to bash, so everytime I open a terminal, i have to type

bash

to invoke bash.

Next, I think this may be caused due to user, permissions etc. running whoami from the docker container directly shows root but running whoami from the wayland front end terminal shows Torizon.

What was done by a developer many moons ago was this entrypoint command:

/usr/bin/entry.sh --developer weston-launch --tty=/dev/tty7 --user=root

But it seems this has been deprecated. What is the correct way to invoke bash by default, and to have the user be root in wayland terminal?

4

I would like to add some more findings:

in the wayland terminal, it does not default to bash, so everytime I open a terminal, i have to type

bash

to invoke bash.

Next, I sys_nice not getting passed to the wayland was caused due to user, permissions etc. running whoami from the docker container directly shows root but running whoami from the wayland front end terminal shows Torizon.

What was done by a developer many moons ago was this entrypoint command:

/usr/bin/entry.sh --developer weston-launch --tty=/dev/tty7 --user=root

But it seems this has been deprecated in torizoncore 6+.

I new solution I found that works is to (from a separate entrypoint script before entry.sh)

export SHELL=/bin/bash

WAYLAND_USER=root /usr/bin/entry.sh --developer --tty=/dev/tty7
5

Hey @kyle_wuz_here,
the issue here is that the default shell for the Torizon user is /bin/sh

root@9a87142fafd2:/# getent passwd torizon
torizon:x:1000:1000::/home/torizon:/bin/sh

Could you share some feedback about your use case for bash? Just convenience of having a nicer shell or is there another reason?

We could think of setting it as the default shell, as scripts wouldn’t be affected because of the shebang.

Also, could you share the use case for running the Wayland container with --SYS_NICE instead of running the application container with the flag?

Thanks!

6

We do not run two separate containers, we have one container that starts up, and starts the torizon entry.sh script to start wayland.

Then we VNC into the wayland terminal and start our executable from there.

We want to use bash because we have some bashrc stuff preset up like autocomplete.
Thus, the wayland backend needs root access to access the SYS_nice thread capabilites of the host container that wayland is running in.

Manually exporting before running the wayland entry:
export SHELL=/bin/bash

is a solution that works for us, so if other users use sh then I don’t see an issue.

1 Like