On Tue, 2017-10-24 at 17:06 +0200, Borja Marcos wrote:
>
> >
> > On 24 Oct 2017, at 16:41, Alan Somers wrote:
> >
> > On Tue, Oct 24, 2017 at 3:07 AM, Borja Marcos wrote:
> > Are you talking about the lockf in /usr/sbin/periodic? It already has
> > a timeout of 0, which should prevent overlap
On Tue, Oct 24, 2017 at 3:07 AM, Borja Marcos wrote:
>
> Hi,
>
> I’ve come across a problem with the “daily” security job. On an overloaded
> system with lots of ZFS datasets,
> lots of files, heavy system load and, to add insult to injury, a ZFS crub
> going on the find’s issued by the
> period
> On 24 Oct 2017, at 17:25, Ian Lepore wrote:
>
> No, lockf -t 0 means to exit without waiting, with status EX_TEMPFAIL,
> if the lock cannot be acquired immediately. In light of that, the rest
> of your report/request doesn't make sense. Jobs won't stack up,
> they'll fail if the prior one i
> On 24 Oct 2017, at 16:41, Alan Somers wrote:
>
> On Tue, Oct 24, 2017 at 3:07 AM, Borja Marcos wrote:
> Are you talking about the lockf in /usr/sbin/periodic? It already has
> a timeout of 0, which should prevent overlapping periodic jobs. Or is
> there some other lockf involved? Without
Garrett Wollman wrote:
> Since packages are already distributed with signatures over the entire
> package manifest, it would be nice if you could use the package system
> to feed this.
Yes, that's what we do in Junos.
The Junos package system relies on veriexec to verify packages and their
conte
Hi,
I’ve come across a problem with the “daily” security job. On an overloaded
system with lots of ZFS datasets,
lots of files, heavy system load and, to add insult to injury, a ZFS crub going
on the find’s issued by the
periodic checks can take forever. They can take so long, I have found seve
