From owner-freebsd-hackers@freebsd.org Tue Oct 24 14:41:38 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 84BEBE4F99C; Tue, 24 Oct 2017 14:41:38 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 093F4307A; Tue, 24 Oct 2017 14:41:38 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-lf0-x230.google.com with SMTP id a16so24281098lfk.0; Tue, 24 Oct 2017 07:41:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=BbNVDhf5LnwKiqD7ODMzM+u2vvAdu2vY9b897WxS6Uk=; b=IQXAT5om+/zRHP+DRogUPy1dPK5juWJBqBamokzJXPpatfuGkfifKgHtO8MHXk/OX1 3bxXyvxBNfKw948qPFkNHk0ty6EtNWtxMNnEdBTwdmnPFl0CawzpqMlFxe4znUhqoD62 mNnWMzOQqbObJrp6IVfJve41BxjocZ5ycJ4NbjTfCzy5zZuunLqvNF3rRJK5CKLMx77v bYoL2e1Y8dOHpMC4vHO/IJge12pr2AoRETq3nQAUHkoQFA8w2ATECKTzk3hWZ4pw2LsJ Hr1UnMWVFYoIh6dLQkfkha9voZtWf92sqJ/LqwkmiYOi5crzT99z0HI8XqO8qHvaOyCw NqDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=BbNVDhf5LnwKiqD7ODMzM+u2vvAdu2vY9b897WxS6Uk=; b=mOiYPRLSCsYHzQySvCx3t3sS+rYK6nz8vOlIcxg/0d6hM3+fN8b4OwYI5giOwuG1TW OLGFXdP2CwlmJHRf6P8TCgEyjD0u+PH7LcDmMaYA1cIQJJ6qjqI7EOVdakZKWOPPfZJI y2dRWAWG9nT4fWFPXj1twfFi0bnTJsRKJ9cWUPxRCISUrYtuNAL568jJK8KdYrnSHlTF /uChKTbKkUzt0BxNizSAmX4wZWxm8mKLCY6mnvI+w4qy78RAMYI+zpxaUc53rzv4fBuC ZPMyOvhg9fyOiKJAAFSKiN64mmkNrPFix+6jnrCih0zHiVEbR9DigPwPvQa1FFUf5gQg 2mIg== X-Gm-Message-State: AMCzsaVuPPrpcOjYI7IrqSmQB9KwF82BjpLoiyqgmNDrfRiTHd0T2dGj jGcvpHSWuVwNrGPUTCRuy6WX1/Kjhvfp2mqNGeY= X-Google-Smtp-Source: ABhQp+T2jw96XXtsJkw6l2VDgdHlRdPwLvIbsmXzKxLImq/z2aI55uni8bQGogqIjM0+Bdf5YWYc9VZTiGx9Bf7PAbo= X-Received: by 10.46.20.11 with SMTP id u11mr7092183ljd.38.1508856095941; Tue, 24 Oct 2017 07:41:35 -0700 (PDT) MIME-Version: 1.0 Sender: asomers@gmail.com Received: by 10.179.93.24 with HTTP; Tue, 24 Oct 2017 07:41:35 -0700 (PDT) In-Reply-To: References: From: Alan Somers Date: Tue, 24 Oct 2017 08:41:35 -0600 X-Google-Sender-Auth: pShcwbTzR9lrwE_EmYzWXwTvQz8 Message-ID: Subject: Re: Periodic jobs lockf timeout To: Borja Marcos Cc: "freebsd-hackers@freebsd.org" , freebsd-security@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 14:41:38 -0000 On Tue, Oct 24, 2017 at 3:07 AM, Borja Marcos wrote: > > Hi, > > I=E2=80=99ve come across a problem with the =E2=80=9Cdaily=E2=80=9D secur= ity 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=E2=80=99s issued by the > periodic checks can take forever. They can take so long, I have found sev= eral lockf=E2=80=99s waiting. > > Is it sane to have an unlimited timeout for lockf? Probably it would be b= etter to have at least a configurable > timeout for each cathegory. It=E2=80=99s really unlikely to see an overla= p for a weekly or monthly job, but for daily > jobs it would be good to have a sane default, say, an hour or two. > > There=E2=80=99s even a parameter on /etc/defaults/periodic.conf but it se= ems it=E2=80=99s not used right now. > > # Max time to sleep to avoid causing congestion on download servers > anticongestion_sleeptime=3D3600 > > > The alternative would be to have defaults for a sane timeout for each cat= hegory, like > > daily_lockf_timeout > weekly_lockf_timeout > monthly_lockf_timeout > > Thoughts? It=E2=80=99s pretty simple to do and overlapping periodic jobs = are really useless. 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 knowing which lockf you're talking about, I can't understand your problem. The anticongestion_sleeptime variable is unrelated to lockf. -Alan