Alapvetoen nem ajanlom, es ilyen feladatra jellemzoen szukseg sincs ilyenre.
Onnan indultunk, hogy "Ha megis erre lenne szukseg, ...", szóval másodperces ütemezésre van szükség, miért nem ajánlod? Én azt látom, hogy nem használod, mert csak, nem tudod mit tud, nem is akarod megérteni a működését, és ezért objektív indokod nincs arra, hogy miért nem ajánlod, viszont ajánlasz helyette egy kókányhalmot, ami töredékét tudja, mint a másodperces ütemezésre lehetőséget adó systemd.
Egyszer kellett mikrokontrolleren a szokasosnal pontosabb idozites, akkor azt csinaltam
Egyrészt nem uC környezetről beszélünk.
Másrészt a másodperces ütemezés azért jó, mert ha van több darab perces ütemezésű job, akkor nem az van, hogy mindegyik elindul egész perc nulla másodperckor és szarráterhelik a szervert, aztán meg ötvenvalahány másodpercig semmi nem fut, hanem lehetőség van egzakt vagy randomizált perces ütemezésre és nem fognak egymással konkurálni a perces job-ok. Nem mindig az a lényeg, hogy egzakt másodpercben fusson le, hanem az, hogy ne burst terhelést okozzanak, amikor futnak és ezt perces ütemezéssel nem tudod jól megoldani.
Cron esetén kurva nehéz ilyen ismétlődést ütemezni, pedig nagyon jó találmány, de ha nincs másodperces ütemezésre lehetőség, akkor nem tudod jól megcsinálni. És például cron esetén kurva nehéz mutally exclusive job-ot létrehozni, systemd esetén ez kurva könnyű, hogy a két ütemezett job egyszerre nem fut.