If you’re designing sophisticated Linux based systems you really should fully understand systemd and what it has to offer.

In some cases you’ll find that systemd can be the core of your architecture and free you from writing a lot of software and reduce overall complexity.

Let systemd do the work, that’s my motto.

Funnily enough, I just tried to do this over the weekend and the results were not ... great.

I hit https://unix.stackexchange.com/q/691436/9452 exactly

> need to process to file added to a directory, then remove them. Files can be large (20KiB to 5 GiB) and arrive slowly (via scp or ftp). How can I monitor a path (possibly with a systemd.path unit) and only react when the new file has finished writing?

And as the question details DirectoryNotEmpty is not adequate because zero byte files still being written will trigger it and there's nothing after.

Indeed all the path unit conditions: PathExists=, PathExistsGlob=, PathChanged=, PathModified=, DirectoryNotEmpty= suffers from this.

One could do the an old fashioned while inotifywait -r -e close_write "/foo/bar/" but now you need to think about the script dying and restarting it which of course leads back to systemd (see https://ma.ttias.be/auto-restart-crashed-service-systemd/ for more) and then one asks: why can't systemd do this alone?

I'm a little confused as to why PathChanged didn't work for you.

From the man page

> PathChanged= may be used to watch a file or directory and activate the configured unit whenever it changes. It is not activated on every write to the watched file but it is activated if the file which was open for writing gets closed. PathModified= is similar, but additionally it is activated also on simple writes to the watched file.

PathChanged seems exactly what you want?

Sorry, my recollection of the sum of all failures was not correct.

PathChanged has a different problem: if you are watching a folder it would seem the name of the file is not passed from inotify(7) to the script launched by systemd. This one is outlined in great detail at https://unix.stackexchange.com/a/600686/9452 linked from https://unix.stackexchange.com/q/600642/9452 essentially saying "just give up".

Yeah reacting to incoming files isn’t well supported, but why would you need to do that?

Actually this is a common pattern in enterprise IT where you need to integrate heterogeneous apps (i.e. at least one of the app is "legacy").

E.g. at my job the main system (the one "selling" stuff to customer and managing inventory of this "stuff") routinely sends production data to the datawarehouse, the accounting system, sends invoices and confirmations to a document management systems for formatting and sending (via email).

And considering both how old it is, and the fact that the data can be large-ish... most of this is sent out as files. This also mean that the various consumers need some sort of trigger to start processing the data.

Yeah reacting to files for integrating systems is definitely done, even if it is a poor idea. I don't think systemd is a good system to do it though because I doubt it could ever handle errors or retries in an appropriate manner for the system.

You must be shitting me.

This answer is so bad it has spawned a meme years ago.

https://programmerhumor.io/stackoverflow-memes/stackoverflow...

Nope not shitting you, and I believe that in this case reacting to files with systemd would be poor design.

What "design"?

Look, listen, StackExchange famously tries to avoid X-Y problems.

If I ask how to use a hammer to drive a screw in, it's right to call me out.

But if I getting a shipment of gizmos regularly and they lack a screw then please do not ask why I am using a screw instead of rivets.

I did not design anything here. I am handed a part of a pipeline which I have zero power over.