Something that bothered me in the 90s and has been bothering me again now is that Amiga OS doesn't have a centralised 'daemon / service management' system. it has a number of unconnected systems that can be used to do some of the things that launchd or initd/systemd+systemctl do.
For example, there is:
- Startup-Sequence and User-Startup, where a number of system processes are launched, like IPrefs
- WBStartup where anything can be launched but generally helper apps with GUIs is what you want in there, especially those that depend on Workbench already being initialised
- commodities.library can be used to make background programs that popup on demand or otherwise perform some automated background action
- Break can be used to send simple messages to running processes
- Run can be used to spawn background processes
- Kickstart processes started by the bootstrap
- application.library which but being new to OS4 is not widely supported and again seems mostly for GUI apps
- Services feature in various TCP stacks which can start a service to handle incoming request on TCP/IP port
A lot can be done with this list but things it can't do include:
- Restarting a task if it ends unexpectedly, fundamental to the concept of a 'daemon'
- Create a common place for stdout/stderr logs for background tasks
- Making sure that only 'one' of a given process runs, where that's desirable, although other mechanisms exist with partial support for that including application library, including unique rexx port naming, only one server can bind to a IP port etc.
- Start an app if it isn't already running on some trigger such as keyboard shortcut for a commodity or access to a rexx port. So for example if you want to have rexx script depending on presence of a particular port, you have to write your own 'if port exists address it or otherwise guess where it's installed and run it first and wait'. If you want to launch an commodity by keyboard shortcut, you better make sure it's in wbstartup - admittedly this is less of an issue now everyone has lots of RAM but it was an issue in the 90s.
- Sending a Break requires a Process number lookup to find the right process
- Heartbeat actions to check a process is responding
- Ensure that dependencies exist before starting, and then auto start once the dependencies are met e.g. that Workbench is running or specific mounted volume exists or that networking is up.
- Auto termination of a task upon certain events such as network offline or disk eject/unmount
- Auto reload of a settings file after it's saved, on a general basis. Individual apps can do this but most don't.
- Centralised command line control of the sort offered by systemctl - instead every app has it's own way of doing things
- Out of the box, write apps that trigger on events like time events or disk mount/unmount, although there are apps that do that specific job including cron commodities
I appreciate lack of crash protection (memory protection, resource tracking) means that if a task dies you're stuck with it. I also appreciate that it's often quicker and easier to just reboot an Amiga than restart a specific service. Still it would be nice to do things 'better' wouldn't it?
What do you guys all think?
I think it could be largely built with only shell and rexx scripts actually, at least to prototype it. As with init.d you would have a shell script for each process you want to 'daemonize' that has entry points for start, stop, restart, status, debug mode etc.
So let's say for the wifi 'C:WirelessManager' command you would define a status command as showing the tail of it's log output, debug mode would set the verbose flag, stop would send a Break C to process called "WirelessManager" etc.