Kris on Nostr: nprofile1q…2f40h Writing a daemon in traditional Unix is absolutely broken. You ...

nprofile1qy2hwumn8ghj7un9d3shjtnddaehgu3wwp6kyqpqmh888n5tn05wwhjls6wd897jx0m9j6fdy0ynfx8s724su5420kxsj2f40h (nprofile…f40h) Writing a daemon in traditional Unix is absolutely broken.

You need to do a dozen things that are special to daemons, and you need to implement a debug option where you do not do these things.

Double forking, disowning a terminal, log to syslog instead of stderr, rotating a logfile and/or handling SIGTERM to close and open a logfile (both syslog and logfile, or an option to choose), resource limits, locking and pid-file handling, the list goes on.

Systemd extracts these things into common code and handles it – properly written systemd code can be started in one of multiple ways the daemon does not need to know anything about. It does not need to fork, it does not need to create a port or know the port number, it logs to stderr, it does not need to know about pid-files, and so on. It is just a piece of code that runs on connect, permanently, containerized with resource limits or whatever – the code does not need to know about it at all.

And that is good. Much better than before.

Systemd does a lot of other things that init should have done, but never bothered to do. Not just daemon-handling and containerizing daemons, but also actually building the system on startup – integrating the various components, including pluggable components, whenever there is an event. For this it handles and integrates with other components that do the actual work. For this, it has to have knowledge about these things.

Systemd also gives us finally a schema for logfiles, which makes logfiles indexable and searchable. It also gives us integrity for logfiles, by treating them as the appendable Merkle tree they should have been since the concept of such trees existed.

All of that is part of the automation of sysadmin work.

https://blog.koehntopp.info/2015/03/27/go-away-or-i-will-replace-you.html

Most computers never have an operator that logs on. If they have to, that's a bug. File a report.

Ah, and regarding

the output of 'ls -l' on a large directory

We do have https://github.com/kellyjonbrazil/jc

CLI tool and python library that converts the output of popular command-line tools and file-types to JSON or Dictionaries. This allows piping of output to tools like jq and simplifying automation scripts.

but despite understanding the output of hundreds of existing Unix commands and converting them to JSON, jc does not understand the output of ls. Nobody does.

That is why Linux coreutils grew stat. ls is just too broken to parse.