Welcome, Guest. Please login or register.

Author Topic: Daemon management on Amiga OS  (Read 11762 times)

Description:

0 Members and 1 Guest are viewing this topic.

Offline NinjaCyborgTopic starter

Daemon management on Amiga OS
« on: February 12, 2021, 12:29:03 PM »
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.
 

Offline NinjaCyborgTopic starter

Re: Daemon management on Amiga OS
« Reply #1 on: February 12, 2021, 08:18:36 PM »
You just can't resist the opportunity to take digs at Thor can you. Go away.
 

Offline NinjaCyborgTopic starter

Re: Daemon management on Amiga OS
« Reply #2 on: February 12, 2021, 09:25:27 PM »
Sorry, is that meant to be funny?
 

Offline NinjaCyborgTopic starter

Re: Daemon management on Amiga OS
« Reply #3 on: February 13, 2021, 02:02:48 PM »
Well that's the point of a services manager, so when they're doing nothing they're really doing nothing, rather than taking up memory unnecessarily. OS3 might not have many standard system processes but look at a vanilla OS4 install how many background tasks are running. That's not a dig at OS4, it's necessary to support USB, compositing etc.
 

Offline NinjaCyborgTopic starter

Re: Daemon management on Amiga OS
« Reply #4 on: February 17, 2021, 02:21:20 PM »
No need to be pedantic. Yes it's the job of inetd. Inetd comes with the TCP/IP stack. It's called a stack, because it consists of multiple bits of interdependent software, and not just because the ISO OSI model is a 'stack'. But you already know that.
 

Offline NinjaCyborgTopic starter

Re: Daemon management on Amiga OS
« Reply #5 on: February 20, 2021, 07:46:48 AM »
There's actually an old command line tool that is like Run but creates a commodity entry for the running command. It's called MakeCX. I need to experiment with it to see how robust it is.
 

Offline NinjaCyborgTopic starter

Re: Daemon management on Amiga OS
« Reply #6 on: February 21, 2021, 03:36:22 PM »
Good point about MakeCX. So what would a 'CXRun' command look like that really works how you're thinking? Here's some ideas.

For GUI apps that aren't commodities, any of FKey, ToolManager or AmiDock (and probably some others) can give you a keyboard shortcut to launch them.
 
But the launching app has no way to keep some state about the app it launched - press the shortcut again and it will try to launch the app again, which may or may not do anything depending on whether the app allows more than instance of itself to run. And unless the app is itself a commodity then you don't have show/hide, pause/resume and exit commands to send to it. Even if it is a commodity, then it will likely have it's own keyboard shortcut, but a different one from the one used to launch it as the launching app doesn't know to yield the shortcut it's using!

So first of all, a smarter solution would let you assign the shortcut, and then it would upon launching the app, yield it's own hold on that shortcut combo, in anticipation of the app it launched reregistering the shortcut for itself. This actually means you can make a nice trick - it can wake up every 5 seconds say, attempt to re-register the same shortcut, and if it fails it knows the app is still running (or has crashed... I know it can't handle that scenario unfortunately), if it succeeds it knows the app has exit, and return to it's original mode.

This solves one issue for me that's always bothered me. I want the shortcuts for certain commodities to always be active, without having to load them all into memory. I have a similar issue which is that I want certain rexx ports to always be available, and the app that hosts them only run when the port is accessed lazy-loading style. Again, the service manager would need to register the port, and then yield it when addressed however in this case it would be destroyed and then reallocated, it couldn't simply be passed to the new host.

