Re: Periodic jobs lockf timeout

2017-10-24 Thread Ian Lepore
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

Re: Periodic jobs lockf timeout

2017-10-24 Thread Alan Somers
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

Re: Periodic jobs lockf timeout

2017-10-24 Thread Borja Marcos
> 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

Re: Periodic jobs lockf timeout

2017-10-24 Thread Borja Marcos
> 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 >

Periodic jobs lockf timeout

2017-10-24 Thread Borja Marcos
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