az `at` ugyanúgy perces felbontást tud
Figyelmedbe ajánlom az at parancs dokumentációját, azon belül a -t [[CC]YY]MMDDhhmm[.SS] opciót. Úgy van, a .SS másodpercet jelent. Elhagyása esetén 0 az alapértelmezés.
a batch semmit se segít
Már attól eltekintve, hogy - mint írtam - ha szükséges, párhuzamos helyett szekvenciális job futtatást tesz lehetővé, ezzel pedig esetleg kisimíthatja az általad fenyegetőnek jelzett peak terhelést. Szintén ajánlom elolvasni az atd dokumentációját is, különös tekintettel a -l LOADAVG és a -b SECONDS opciókra amellyel meghatározhatod, hogy mekkora CPU-terhelésérték alatt indítsa a batch a jobokat, és mennyi idővel elcsúsztatva indítsa az "egyszerre" futtatandó jobokat.
alapozzak sleep meg egyéb parancsokra
Rajtad kívül senki nem beszélt sleep-ről. Nem lehet, hogy ez az utalás csak annyit jelent, hogy sosem használtad a cron-t megfelelő módon, csak hiányzott - de nagyon - a másodperces pontosság?
Amit írtál, az meg workaround. Körbetákolás.
Neked körbetákolás, nekem megfelelő működés. Amúgy ha a peak-terhelést úgy kerülöm ki, hogy én időzítem - mondjuk x:00 meg x:15 meg x:38 -ra a jobokat a sytemd-timerrel az nem hákolás, ha pedig belövöm, hogy a rendszer globálisan hagyjon 20 másodpercet az egyes jobok között (az alapértelmezett 1 perc helyett), az körbetákolás. Értem.
De valóban, nyudodtan gondolhatott volna a cron fejlesztője valamikor a 70-es évek közepén arra, hogy majd egyszer eljön a 64-bites time_t ideje, és az is mekkora baromság már, hogy a POSIX szabvány alkotói (OpenGroup vagy mittudomén ma kik ők) még mindig nem szabványosította a másodperc pontos cron-t. De ez is csak azt mutatja, hogy nem én vagyok az egyetlen, aki szerint kevésbé kritikus dolog a sec-pontosságú job-ütemezés.