For example I have a RequestService that is responsible for making requests and LogHandler that is loaded with /home/nao/naoqi/preferences/autoload.ini. The idea of the LogHandler is to handle all logs (with help of the LogManager service) and to make a request with this logs to a remote Server. Furthermore the LogHandler handles the events when the system is started and when the system is shutting down. To handle the shutting down I'm using a logic that is triggered after app.run() method (I used this idea).
The question is: If the LogHandler depends on RequestService, is there any guarantee that the OS will kill first LogHandler and then RequestService or there is risk to kill the RequestService - in this case the LogHandler will fail to send a request to the remote server. In this scenario may be a better idea to implement the LogHandler in such a way as to be independent from the RequestService?
# init of the LogHandler
app = qi.Application(url=ROBOT_URL)
app.start()
session = app.session
request_service = session.service("request_service")
on_os_start(request_service)
...
app.run()
...
on_os_shutdown(request_service)
app.stop()
Can I depend on the request_service in case of system shutting down?
No, there is no "official" service shutdown sequence, so even if your services get shut down in a certain order, there's no guarantee that they will continue doing so in different contexts or system versions.
The best is to reduce the need for dependencies between your services, especially at critical moments like startup and shutdown. So to answer your question ...
In this scenario may be a better idea to implement the LogHandler in such a way as to be independent from the RequestService?
... yes, it's a better idea.
I'm not even sure why you want the requests_service in a different service (or is this just an example?). What I sometimes do is have helper python libraries that provide useful functionality, and import the same library from several different services; that way I have shared functionality without code duplication (you might have other reasons than code duplication for wanting to centralize your request handling though).