3 ms·

It would be nice if `RestartSec` weren't constant. Then you could have the default be 100ms for one-time blips, but (after a burst of failures) fall back gradu

by o11c 3y ago

It would be nice if `RestartSec` weren't constant. Then you could have the default be 100ms for one-time blips, but (after a burst of failures) fall back gradually to 10s to avoid spinning during longer outages. That said, beware of failure chains causing the interval to add up. AFAIK there's no way to have the kernel notify you of when a different process starts listening on a port.

dijit 3y ago
> AFAIK there's no way to have the kernel notify you of when a different process starts listening on a port. You can use mandatory access control for this. AppArmour or SELinux are examples. Unfortunately they are hard, not sexy and sysadmins (people who tend to do not sexy hard things) are a dead/dying breed
nomel 3y ago
> AFAIK there's no way to have the kernel notify you of when a different process starts listening on a port. Would the ExecCondition be appropriate here, minimally, with a script that runs `lsof -nP -iTCP:${yourport} -sTCP:LISTEN`?
- o11c 3y ago
  I'm talking: once your process has started, how do you wait for a process you depend on? Obviously if systemd opens the port for you it's easy enough (in this case, even across machines), but otherwise you have to do a sleep loop. And I'm not sure how dependency restarts work in this case. ExecCondition must moves the spin to systemd, and has more overhead than doing in your own process. There's no point in gratuitously restarting after all.
saint_yossarian 3y ago
There's `RestartSteps` and `RestartMaxDelaySec` for that, see the manpage `systemd.service`.
- o11c 3y ago
  Ah, not in the man page on my system. Available since systemd 254, released July 2023 (only 1 release since then). Huh, has release rate severely slowed down?
BobbyTables2 3y ago
> AFAIK there's no way to have the kernel notify you of when a different process starts listening on a port. For startup, I’d argue the proper way is for the process to bind the socket before forking as a daemon. With such a design, one can launch a list of dependent processes without worrying how long they each take to start up. No polling loops needed! Of course, that requires some careful design — “fork and forget” is too appealing. The process would be responsible for creating its PID file after forking but the socket before… Alternatively, an IPC notification could be used but would require some sort of standardization to be generally useful.

by o11c 3y ago

dijit 3y ago

> AFAIK there's no way to have the kernel notify you of when a different process starts listening on a port. You can use mandatory access control for this. AppArmour or SELinux are examples. Unfortunately they are hard, not sexy and sysadmins (people who tend to do not sexy hard things) are a dead/dying breed

nomel 3y ago

> AFAIK there's no way to have the kernel notify you of when a different process starts listening on a port. Would the ExecCondition be appropriate here, minimally, with a script that runs `lsof -nP -iTCP:${yourport} -sTCP:LISTEN`?

o11c 3y ago
I'm talking: once your process has started, how do you wait for a process you depend on? Obviously if systemd opens the port for you it's easy enough (in this case, even across machines), but otherwise you have to do a sleep loop. And I'm not sure how dependency restarts work in this case. ExecCondition must moves the spin to systemd, and has more overhead than doing in your own process. There's no point in gratuitously restarting after all.

saint_yossarian 3y ago

There's `RestartSteps` and `RestartMaxDelaySec` for that, see the manpage `systemd.service`.

o11c 3y ago
Ah, not in the man page on my system. Available since systemd 254, released July 2023 (only 1 release since then). Huh, has release rate severely slowed down?

BobbyTables2 3y ago

> AFAIK there's no way to have the kernel notify you of when a different process starts listening on a port. For startup, I’d argue the proper way is for the process to bind the socket before forking as a daemon. With such a design, one can launch a list of dependent processes without worrying how long they each take to start up. No polling loops needed! Of course, that requires some careful design — “fork and forget” is too appealing. The process would be responsible for creating its PID file after forking but the socket before… Alternatively, an IPC notification could be used but would require some sort of standardization to be generally useful.