Service management is complicated, mostly because it's android development territory, where I'm quite inept.

My ideal service management story would be having a real init (systemd would be sweet, but maybe something like runit might work), with a lifetime equal to the lifetime of the notification, so that you can acquire wakelock, end all sessions and still keep it running.

Are you sure that killing the app doesn't reap all its processes? That sounds real weird to me, actually, I would expect that it does.

A real init system would be nice but maybe an overkill. But I had not that much contact with setting up init systems and what kind of init systems exist already. A quite mimimal one for a primitive service management with transitive dependencies should be sufficient.

Yes I am sure. Example: Run ssh-agent, you can see the process via htop for example. If you exit the app via the notification and start the app again, you can see ssh-agent process is still running. When instead you use force quit in android settings, the process will be killed.

Maybe the app only kills the login process that it started but because ssh-agent is detached completely and no member of the login process group (which forces the app to kill it explicitly), it remains running.

Aha. Then we are after a process supervisor

(fat fingers) Then we are after a process supervisor (supervisord? daemontools? something else?), spawning it, demonized, from the login script, ensuring that we have one and, maybe, hooking the 'exit' button to stop it.

Might be relevant: http://sandervanderburg.blogspot.com/2020/02/a-declarative-process-manager-agnostic.html

Oh forgot about this thread here..

I think we should consider using a init system, that provides us with functionality like service management, but is still as minimal as it can be. I don't know many init systems out there, so can you recommend any?

Would be a pretty neat feature for our small project :)

Last time I've researched that, a systemd-versed friend told me that systemd is out of question (that the whole nix-on-droid is beyond crazy). For the remaining ones, I recall supervisord was the most promising one, but I don't remember the details now.

Alright, I will have a look into supervisord as a starting point.

@t184256 supervisord works flawlessly for managing multiple processes inside of Docker containers for example, here is an example config in a project:

I think it'd be a great fit for nix-on-droid. My use case is that I want to use nix-on-droid to replicate the work I've done with Docker to run on Android devices by acquiring wakelock and having these processes run under supervisord. It would be fantastic if we could spawn these processes declaratively in the nix configuration on Android by this method.

It's worth noting that Termux can already spawn processes at boot via this addon

I would also love to see services in nix-on-droid. My use case would be to create a cron entry to start a script on a regular basis (it would be even cooler if it were compatible with systemd syntax, in order to re-use all the code made for systemd)

The current approach would use supervisord, see #203, but it is still WIP

Yeah, I saw that, thanks for the link. But I guess this would not start nix-on-droid automatically at startup, right? We should maybe add some options to automatically start nix-on-droid when the phone reboots, as I would not want my cron tasks to stop after a reboot.

That sounds like some android stuff.. If you have more knowledge in this regard, feel free to play around with https://github.com/t184256/nix-on-droid-app. Android knowledge is generally lacking in this project unfortunately.

https://github.com/termux/termux-boot
https://wiki.termux.com/wiki/Termux:Boot