Distribution independent standard package
alonbl opened this issue · 2 comments
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,
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
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,