Welcome, Guest. Please login or register.
Amiga Kit Amiga Store Iridium Banner AMIStore App Store A1200/A600 4xIDE Interface

AuthorTopic: Daemon management on Amiga OS  (Read 3156 times)

0 Members and 1 Guest are viewing this topic.

Offline Tygre

Re: Daemon management on Amiga OS
« Reply #15 on: February 20, 2021, 04:04:42 PM »
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 does...

Offline trekiej

Re: Daemon management on Amiga OS
« Reply #16 on: February 20, 2021, 05:28:19 PM »
erased
« Last Edit: February 20, 2021, 05:31:13 PM by trekiej »
Amiga 2000 Forever :)
Welcome to the Planar System.
 

Offline NinjaCyborg

Re: Daemon management on Amiga OS
« Reply #17 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 cgutjahr

Re: Daemon management on Amiga OS
« Reply #18 on: February 22, 2021, 01:55:31 PM »
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...
 

Offline NinjaCyborg

Re: Daemon management on Amiga OS
« Reply #19 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 kolla

Re: Daemon management on Amiga OS
« Reply #20 on: February 23, 2021, 01:35:06 AM »
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)
« Last Edit: February 23, 2021, 11:08:11 AM by kolla »
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
---
A3000/060CSPPC+CVPPC/128MB + 256MB BigRAM/Deneb USB
A4000/CS060/Mediator4000Di/Voodoo5/128MB
A1200/Blz1260/IndyAGA/192MB
A1200/Blz1260/64MB
A1200/Blz1230III/32MB
A1200/ACA1221
A600/V600v2/Subway USB
A600/Apollo630/32MB
A600/A6095
CD32/SX32/32MB/Plipbox
CD32/TF328
A500/V500v2
A500/MTec520
CDTV
MiSTer, MiST, FleaFPGAs and original Minimig
Peg1, SAM440 and Mac minis with MorphOS
 

Offline Tygre

Re: Daemon management on Amiga OS
« Reply #21 on: February 23, 2021, 09:53:10 PM »
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!
« Last Edit: February 23, 2021, 09:54:57 PM by Tygre »
 

Offline kolla

Re: Daemon management on Amiga OS
« Reply #22 on: February 24, 2021, 08:30:14 AM »
@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?
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
---
A3000/060CSPPC+CVPPC/128MB + 256MB BigRAM/Deneb USB
A4000/CS060/Mediator4000Di/Voodoo5/128MB
A1200/Blz1260/IndyAGA/192MB
A1200/Blz1260/64MB
A1200/Blz1230III/32MB
A1200/ACA1221
A600/V600v2/Subway USB
A600/Apollo630/32MB
A600/A6095
CD32/SX32/32MB/Plipbox
CD32/TF328
A500/V500v2
A500/MTec520
CDTV
MiSTer, MiST, FleaFPGAs and original Minimig
Peg1, SAM440 and Mac minis with MorphOS
 

Offline Tygre

Re: Daemon management on Amiga OS
« Reply #23 on: February 25, 2021, 12:04:10 AM »
@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!

Offline NinjaCyborg

Re: Daemon management on Amiga OS
« Reply #24 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 NinjaCyborg

Re: Daemon management on Amiga OS
« Reply #25 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 kolla

Re: Daemon management on Amiga OS
« Reply #26 on: February 25, 2021, 02:29:45 PM »
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...
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
---
A3000/060CSPPC+CVPPC/128MB + 256MB BigRAM/Deneb USB
A4000/CS060/Mediator4000Di/Voodoo5/128MB
A1200/Blz1260/IndyAGA/192MB
A1200/Blz1260/64MB
A1200/Blz1230III/32MB
A1200/ACA1221
A600/V600v2/Subway USB
A600/Apollo630/32MB
A600/A6095
CD32/SX32/32MB/Plipbox
CD32/TF328
A500/V500v2
A500/MTec520
CDTV
MiSTer, MiST, FleaFPGAs and original Minimig
Peg1, SAM440 and Mac minis with MorphOS
 

Offline Tygre

Re: Daemon management on Amiga OS
« Reply #27 on: February 25, 2021, 03:15:05 PM »
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?

Offline NinjaCyborg

Re: Daemon management on Amiga OS
« Reply #28 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.

Offline Tygre

Re: Daemon management on Amiga OS
« Reply #29 on: February 25, 2021, 04:32:33 PM »
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
 
The following users thanked this post: NinjaCyborg