Job Snijders <j...@openbsd.org> wrote: > A use case could be running rpki-client more frequently than once an > hour:
I want to say I think running rpki-client so often is misguided for these rpki-processing-on-the-router configurations. rpki-processing-on-the-router seems like more a technology demonstration than performant practical solution. A rpki-client run is a lot of x509 compute, roughly 5 minutes of full cpu. After cron has this support, I suspect you will propose that root's crontab be changed to use the feature, thus further increasing the compute done directly on a router. It will do 5 minutes of compute, 15 minutes of pause, and do it all again. This will have impact on traffic flow through the OpenBSD software routing stack. Surely the on-router approach is only acceptable in very narrow circumstances, and those situations don't need to be updating RPKI every 20 minutes, as I doubt the internet at large is doing anything close to 20 minute updates. The normal RPKI use pattern should be offline processing (on a different dedicated system), then uploaded to a router. How often RPKI is run should be sensitively scaled to the resources available. Are we actually helping people by proposing they use 5 minutes of total cpu compute, every 20 minutes? I have serious doubts. That then begs the question why cron needs this extension for this purpose. > @15 -n rpki-client && bgpctl reload > > The above is equivalent to: > > * * * * * -sn sleep 900 && rpki-client && bgpctl reload Somewhat the same effect, but I think there are big differences in behaviour. The second version creates a process hierarchy which sleeps for a long time. I suspect crontab -e causes drastic difference in behaviour when the job is already running. I hate the sleep pattern, because you can't see what is happening from a system perspective (ie. in ps), and if root decides to run rpki-client or various bgpctl commands by hand, you can get surprising results. So I agree with getting away from the sleep pattern. I have never used it myself, and we should discourage others from using it by providing something better. > I borrowed the idea from FreeBSD's cron [1]. A difference between the > below changeset and the freebsd implementation is that they specify the > interval in seconds, while the below specifies in minutes. Why be incompatible? Better have a strong justification.
