Multithreaded telnet server somewhat working but how to convert it in a Daemon

[xardomain]

Hi,
my never ending battle for this example seems finished as a gui "demo" program that works reasonably well.
Despite some nuances between windows and linux, it mostly worked to my satisfaction. It does compile also on a PI5 but crashes at the first attempt to connect to it(not a priority at the moment).
The log of the main events is on a memo component like this:

[2026-02-02 13:46:43][000][30524] Server started on port 23

[yyy-mm-dd hh:mm:ss] [specific point in the program][ThreadId] message

The prompt returned to a telnet client is similar.

Here you will find the complete project:
https://www.marullo.it/wp-content/uploads/2026/02/Multithreadgui.zip



Now, I have a working example of a windows daemon (not converted/tested yet in linux):
https://www.marullo.it/wp-content/uploads/2026/02/ServiceDaemonExample.zip

 and tried to mix the two, but I am unsble to make it work.

I tried to move pieces of code around, but clearly I am not doing much progress:


https://www.marullo.it/wp-content/uploads/2026/02/MultithreadDaemon.zip
Is there a better approach? Could any good soul tell me how to arrange stuff to make it compile?

My example uses forms, it seems not so easy to get rid of them because threads are in a way or another tied to them. Can I leave forms inside a daemon code, may I but it is not recommended or what?


TIA

Giuseppe Marullo

[LeP]

.............. Can I leave forms inside a daemon code, may I but it is not recommended or what?

If you mean "daemon" code like a service (in Windows OS), you cannot and must not use any LCL components: services in Windows cannot use graphic surfaces like Desktop (and Forms for example) or others.

And you cannot use any LCL calls from threads. I mean that you cannot call any LCL procedures, functions and others (normally) from a thread.
You must use the proper methods of TThread class (like synchronize) or others to guarantee that global resources are used without deadlock.

I'm sorry, but I have no time to look and test your code, may be others can do.

[dbannon]

On Linux ?  Yes, definitely no GUI anywhere !

Then, its easy to make a basic daemon, start it using the nohup command and divert stdout to somewhere suitable. Obviously, nothing expected on stdin. Settings should be read from a config file at startup. Catch Ctrl-C etc to manage a nice safe shutdown.

Next step might be to make the code safe to use as root, a daemon does not have to run as root but I bet you expect to.

And, maybe then you go the whole hog and make it SystemD compliment, do some reading ...

Davo

[MarkMLl]

https://github.com/MarkMLl/telnetsrv

MarkMLl

[xardomain]

First of all, many thanks for your answers.
I used the term daemon while in reality I should I have used "service" more akin to the windows world. AFAIK I remember that old Lazarus (or Delphi?) created services were allowed to interact with the GUI. I know it is not exactly ortodox, but that would do for me. If it is not possible anymore, I would gladly create a separated graphic frontend app.

I started from synapse example I don't even remember where I took from, I rather would prefer a windows solution but ideally I would like to have it working on linux too.
The easiest way to have it converted in a service/daemon will do, I don't care if it is linux or windows.

@Davo
>Next step might be to make the code safe to use as root, a daemon does not have to run as root but I bet you expect to.
Without gui access I guess no.  Pure server/service will just interact with telnet clients, a database (preferably MSSQL but again no probem with mariadb) and a graphic frontend to manage the clients. Since not gui, I should incorporate screen/keyboard recording replay using a different program that runs in foreground and talks to the service/daemon.

@MarkMLI
I understand it is a very accurate example but it is made using a completely different approach (no Synapse) and clearly only for linux.  I didn't undestand yet if it is multithreaded, I mean, I would need a thread coupled with each client running concurrently. Does it provide such feature? I could just try to adapt the client thread with a FSM where all my stuff is done and this could more than a good starting point.

@Lep
Yes, definitely a good guy maybe would be able to fix it in no time

Generally, it is difficult for me to locate good docs up to the point it works reliably. Lot of examples around but when I test in not so very special cases it hangs or throws an exception.

The results so far is the best I was able to achieve, it seems pretty stable even handling clients intentional or not so intentional disconnects, timeouts and so on. I would rather havie it converted to a service/daemon though.

Giuseppe Marullo

[MarkMLl]

@MarkMLI
I understand it is a very accurate example but it is made using a completely different approach (no Synapse) and clearly only for linux.  I didn't undestand yet if it is multithreaded, I mean, I would need a thread coupled with each client running concurrently. Does it provide such feature? I could just try to adapt the client thread with a FSM where all my stuff is done and this could more than a good starting point.

At the moment it is multithreaded in that it uses a background thread to handle data transfer, and works well in the role of debugging output etc. Extending this to handle multiple connections to the same socket is "left as an exercise", I have not explored using inetd etc.

MarkMLl

[Remy Lebeau]

AFAIK I remember that old Lazarus (or Delphi?) created services were allowed to interact with the GUI.

That hasn't been allowed since Windows Vista, which introduced "Session 0 Isolation" to secure services away from users. While it is technically possible to make a background service display a GUI, it's much more work to accomplish, and not really worth the effort nowadays.

If it is not possible anymore, I would gladly create a separated graphic frontend app.

That is exactly what you should do.

[xardomain]

@MarkMLl
>Extending this to handle multiple connections to the same socket is "left as an exercise", I have not explored using
> inetd etc.
Thanks but it seems even more difficult to me, if it is not multithread in the way I need.

@Remy
>>That hasn't been allowed since Windows Vista, which introduced "Session 0 Isolation" to secure services away from users.
>> While it is technically possible to make a background service display a GUI, it's much more work to accomplish, and not >>really worth the effort nowadays.
Ok, that was a long time ago.

>If it is not possible anymore, I would gladly create a separated graphic frontend app.
>>That is exactly what you should do.
Sure, but I don't know where to look to "port" my application to a daemon. The gui elements were added but are not needed, still I can't separate the multithread code from the elements that prevent me to succesfully compile it as a pure service /daemon. If I won't be able to create a daemon, I will go on and code in the app that will provide the gui and the multithread. Not exacly the cleanest solution, but it is the only solution at the moment.

To recap:
This one contains the implementation of the multithreaded server into a normal gui app:
https://www.marullo.it/wp-content/uploads/2026/02/Multithreadgui.zip
I am unable at the moment to convert it in a daemon/service app.
It does compile in windows and linux Ubuntu into a vm. It does compile on a PI5 but it is not stable, GTK complains and debugger fails.

This a working daemon tested in windows:
https://www.marullo.it/wp-content/uploads/2026/02/ServiceDaemonExample.zip

And this is my failed attempt to port the relevant part of code from the multithreadgui.zip into the ServiceDaemonExample.zip
https://www.marullo.it/wp-content/uploads/2026/02/MultithreadDaemon.zip

Any help/pointer to relevant documentation to let me out from this wormhole is really appreciated, thanks.

Giuseppe Marullo