However if we're launching an app that isn't a commodity, we might only have options like sending a Ctrl-C signal or a fake Window Close IDCMP message like MakeCX does (and then we need to know process names or window names to know where to send it). Or, it might have a rexx port but then we need some way to tell our 'service manager' what commands to send, to what port, for show/hide,suspend/resume,exit etc. Actually application.library tries to do this and adds 'new document', 'open document' and other message types. But It needs the host app to support it itself (and it's OS4 only).

However, a init.d type scripting framework with shell scripts that contain the commands that need to be sent to control a given system could work. For each piece of software you want to control in this way you'd have a script with sections that say what to do - app1 is a commodity, named 'AppX', app2 has a rexxport call 'APP2HOST.1' and the command to exit is QUIT for example

Anyway these are just thoughts for fun.
 

Offline NinjaCyborgTopic starter

Re: Daemon management on Amiga OS
« Reply #7 on: February 22, 2021, 02:15:00 PM »
I believe the AmiTCP inetd and Roadshow service manager can launch services on demand on incoming requests. But on Linux these days it's much more likely that services launch on boot and bind to the server ports immediately than rely on inetd anyway.

Also, your assertion that using amigas as any kind of internet servers requires amiga itself to support users/groups/permissions/strict security is not exactly true. That's only necessary if you want enterprise grade security, which on Amiga you can't get because no memory protection, no buffer overrun protection and a dozen other reasons. But it can certainly run services, see ZitaFTPd or Samba for example, if you don't mind they probably can be hacked. Linux software only maps public service users and groups to local users and groups because the software is written that way. There's nothing intrinsic about it that means it has to be done that way, many web services will simply use a web server specific .htpasswd file for example.
 

Offline NinjaCyborgTopic starter

Re: Daemon management on Amiga OS
« Reply #8 on: February 25, 2021, 08:28:25 AM »
@Tygre

Some further thoughts: The aim of my thought exercise is not necessarily to implement a 'Task manager' type application with deep visibility of all system 'service' processes after all many of them like filesystems or iprefs simply have a lifetime corresponding to the system session lifetime. There are tools to expose full lists of tasks and processes for developer / nerd purposes like Ranger, sysinspector etc. And without memory protection/ resource tracking there's no chance to kill/restarting these processes if they don't want to be anyway.

I'm sure the usual suspects will in any case rail against the idea of introducing 'proper operating system' levels of complexity to Amiga because they like to argue even with people who agree with them, and I'm as much a fan of the 'lean' nature of Amiga OS as anyone so I don't need to argue that point. I still think there's a case though because one can consider 4 levels of 'awareness about tasks' -
Level 1 - tasks you don't need awareness of at all. iprefs, filesystems, intuition etc.
Level 2 - tasks that are services you mostly don't need much visibility of but occasionally do - rexxmast, usb stacks, timidity, tcp ip stack, and tcp services you run e.g. ftpd
Level 3 - things that make good commodities, where the UI is frequently available but hidden when not needed
Level 4 - things you use actively where the UI is always available and which are under your direct control

A service manager would be useful for level 2. a CXRun type tool to make more things commodities that aren't would be good for level 3. Application library is good for level 4, if they ever finish fulfilling it's potential.

The commodities path is worth exploring, after all it is the existing tool for managing background processes that want to be managed. It's just not used in that way enough by developers. I think the makecx approach of messing around with IDCMP close window is a mistake, as it relies on non unique window names and so on. Better to just send a control C, this usually works e.g. with calculator, and if you spawned the process you will know it's ID. In fact the best approach might be a service that stay resident keeping track of all the things it launches and sends messages to, and a separate shell command to control it. I see an architecture forming now.

P.S. I knew you meant Ctrl C not Ctrl F but I didn't feel the need to correct you like certain others do.
 

Offline NinjaCyborgTopic starter

Re: Daemon management on Amiga OS
« Reply #9 on: February 25, 2021, 10:38:15 AM »
A further thought, inspired by looking again at Ranger's functionality. A subset of what Ranger does, parsing the DOS processes list to find processes spawned by Workbench, and then providing that as a list that can be used to drive a UI for managing your 'user apps'. One could make a docky for example that automatically added an icon for every app spawned by Workbench (and let's say, that's NOT in the wbstartup list) rather than relying on developers to implement it themselves, badly (although I do wish AmiDock worked like the mac dock, where the icon for the unlaunched app, and the icon for managing the open app coexist in the same space). And in many cases Workbench can be used to actually spawn new processes by sending it wbrun commands or using workbench library or rexx, rather than necessitating a separate service manager process.

Anyway when I get some time I am going to prototype some of these ideas.
 

Offline NinjaCyborgTopic starter

Re: Daemon management on Amiga OS
« Reply #10 on: February 25, 2021, 03:43:31 PM »
@Tygre

Ranger is an OS4 app to examine all operating system lists of various kinds and can send raw signals. Similar for OS3 is SysInspector, or some others I forget the name of.