rbonghi / jetson_stats

📊 Simple package for monitoring and control your NVIDIA Jetson [Orin, Xavier, Nano, TX] series
https://rnext.it/jetson_stats
GNU Affero General Public License v3.0
2.17k stars 264 forks source link

Distribution independent standard package #557

Open alonbl opened 3 months ago

alonbl commented 3 months ago

Is your feature request related to a problem? Please describe.

Embedded product such as Jetson not always use the Ubuntu distribution variant. The distribution, for example Yocto, do not always use systemd. A well behaved package should assume minimum fact on the environment while providing the functionality. Dynamic installation of components is not possible in most cases of embedded.

Describe the solution you'd like

Be able to run this package on Yocto openrc based distribution.

Describe alternatives you've considered

After code modifications, I ended up with:

[INFO] jtop.service - Initialization service
[INFO] jtop.service - service ready
[INFO] jtop.service - jtop timer thread started 1000ms
[CRITICAL] jtop.core.timer_reader - Exception in 'timer_reader thread': [errno:1] Error process:

[ERROR] jtop.service - Error subprocess [errno:1] Error process:
Traceback (most recent call last):
  File "/tmp/env2/lib/python3.12/site-packages/jtop/service.py", line 328, in run
    control = self.q.get(timeout=timeout)
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.12/multiprocessing/queues.py", line 114, in get
    raise Empty
_queue.Empty
<snip>

Additional context

I understand that the intention of the author is to provide "plug & play" solution, however, when constructing a formalized cross-build of images, the "plug & play" solution does not work. Everything should be pre-customized by using on-disk files and configuration, without modifying the system state at runtime.

Comments I have so far:

It would be nicer to have a separate entry point to the utility and a separate entry point to the service, for example jtop and jtop-service it took me a while to figure out that behavior is modified per JTOP_SERVICE=True environment variable which is not expected... It costs nothing to add a new entry point in python :)

File relative to sys.prefix is not expected, the python is installed using system tools, while this package may be installed in an environment or other locations. The location of the directory used by the package should be configurable. Having defaults is OK, but best to have a configuration file to specify the process configuration such as where are the folders, what is the user name etc...

Assumption of group name == user name is not something that is correct, there should be a separate user name and group name entries in configuration file.

The service should not assume a specific service management platform, it should run until SIGTERM is received. The service management system will execute the service in unprivileged account, service should assume this. Access to peripherals should be done by service user assignment to a groups and assign device permissions using udev.

On top of the well-behaved daemon process we can provide wrapper of systemd, sysvinit and openrc.

I stopped here as I could not make this service work.

Regards,

rbonghi commented 3 months ago

Thank you @alonbl. It's a feature that I want to implement, and your comments are helpful for me to figure out the best way to make jtop available for independent platforms. I'm also working to make jtop available for x86 machines. I think it can be merged into a single release.

Thank you again for your help! I really appreciate

alonbl commented 3 months ago

Hello @rbonghi ,

It is great to hear! Please let me know when you have something ready, I will be able to test.

I suggest to start by splitting the installation, daemon and utilities. Avoid running apt or any other command in the daemon. And and configuration file. I would also suggest to consider dropping the daemon as mandatory component, as the tool may directly access the information.

Regards,