tried to run container in privileged mode. Added privileged: ‘True’ to extraparms. It appeared in docker compose file. After that program lost access to serial ports . It provides an exception: " An unhandled exception of type ‘System.UnauthorizedAccessException’ occurred in System.IO.Ports.dll: ‘Access to the port ‘/dev/colibri-uartb’ is denied.’". When set privileged to “False” everything works. what is wrong?
Thanks.
Greetings @Serghey,
Are you passing /dev/colibri-uartb via the --device flag into the container?
If I recall the --privileged flag and the --device flag have a weird interaction. Check inside your container to see if /dev/colibri-uartb even exists when you have the --privileged flag enabled.
If it doesn’t exist you may need to pass it into the container as a volume rather than a device.
Best Regards,
Jeremias
Great, it works when pass serial ports as a volumes.
The final purpose was read/write real time clock via i2c (i2c-17 address 0x68) to setup date/clock directly from the user space when there is no access to internet. Could you provide the best way how to do that?
Thank you in advance.
The final purpose was read/write real time clock via i2c (i2c-17 address 0x68) to setup date/clock directly from the user space when there is no access to internet. Could you provide the best way how to do that?
If I understand, you want to read/write the RTC from inside a container? Is this something that you will be doing dynamically or do you just need to set the RTC one time?
Setting time/RTC inside a container is not the most trivial task which is why I’m asking.
Best Regards,
Jeremias
RTC will be set one time during the production. Customer should have the option to choose the time zone. Product may use as stand alone without internet access. In that case, if by some reason RTC battery fail, we need to provide the possibility to setup date and time without network connection.
Thank you.
Will hwclock commands not solve this for you? Are you trying to modify the hardware or system clock or both?
Beware the systemd-timedated/timedatectl commands since they are outdated.
We can read/write RTC inside container using hwclock, from the console.
But when trying implement hwclock as a process in dotnet app it does not work. The process exit code is always 1. Also when read RTC (hwclock -v) we can observe communication pulses on RTC pins (SDA and SCL). When write new date/time inside RTC no pulses are observed, but data successfully saved somewhere and hwclock -v provides these new date/time. Something weird…
We can read/write RTC inside container using hwclock, from the console.
But when trying implement hwclock as a process in dotnet app it does not work.
Ok so you are already reading/writing the RTC from inside a container. But it fails when trying to do so from your dotnet app? It sounds like an issue with the dotnet app then, yes? I’m not much of an expert with dotnet unfortunately.
So is the issue then that you can’t execute hwclock using your dotnet app? Or is there another goal here?
Best Regards,
Jeremias
Hwclock was just one option we tried and it was not successful.
You didn’t quite answer my question. So you claimed that you can use hwclock to read/write the RTC from inside a container by invoking hwclock via the console. However, this fails when you try to invoke hwclock from your dotnet app.
This means hwclock works then, just there’s an issue with invoking it from your app right?
Doesn’t this mean it’s an dotnet application issue then?
Best Regards,
Jeremias
Yes, we think this is dotnet issue. Probably hwclock uses some folders which should be bound/mount to be accessible from the container.
Some update:
This is how hwclock --verbose is executed from docker container:
root@8827bc7c6104:/# hwclock --verbose
hwclock from util-linux 2.36.1
System Time: 1651244420.219210
Trying to open: /dev/rtc0
Using the rtc interface to the clock.
Assuming hardware clock is kept in UTC time.
Waiting for clock tick…
…got clock tick
Time read from Hardware Clock: 2022/04/29 15:00:22
Hw clock time : 2022/04/29 15:00:22 = 1651244422 seconds since 1969
Time since last adjustment is 1651244422 seconds
Calculated Hardware Clock drift is 0.000000 seconds
2022-04-29 15:00:21.660463+00:00
root@8827bc7c6104:/#
But when I try to invoke it from dotnet app it provides the error message:
hwclock: cannot open /dev/rtc0: Permission denied
hwclock: Cannot access the Hardware Clock via any known method.
Container is running in privileged mode and it does not matter , if volume /dev/rtc0 bound/mounted or not.
Just for reference this is how process is invoked from dotnet:
using (var hwclock = new Process())
{
hwclock.StartInfo.FileName = “hwclock”;
hwclock.StartInfo.Arguments = “-- verbose”;
hwclock.StartInfo.UseShellExecute = false;
hwclock.StartInfo.RedirectStandardOutput = true;
hwclock.StartInfo.RedirectStandardError = true;
hwclock.Start();
StreamReader myStreamReader = hwclock.StandardError;
Console.WriteLine(myStreamReader.ReadToEnd());
hwclock.WaitForExit();
}
I’m not an expert in dotnet code. But it seems like a permission issue. I notice when you run hwclock from the console inside the container you’re running it as root. Maybe your application is not running with high enough privileges to use hwclock?
What happens if you run hwclock from a simple shell script? Is it just the dotnet app that has the issue?
Best Regards,
Jeremias
hwclock could be definitely executed from dotnet. When I change its argument hwclock.StartInfo.Arguments =" --version" it provides the right output response hwclock from util-linux 2.35.1 the same as if run it from the console. So application has the permission to invoke it. Look like the problem is that hwclock trying to access /dev/rtc0 which is not permitted. Probably this is because this device is already opened by operation system? But why it works from container console?
Well I did a few tests on my side. I created a little program/script that invokes hwclock. If the root user executes this, then it works. If not then I get permission issues.
Unless dotnet is special in how it handles user permissions, the only likely scenario I see is that the root user is not the one executing the application that invokes hwclock. Otherwise as long as the container is privileged and the root user is executing then it seems to work.
Best Regards,
Jeremias
I was able to read/write RTC directly using i2cget/i2cset, but still have an issue to synchronize system clock with RTC. From console system time could be synchronized with RTC using command hwclock --hctosys. Still have the same problem when try to run this command from C#. It trying access to /dev/rtc0 and gives the same error message that access is not permitted. Container is running in privileged mode. Is it any other way to synchronize system clock to RTC or change system clock to some known value from container?
I’m still not understanding how your dotnet app is failing to call hwclock due to permissions. In my test I made a simple python app that calls hwclock, and there were no issues as long as the root user inside the container is executing.
I’m not experienced with dotnet/C# at all. Could you please provide a minimal code for a dotnet application that calls hwclock. As well as any other instructions needed to setup the application. I want to give this a try for myself, I can’t imagine dotnet is doing something very differently here when it calls hwclock
Is it any other way to synchronize system clock to RTC or change system clock to some known value from container?
The date command can be used to set the system time but this doesn’t affect the RTC. I’m not aware of any other utilities that can be used with interact with RTC, since hwclock is the most commonly used.
Best Regards,
Jeremias
Please refer to hwclock.rar. Here application changes RTC year to 2023 by directly write to i2C. But the second part hwclock -s does not work from the application, but it is fine when execute it from the container console. I use Iris carrier board with colibri imx8qxp (rev D).
Thank you.
There seems to be something wrong with the application you provided me. I’ve been trying to run it and it doesn’t seem to work as expected. After some observation it seems like hwclock never finishes executing. I added a print statement after TimeSync(); and it never gets reached. The application seems to hang for some reason.
Also observing the memory usage it seems like this application uses more and more memory on the module till it eventually fails due to no memory left. I’ve seen it use more than 1G of memory.
Could you please advise on what’s going on with this code otherwise I won’t be able to reproduce this.
Best Regards,
Jeremias
Hello,
Thank you for spending time.
The console project, I sent , is not exactly what we use in our product. Here hwclock by some reason hangs the program. This is the separate issue. I did the new simple app with uno platform on which our current device based. Please refer to TestHwclock
I moved both processes from console app without any changes and invoke the other process hwclock --verbose. The results attached below. Here we can observe the same behavior as in our product:
application cannot invoke properly hwclock -s , but it works fine when run it from container console.
Something wrong with /dev/rtc0 access.
This is aplication console output:
hwclock: Cannot access the Hardware Clock via any known method.
hwclock: Use the --verbose option to see the details of our search for an access method.
hwclock: cannot open /dev/rtc0: Permission denied
hwclock: Cannot access the Hardware Clock via any known method.
hwclock from util-linux 2.36.1
System Time: 1651765607.723926
Trying to open: /dev/rtc0
No usable clock interface found.
And this is what happens when run hwclock --verbose from docker container console:
root@df0392dd2420:/# hwclock --verbose
hwclock from util-linux 2.36.1
System Time: 1651766863.934271
Trying to open: /dev/rtc0
Using the rtc interface to the clock.
Assuming hardware clock is kept in UTC time.
Waiting for clock tick…
…got clock tick
Time read from Hardware Clock: 2023/05/05 16:07:46
Hw clock time : 2023/05/05 16:07:46 = 1683302866 seconds since 1969
Time since last adjustment is 1683302866 seconds
Calculated Hardware Clock drift is 0.000000 seconds
2023-05-05 16:07:45.412234+00:00
root@df0392dd2420:/#