From nobody Wed Aug 3 15:19:15 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4LybB45pNQz4XvXw for ; Wed, 3 Aug 2022 15:19:24 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4LybB36q5Mz3qBc for ; Wed, 3 Aug 2022 15:19:23 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id 273FJG9J030333; Wed, 3 Aug 2022 08:19:16 -0700 (PDT) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id 273FJG3t030332; Wed, 3 Aug 2022 08:19:16 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <202208031519.273FJG3t030332@gndrsh.dnsmgr.net> Subject: Re: cron @shutdown In-Reply-To: <20220803085433.Horde.aghywmAauLjH7fJCEFFzNvn@webmail.leidinger.net> To: Alexander Leidinger Date: Wed, 3 Aug 2022 08:19:15 -0700 (PDT) CC: freebsd-arch@FreeBSD.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 4LybB36q5Mz3qBc X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of freebsd-rwg@gndrsh.dnsmgr.net has no SPF policy when checking 69.59.192.140) smtp.mailfrom=freebsd-rwg@gndrsh.dnsmgr.net X-Spamd-Result: default: False [-2.10 / 15.00]; AUTH_NA(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-0.999]; NEURAL_HAM_SHORT(-1.00)[-0.999]; MIME_GOOD(-0.10)[text/plain]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:13868, ipnet:69.59.192.0/19, country:US]; MLMMJ_DEST(0.00)[freebsd-arch@FreeBSD.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; TO_DN_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DMARC_NA(0.00)[dnsmgr.net]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N > Quoting Cy Schubert (from Tue, 02 Aug 2022 > 07:54:33 -0700): > > > Hi, > > > > Does anyone think there might be some utility with an @shutdown crontab(5) > > "nickname" similar to @reboot but instead when cron shuts down? > > > > I pointed out to one of my customers that @reboot might be an option > > instead of an rc script (or in his case a systemd unit file). Not that an > > @reboot for FreeBSD cron would contribute to solving his Linux problem but > > might our users be interested in something like this? > > I'm a little bit puzzled... > "@stop" (when cron is stopped) is easy to implement, but the use cases > for this are ... IMO very limited (and I would question if another way > of implementing the application logic where this is used may be better). > "@shutdown" is not only a simple change to cron but also needs some > logic to distinguish a stop/restart of crond from a full system > shutdown. As such from a layering logic I would rather go with a rc > script instead of a cron entry. > > I understand that real-world ... "rules" ... can lead to situations > where @shutdown would make life more easy. How far do we want to go > there? Where do we draw a line between layering violations and stupid > policies or convenience or "I don't want to talk with a colleague" > situations (or whatever it is)? > > This message is not a "no-vote", it is a "take a step back, take a > deep breath, and ask yourself if we really want to do that". > > Bye, > Alexander. This message is a no-vote, based on the layering violation, but even without that I fully support this notion of asking "do we really want to do this", and "what are all the new bugs that come along". Shall @shutdown only be allow for "root" cron tables? What happens if 50 users add @shutdown entries, or one user adds a very long one, that leads me to say, yep, this has to be a "root" only entry. Well if it is root only, does this really belong in cron at all? Anyway.. I think @shutdown, @reboot, are a Bad Ideas. -- Rod Grimes rgrimes@freebsd.org