Reply to topic

Why QDir::exists() do not work in kdeneon docker container?

kleag
KDE Developer
Posts
16
Karma
0
OS
Hi,

I opened the following question on Stack Overflow:
https://stackoverflow.com/questions/527 ... -container

To summarize, the QDir::exists() method does not work in the kdeneon docker image.

With the latest tests (see my last comment), it seems that the problem comes from the kdeneon docker image from Docker hub (the problem does not occur in my KDE Neon host nor in a ubuntu:18.04 docker image).

Any idea of the possible origin of the problem ?

Gaël
User avatar apachelogger
KDE Developer
Posts
471
Karma
5
OS
Since 5.10 Qt is using somewhat new syscalls. One of them is statx and last I checked the syscall was not whitelisted in docker, nor was it whitelistable because the libseccomp used for the upstream docker build was too old and didn't know what statx is. Chances are the problem you see is that. If so, seccomp=unconfined would make it work.


Annoyed with bbcode since 1999.
kleag
KDE Developer
Posts
16
Karma
0
OS
apachelogger wrote:Since 5.10 Qt is using somewhat new syscalls. One of them is statx and last I checked the syscall was not whitelisted in docker, nor was it whitelistable because the libseccomp used for the upstream docker build was too old and didn't know what statx is. Chances are the problem you see is that. If so, seccomp=unconfined would make it work.

You are probably right. Thank you. Passing seccomp=unconfined made it work as suggested.
Can I copy your answer to stackoverflow ?

Gaël
User avatar apachelogger
KDE Developer
Posts
471
Karma
5
OS
Sure


Annoyed with bbcode since 1999.
kleag
KDE Developer
Posts
16
Karma
0
OS
apachelogger wrote:Since 5.10 Qt is using somewhat new syscalls. One of them is statx and last I checked the syscall was not whitelisted in docker, nor was it whitelistable because the libseccomp used for the upstream docker build was too old and didn't know what statx is. Chances are the problem you see is that. If so, seccomp=unconfined would make it work.

@apachelogger, a (maybe) complementary question: when I build and execute the Qt program on a kdeneon docker image on a KDE Neon host, it works as expected (with the problem above), but when I build and execute it on a docker image on a Debian 8 host, it fails with
Code: Select all
liqQt5Core.so.5: cannot open shared object file: No such file or directory
, while the lib obviously exist. Could it be again related to incompatible system calls? Or should I search (and ask) elsewhere?
User avatar apachelogger
KDE Developer
Posts
471
Karma
5
OS
Unlikely, certainly not if you disable seccomp. It's probably best to strace it and see what's going on, maybe the library lookup paths are wrong.


Annoyed with bbcode since 1999.
kleag
KDE Developer
Posts
16
Karma
0
OS
apachelogger wrote:Unlikely, certainly not if you disable seccomp. It's probably best to strace it and see what's going on, maybe the library lookup paths are wrong.

OK. Thanks. I'll see if I find time to trace the problem. But the simplest solution will be to switch to a newer OS on the host which was scheduled anyway.

 
Reply to topic

Bookmarks



Who is online

Registered users: Baidu [Spider], Bing [Bot], Exabot [Bot], Google [Bot], Sogou [Bot]