Shutdown from C++ application container using D-Bus

Technical Support
, ,
21

No, it is located in the /usr/share/dbus-1/system.d folder.

Does it not check a secondary location? Otherwise it’d be hard to customize that location in the filesystem.

Yes, I can get inside the container but I am unable to find the application files copied over to it by the VSCode extension. I am using the default dockerfile.debug from the apollox extension but I am unable to find a location where the application files are being copied into the container.

This is because for debug the application is dynamically copied to the container at the time of debug. If you’re trying to do this in the debug container, then start the debug process from the container, put a breakpoint somewhere so it will pause. Then on the target device while the debug container is still running get a shell as a root inside this container with docker exec. Your application should be in /home/torizon, you can then manually execute it from there.

Ok I copied your code exactly as you showed it here, compiled in a container, executed it as root and it worked. As I said you’ve been executing as a non-root user which is why it fails. If you execute it as root it works, for debug our extension runs the debugger as the torizon user which is why you get this behavior during debug.

would I have to deal with torizoncore builder to create/set permissions for this folder when it is to be production ready?

Your files are in /home which can’t be customized by TorizonCore Builder for technical reasons, if you move these files/directories to /etc then they could be customized. That said I’m not sure why you need to change the permissions on these. If I bind-mount a folder from the home directory into the container and create a file in it I have no issues, this is as root or even non-root.

Are there any video/animated tutorials for a novice like me

Whatever we have in our documentation is what we have, some articles may have videos, some may not.

Best Regards,
Jeremias

1 Like
22

There is also a folder in /etc/dbus-1/system.d but it does not contain the org.freedesktop.login1.conf file. perhaps it can be added there as an override. The Unix documentation (dbus-daemon) states:

On Unix, the standard system service directories are:

/usr/local/share/dbus-1/system-services: this location is specified by the D-Bus Specification, and is suitable for software installed locally by the system administrator

/usr/share/dbus-1/system-services: this location is specified by the D-Bus Specification, and is suitable for software installed by operating system packages

${datadir}/dbus-1/system-services for the ${datadir} that was specified when dbus was compiled, typically /usr/share: this location is an extension provided by the reference dbus-daemon implementation, and is suitable for software stacks installed alongside dbus-daemon

/lib/dbus-1/system-services: this location is specified by the D-Bus Specification, and was intended for software installed by operating system packages and used during early boot (but it should be considered deprecated, because the reference dbus-daemon is not designed to be available during early boot)

Thank you for confirming this. It means even if it doesnt work in a debug setting, it will work on the production containers?

23

Thank you for confirming this. It means even if it doesnt work in a debug setting, it will work on the production containers?

As per my test it should. Now I just learned that in the extension there is also a setting to configure what user executes processes from the extension on the target (including debug). You can see the option here: https://github.com/toradex/torizon-experimental-torizon-ide-v2-docs/blob/main/WORKSPACE-SETTINGS.md#torizon_run_as

Best Regards,
Jeremias

1 Like
24

Wow! Thank you for pointing this out.

I really appreciate your patience and help!

Best Regards,
Hassan.

25

Glad I was able to assist!

1 Like