Amiga.org
Operating System Specific Discussions => Amiga OS => Amiga OS -- Development => Topic started by: NinjaCyborg 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.
-
Don't you know that ThoR passionatly detest systemd? So much that he created System-Startup for OS 3.2 (so that everyone who believes in him may not die in vain, but have eternal life... heh)
As you say, you can largely build what you want using shell and arexx scripts, so you can just go ahead and implement away already.
-
You just can't resist the opportunity to take digs at Thor can you. Go away.
-
Wouldn't it be nice if Amigas just always worked all the time when you turned them on?
Yes. Yes, it would. Far more people would use them on a day to day basis.
The same could be said about any computing device.
-
Sorry, is that meant to be funny?
-
You just can't resist the opportunity to take digs at Thor can you.
The "dig" was at you, really. I just find it funny how you’re essentially asking for systemd for AmigaOS, given his stance on systemd... have you tried emailing him your ideas? He may have an oppinion or ... ten on this matter, and he is the guy who described System-Startup of OS 3.2 as a sort of initd for AmigaOS, so this is absolutely relevant.
-
I don't feel the need to turn AmigaOS into yet another Linux with hundreds of tasks running doing nothing most of the time and restarting at own will while cluttering the drive with log files nobody ever reads.
Leave AOS alone as it is, make small improvements along and all is gooood.
-
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.
-
The "service manager" is the Exchange commodity - just make sure all your software you run has commodity interface, and you can enable and disable at will. By using MUI programs, you already have a head start, as all MUI software inherently also have commodity interfaces. And there is both rexx and CLI interfaces to talk with the commodity interface.
-
If there's one thing AmigaOS definitely doesn't need it's daemons or service managers or whatever you want to call them. The whole point of AmigaOS is its modularity - of course it's the TCP stack's job to start a service if a request comes in via a certain port. And if I need to react to a file changing or a device being mounted, I tell dos.library about it, because that is (or should be) dos.library's effing job.
daemons make sense in a multiuser-environment, where anything running in my session can never directly talk to anything important - because another user's session might be trying to do the exact same thing at the exact same time. But on AmigaOS? It would just introduce another software layer and making stuff more complex because it might make things slightly more comfortable is never a good idea. "Keep it simple, stupid".
-
of course it's the TCP stack's job to start a service if a request comes in via a certain port.
Not at all - that's the task of an inet daemon, not a TCP stack.
And AmigaOS is full of "daemons", like IPrefs, like commodities, like rexxmast...
-
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.
-
No need to be pedantic. Yes it's the job of inetd. Inetd comes with the TCP/IP stack.
Huh, I am not pedantid, and no...
- an inetd doesn't always come with a TCP/IP stack, and when they do, they are very much optional
- they are most often not activated since that is considered a security risk.
- most inet daemons are stand alone and not directly associated with a TCP/IP stack, rinetd, xinetd, systemd socket - even on Amiga you can chose.
It's called a stack, because it consists of multiple bits of interdependent software
No, that is not why it is called a stack, you just made that up now.
and not just because the ISO OSI model is a 'stack'. But you already know that.
TCP/IP has little to do with the OSI model... TCP/IP specifically doesn't follow the OSI model - the TCP/IP stack is different from the OSI stack.
But you already know that.
-
Hi NinjaCyborg!
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.
I wonder if Run, WBRun, and IconX could be rewritten such that, when running a program/script, they create a commodity with the name of that program/script. This commodity would send CTRL+C when selecting "Remove" or CTRL+D (or E?) when selecting "Active/Inactive" to the program/script :)
That way, most (all?) commands would be "visible" in Exchange and controllable...
Any thoughts?
Cheers!
-
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.
-
I tried but couldn't make it work, could you?
Anyways, its readme says that MakeCX works only with a program with a window and a close gadget: it seems to me that MakeCX can just send the IDCMP_CLOSEWINDOW event to a program. Besides, it requires a lot of parameters...
I think that a "RunCX" command would be better: it would send CTRL+F and IDCMP_CLOSEWINDOW to a program (with or without window) and it should pull from the command line/WBStartup the info. about the program name, path, etc. More like WBRun (http://aminet.net/package/util/cli/WBRun) does...
-
erased
-
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.
-
Not at all - that's the task of an inet daemon, not a TCP stack.
On Unix or Windows? Sure. On AmigaOS? Certainly not. A computer running AmigaOS shouldn't answer requests coming in over the network. - it issues requests, but that's it. If you need to FTP or Telnet to your Amiga box over the local network in case of an emergency or when setting up the machine, a minimalistic approach using the TCP stack works just fine.
If you implement a network daemon, you need a detailed user and rights management system next. And that doesn't make much sense without the ability to have several users logged into the box simultaneously. Both of these things require a much more complicated startup process involving an init system, i.e. the dreaded "service manager" NinjaCyborg mentioned. And suddenly, AmigaOS is just like any other OS out there - just that it has the close button on the top left instead of the top right of the window...
-
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.
-
I will let you two “experts” fight this one, who am I, just an “ignorant fuck” with more than 25 years experience in networking, professionally...
(https://forum.hyperion-entertainment.com/viewtopic.php?p=47821#p47821)
-
Hi NinjaCyborg and all!
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.
Good point! But CXRun would have a slightly different purpose and use case: once run using CXRun (maybe from FKey...), these non-commodity programs would appear "as" commodities, with entries in Exchange :) "Show"/"Hide" would just (if possible) move their windows forward/backward and "Remove" would send them a CTRL+F and a "ICDMP_CLOSEWINDOW". (I think that nothing much else can be done? I don't think possible to really "hide" the window of a program not made for it...)
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.
For programs that have no window (and that are not commodities), e.g., AssignWedge, CXRun will again create an entry into Exchange: "Show"/"Hide" would do nothing (or be disabled entirely) and "Remove" would send them a CTRL+F.
So, any program that is not a commodity becomes "visible" as a commodity in Exchange and, as much as possible, controllable from Exchange 8)
In a way, Exchange would become the "command center" of the Amiga, there would be no need to look at the list of processes/tasks anymore, to know what's running. It would also give greater control on these programs that have no windows/are not commodities.
What do you think?
Cheers!
-
@Tygre
I am still wondering why you wish to send Ctrl+F to programs, I don't know of any software that handles that as "quit", do you?
-
@Tygre
I am still wondering why you wish to send Ctrl+F to programs, I don't know of any software that handles that as "quit", do you?
Yes, I meant CTRL+C, good catch and thank you for your contribution!
-
@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.
-
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.
-
When someone repeatedly and consistently writes ctrl+f instead of ctrl+c, it’s safe to assume that it’s a misunderstanding and worth pointing out. Not just for the person in question, but also for other readers.
Btw, I feel sad, I run UDP services on my Amiga and these are not mentioned in this discussion, so sad...
-
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.
PS. What is Ranger? I searched Google but found only the Ranger prototype and Aminet returns nothing?
-
@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.
-
Hi NinjaCyborg!
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
Good taxonomy! :)
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.
Yes, absolutely! A user could also use it for Level 2 but that might clutter needlessly her Exchange ;)
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.
My thoughts too: I haven't yet explore the source code of WBRun but, if possible, I would rather have as little parameters as possible for CXRun: it should itself "remember" the ID of the task/process that it runs, it should not need a window name, etc.
Let's find some time to code now ;D
-
@Tygre:
Ranger is sold via AmiStore these days, IIRC.
Best regards,
Niels
-
Thanks for the info. @nbache and @NinjaCyborg!
I bought a copy of AmigaOS4 (some years ago) but don't have it running currently...
For AmigaOS3, there SysInspector but my favourites are Commander (with Executive (http://aminet.net/package/util/misc/Executive)) and Scout (http://aminet.net/package/util/moni/Scout_os3).
Cheers!
-
I haven't yet explore the source code of WBRun
There are several to chose between, but most common is the one that shipped with OS3.9 - any particular reason you may have the source code for that one?
It was left out of OS 3.1.4 because according to ThoR nobody needs it, and according to Gulliver (and various OS 3.1.4 FAQs that I suppose mostly he wrote), WBRun was replaced by a 3.1.4 spin (same, but different) of ThoR's own WBLoad (not to be confused with LoadWB) from his CLICon project, which doesn't even rely on Workbench to be running to work. Sad story is that WBLoad, unlike WBRun, isn't capable of talking directly with Workbench when it is running, so unlike WBRun, it cannot be used to for example open volumes, drawers etc. So after some... heh... heated debate between everybody's super hero (ThoR) and me, it was concluded that WBRun better be a script that checks if Workbench is up and running, and if so, tells Workbench to do its thing via arexx, and if Workbench is not available, simply use WBLoad. (Don't you remember? You typically pressed "like" on just about anything he posted)
Currently, this rudimentary script looks like this...
; $VER: WBRun 45.9 (24.10.2019) Kolbjørn Barmen <amiga[member=751]kolla[/member].no>
.key PROG/A,ARGS/M,DELAY/N/K,SHOW/K,VIEWBY/K
.bra [
.ket ]
If NOT "[DELAY]" EQ ""
Wait [DELAY]
EndIf
Status com=Workbench >NIL:
If WARN
WBLoad [PROG] [ARGS]
Else
RX "ADDRESS Workbench WINDOW '[PROG]' OPEN"
If NOT "[SHOW]" EQ ""
RX "ADDRESS Workbench MENU WINDOW '[PROG]' WINDOW.SHOW.[SHOW]"
EndIf
If NOT "[VIEWBY]" EQ ""
RX "ADDRESS Workbench MENU WINDOW '[PROG]' WINDOW.VIEWBY.[VIEWBY]"
EndIF
EndIf