lun-4 / tsusu Goto Github PK

There are two protocols in tsusu:

• Text-based protocol between the tsusu client and tsusu daemon.
• Wire protocol between tsusu threads

The client-server protocol should be finished, as we declare the 1.0 feature set for tsusu.

This should not happen.

Basically, tsusu stop <service> should send a SIGINT/SIGTERM to the child process, and if both fail after some set timeout (maybe default 5 seconds, configurable later, via the service files, etc, see #6 ), SIGKILL.

PM2 provides some basic logging capabilities by itself for the services. Maybe we can do the same, since std.ChildProcess can already catch stderr and stdout into pipes. We just need a way to communicate them into logfiles.

It would be self-written because I kinda don't know what I could do there with existing tooling.

For the daemon, it should live more on the stack. In the thread wire protocol, you can allocate unbounded memory, which isn't good, amongst other things like not freeing memory when it should be freed, etc.

As the codebase is very prototypical, this won't be pushed forward compared to getting things work.

Little design problem. Should fix that someday.

this will be a long while, so i'll keep track that this project is on hold because doing anything more requires (currently hacky when i tried to do them) changes to the stdlib that don't quite work.

there's a blocking socket module in the works which might be good enough for tsusu's usecase, until then, no work is done.

This is separate to #6 as this is on the service level.

When a service's child process exits, with any code, we should be able to automatically restart it. Compared to PM2, though, which keeps continously restarting processes at a fixed rate (which can cause havoc if you got a configuration file wrong, for example), I plan to implement exponential backoff.

The state of that restart should be made available to the daemon, I added that via the Restarting service state. A timestamp for when the service actually starts up should be made available on that state.

Keeping note that system clock depedency for that timestamp should be done only as an informative measure. If things happen that require that data in a non-informative way, we could investigate deeper into how the monotonic clock works, and if we could show that information instead.

Got some energy to work on this, here's the plan:

• Add supervisor threads that actually spawn and wait the child processes.
• By waiting, we can detect the exit code of it, etc, and give that status back to the daemon process.
• Notification of the child proccess state and other things is done via a message-passing-esque model. Supervisor threads push message structs to an ArrayList inside the daemon process, a thread consumes from that and applies state changes, instead of the supervisors changing state directly.

TODO:

• How can we communicate directly to the supervisor process? We must be able to send signals to the child process, that means getting access to the PID of the child process, and the supervisor is the only one that knows that PID in its execution. Maybe the supervisor can expose the ChildProcess pointer back via messages
• Knowing the PID is also required to know about the stats of the process via procfs.
• Maybe we can do something in regards to logging via the PID as well? If strace -p can do it, what stops us from doing so via procfs as well?

• Services should be stored, somewhere.
  • Service files would contain information about the service and configuration about it as well
  • Proposed interface: tsusu config <service> get/set <key> <value>
• Recover services from that file if the daemon is starting
  • Also means some systemd auto-integration, like pm2 does.
• We could be able to translate systemd unit files into our own format (would be likely INI as well, tbh), that would go as a single argument to tsusu start

PIDs for the child processes should be available in the daemon state, somehow.
The proper "thing" for this is showing CPU/RAM stats when listing services.

Followup question: what is the overhead of accessing procfs? Can that scale, even?