Re: cron(8) improvement
On Wed, Nov 06, 2013 at 10:57:12AM +0200, Volodymyr Kostyrko wrote: Shouldn't we encourage packages to use periodic(8) when possible? Yes but our default periodic configuration in /etc/crontab is only configured to be as granular as daily. If this is something that should run hourly or at very strange intervals then cron is a better choice. So why we shouldn't add something like: 0 * * * * root periodic hourly @reboot root periodic reboot I already do this on some machines to take hourly and boot snapshots with zfSnap. And I think periodic is much better place for such tasks. While this is the way it has always been done, I'd find it somewhat lacking in the flexibility department, also you might be in for some nasty surprises First, the resolution is limited to hourly, and second, if I'm not mistaken, the jobs are run strictly sequentially. The last point be suboptimal, as the interval may vary wildly. Also, what happens when all jobs' runtime adds up to more than one hour? It's an equivalent of /etc/cron.hourly.d, but going this way we still don't have something like /etc/crond.d. Best regards Thomas ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: cron(8) improvement
Adrian Chadd wrote, On 11/10/2013 01:18: I'm kinda fed up installing packages that don't enable themselves. There should be no package that needs activation, that is if you want a desktop computer, not a server. 'pkg install xorg' is not enough to get a working xorg. You have to enable hal and dbus and then restart (so things come up in the right order; manually starting them doesn't work) in order to get X working. I use: hald_enable=NO dbus_enable=NO Please install the cron scripts by default. Please then write up a simple rc.conf style setup where the cron scripts can check a config file to see if they should run. Provided that there will be - an option for every instance of a port wanting to install a cron.d script -- ie., port options plus a settable NO_CROND_SCRIPTS -- and - a fail-safe mechanism to disable all cron.d entries, ie. crond_enable=NO, I feel that installed scripts could be an option. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: cron(8) improvement
Am 10.11.2013 18:23, schrieb Warren Block: On Sun, 10 Nov 2013, Philipp Ost wrote: Warren Block schrieb: [...] Given the above scenario, would it be acceptable to set the entry in rc.conf, $portname_cron=YES, to $portname_cron=NO without touching the modified files and inform the user about having done so? I would not want the system modifying rc.conf for me, but don't have a better idea at present. Maybe move customized cronfiles to an old folder on deinstall, so at least the user could recover them. I like the idea that entries are ignored unless they end in .cron. This does not only allow to install inactive cron scheduled in a file ending in .cron.sample, it also lets you rename modified cron tabs to e.g. .cron.off (a convention often used by me). If the port is re-installed, it is up the administrator to decide whether a schedule based on a freshly installed .cron.sample or the old .cron.off should be enabled. This would require the deinstall target / tool to rename any cron entry of the port / package by appending .off, but that's a minor change, IMHO. This might lead to some clutter in .../cron.d/, but I do not think that stale files should be automatically removed (even if they were older than some threshold). Regards, STefan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: cron(8) improvement
On 11/09/13 21:23, Allan Jude wrote: On 2013-11-09 21:13, Adrian Chadd wrote: On 9 November 2013 17:58, Allan Jude free...@allanjude.com wrote: Well, if the rc.conf config is specific to the daemon being installed by the package, then the existing /etc/rc.conf.d/ system works fine, it just falls down a little on xorg configuring hald, unless you just make the xorg package create /etc/rc.conf.d/hald and /etc/rc.conf.d/dbus If I install hal/dbus, why wouldn't they themselves populate /etc/rc.conf.d/hald and /etc/rc.conf.d/dbus ? If there are hal/dbus options that need configuring by other packages, then sure, you'll need to add some other things too. ahh, right, why didn't I think of that I like the simplicity of rc.conf, and I would much rather not involve an sqlite database, I am not sure how that could possibly be faster then sourcing an extra shell script. Don't focus on that. The sqlite example is just that - an example - showing what kind of operations you would want to implement to _allow_ you to do that. I'm not advocating for doing it in freebsd-base. The point I'm making is this: * when populating rc.conf.d/, don't just do 'cp' in a post-install script * when populating the cron daemon entries in rc.cron.d, don't just 'cp' in a post-install script. -adrian If the cron daemon is just scanning /etc/cron.d/* and treating it as if those lines had been appended to /etc/crontab I don't see why you couldn't just cp in the post-install. I think it would be better if you didn't have to 'register' a change. For this whole thread, please s,/etc/rc.d,/usr/local/etc/rc.d,g -- George ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: cron(8) improvement
On 2013-11-10 09:04, George Mitchell wrote: On 11/09/13 21:23, Allan Jude wrote: On 2013-11-09 21:13, Adrian Chadd wrote: On 9 November 2013 17:58, Allan Jude free...@allanjude.com wrote: Well, if the rc.conf config is specific to the daemon being installed by the package, then the existing /etc/rc.conf.d/ system works fine, it just falls down a little on xorg configuring hald, unless you just make the xorg package create /etc/rc.conf.d/hald and /etc/rc.conf.d/dbus If I install hal/dbus, why wouldn't they themselves populate /etc/rc.conf.d/hald and /etc/rc.conf.d/dbus ? If there are hal/dbus options that need configuring by other packages, then sure, you'll need to add some other things too. ahh, right, why didn't I think of that I like the simplicity of rc.conf, and I would much rather not involve an sqlite database, I am not sure how that could possibly be faster then sourcing an extra shell script. Don't focus on that. The sqlite example is just that - an example - showing what kind of operations you would want to implement to _allow_ you to do that. I'm not advocating for doing it in freebsd-base. The point I'm making is this: * when populating rc.conf.d/, don't just do 'cp' in a post-install script * when populating the cron daemon entries in rc.cron.d, don't just 'cp' in a post-install script. -adrian If the cron daemon is just scanning /etc/cron.d/* and treating it as if those lines had been appended to /etc/crontab I don't see why you couldn't just cp in the post-install. I think it would be better if you didn't have to 'register' a change. For this whole thread, please s,/etc/rc.d,/usr/local/etc/rc.d,g -- George ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org We have never once mentioned /etc/rc.d rc.conf.d is an entirely different system (extending rc.conf) and I proposed both /etc/cron.d/ (stuff you'd normally add to /etc/crontab) and /usr/local/etc/cron.d/ (packages) -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: cron(8) improvement
On Sun, 10 Nov 2013, Daniel O'Connor wrote: On 10 Nov 2013, at 24:24, Matthew Seaman matt...@freebsd.org wrote: 2) Should ports / packages populate these cron.d directories? This is a much more interesting question. Effectively its asking if a port / package should provide some level of automatic configuration -- a thing that has previously been a no-no for FreeBSD. I think it would be OK if they installed entries in a disabled state. That would be my preference also. ie either the file is named such that it is ignored by cron (preferable IMO) or the entries in them are commented out. Why not just use an additional entry in rc.conf? rsnapshot_cron=YES (If there is a /usr/local/etc/cron.d/rsnapshot, add it to cron on start/restart.) This brings up another problem. When a port is removed, what is done with ports cron entries that have been user modified? Normally, modified files would not be removed, but a cron entry for a removed port definitely should not be running any more, even if the admin forgot to remove the entry in rc.conf. But just removing the modified file is bad also, because maybe the port was just removed as part of an upgrade. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: cron(8) improvement
On 2013-11-10 11:21, Warren Block wrote: On Sun, 10 Nov 2013, Daniel O'Connor wrote: On 10 Nov 2013, at 24:24, Matthew Seaman matt...@freebsd.org wrote: 2) Should ports / packages populate these cron.d directories? This is a much more interesting question. Effectively its asking if a port / package should provide some level of automatic configuration -- a thing that has previously been a no-no for FreeBSD. I think it would be OK if they installed entries in a disabled state. That would be my preference also. ie either the file is named such that it is ignored by cron (preferable IMO) or the entries in them are commented out. Why not just use an additional entry in rc.conf? rsnapshot_cron=YES (If there is a /usr/local/etc/cron.d/rsnapshot, add it to cron on start/restart.) I envisioned crond just scanning the directory for added/removed files, rather than some 'add it to cron' system, and cron doesn't read/parse the rc.conf system. maybe it makes most sense to make it scan /usr/local/etc/cron.d/*.cron So ports can install rsnapshot.cron.sample that the user must manually enable (like we do with config files) This brings up another problem. When a port is removed, what is done with ports cron entries that have been user modified? Normally, modified files would not be removed, but a cron entry for a removed port definitely should not be running any more, even if the admin forgot to remove the entry in rc.conf. But just removing the modified file is bad also, because maybe the port was just removed as part of an upgrade. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: cron(8) improvement
Warren Block schrieb: [...] ie either the file is named such that it is ignored by cron (preferable IMO) or the entries in them are commented out. Why not just use an additional entry in rc.conf? rsnapshot_cron=YES (If there is a /usr/local/etc/cron.d/rsnapshot, add it to cron on start/restart.) This brings up another problem. When a port is removed, what is done with ports cron entries that have been user modified? Normally, modified files would not be removed, but a cron entry for a removed port definitely should not be running any more, even if the admin forgot to remove the entry in rc.conf. But just removing the modified file is bad also, because maybe the port was just removed as part of an upgrade. Given the above scenario, would it be acceptable to set the entry in rc.conf, $portname_cron=YES, to $portname_cron=NO without touching the modified files and inform the user about having done so? Philipp ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: cron(8) improvement
On Sun, 10 Nov 2013, Philipp Ost wrote: Warren Block schrieb: [...] ie either the file is named such that it is ignored by cron (preferable IMO) or the entries in them are commented out. Why not just use an additional entry in rc.conf? rsnapshot_cron=YES (If there is a /usr/local/etc/cron.d/rsnapshot, add it to cron on start/restart.) This brings up another problem. When a port is removed, what is done with ports cron entries that have been user modified? Normally, modified files would not be removed, but a cron entry for a removed port definitely should not be running any more, even if the admin forgot to remove the entry in rc.conf. But just removing the modified file is bad also, because maybe the port was just removed as part of an upgrade. Given the above scenario, would it be acceptable to set the entry in rc.conf, $portname_cron=YES, to $portname_cron=NO without touching the modified files and inform the user about having done so? I would not want the system modifying rc.conf for me, but don't have a better idea at present. Maybe move customized cronfiles to an old folder on deinstall, so at least the user could recover them. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: cron(8) improvement
On Sun, Nov 10, 2013 at 10:13 AM, Adrian Chadd adr...@freebsd.org wrote: The point I'm making is this: * when populating rc.conf.d/, don't just do 'cp' in a post-install script * when populating the cron daemon entries in rc.cron.d, don't just 'cp' in a post-install script. sounds like we need a ports/pkg config system for admins *after* they have been installed, if bsdconfig interface for en-/disabling services is too simple to do what users want. For cron.d I believe only a few will object it. It is only question who should put files in it. Taking dbus/hald for example, that probably belongs to xorg meta-ports to do the necessary works to enable it, if dbus users prefer to enable it manually. And that will involve painful package dependencies. Imagine more complex cases like letting user choose cron tasks to enable. ports/pkg being a wrapper around 3rd party packages, inevitably it will need to decide some default settings in advance for user. For compile time it is probably ok, or user can choose to compile it with different options. Do we need to agree on some common user interface to do the run-time user-adjustable settings for applications? That's probably also subject to what a pkg install should do by definition. -Jia-Shiun. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: cron(8) improvement
On 08/11/2013 04:51, Allan Jude wrote: My use case is puppet etc, not ports/packages, so I'll leave the policy about packages up to portsmgr@, I just want a less sloppy way to manage crontabs with my orchestration system (and feature parity with Linux) There's two questions here: 1) Should cron(8) support use of /etc/cron.d and/or /usr/local/etc/cron.d ? Clearly yes it should. Seems a no-brainer to me. 2) Should ports / packages populate these cron.d directories? This is a much more interesting question. Effectively its asking if a port / package should provide some level of automatic configuration -- a thing that has previously been a no-no for FreeBSD. However, I personally would not be completely against this *given* the switch to use of sub-packages. I think having a foo-config sub-package as an optional extra would provide the best of both worlds. People who want the same sort of behaviour as you get with most Linux distributions can install the pre-canned configuration bits; those who prefer the FreeBSD traditional approach can simply not install them. Done right this should also facilitate people writing their own customized configuration sub-ports. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey JID: matt...@infracaninophile.co.uk -- Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey signature.asc Description: OpenPGP digital signature
Re: cron(8) improvement
On 10 Nov 2013, at 24:24, Matthew Seaman matt...@freebsd.org wrote: 2) Should ports / packages populate these cron.d directories? This is a much more interesting question. Effectively its asking if a port / package should provide some level of automatic configuration -- a thing that has previously been a no-no for FreeBSD. I think it would be OK if they installed entries in a disabled state. ie either the file is named such that it is ignored by cron (preferable IMO) or the entries in them are commented out. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C smime.p7s Description: S/MIME cryptographic signature
Re: cron(8) improvement
On 9 November 2013 16:05, Daniel O'Connor docon...@gsoft.com.au wrote: On 10 Nov 2013, at 24:24, Matthew Seaman matt...@freebsd.org wrote: 2) Should ports / packages populate these cron.d directories? This is a much more interesting question. Effectively its asking if a port / package should provide some level of automatic configuration -- a thing that has previously been a no-no for FreeBSD. I think it would be OK if they installed entries in a disabled state. ie either the file is named such that it is ignored by cron (preferable IMO) or the entries in them are commented out. I want the opposite. I'm kinda fed up installing packages that don't enable themselves. 'pkg install xorg' is not enough to get a working xorg. You have to enable hal and dbus and then restart (so things come up in the right order; manually starting them doesn't work) in order to get X working. If people are really worried about this, then I suggest a couple of package options for this stuff: * whether to default enable the package or not; * whether to default enable the cron scripts or not. Please install the cron scripts by default. Please then write up a simple rc.conf style setup where the cron scripts can check a config file to see if they should run. I don't want to have to freaking delete, rename, etc cron.d files. I just want the package files to be almost-untouched and have an option of working out of the box. Please, please allow an option to make this crap work out of the box already. -adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: cron(8) improvement
On 10 Nov 2013, at 10:48, Adrian Chadd adr...@freebsd.org wrote: ie either the file is named such that it is ignored by cron (preferable IMO) or the entries in them are commented out. I want the opposite. I'm kinda fed up installing packages that don't enable themselves. 'pkg install xorg' is not enough to get a working xorg. You have to enable hal and dbus and then restart (so things come up in the right order; manually starting them doesn't work) in order to get X working. I agree that is a pain in the arse, however it IS existing policy. I don't think changing it here is right - if the policy is to change it should be changed everywhere. If people are really worried about this, then I suggest a couple of package options for this stuff: * whether to default enable the package or not; * whether to default enable the cron scripts or not. Please install the cron scripts by default. Please then write up a simple rc.conf style setup where the cron scripts can check a config file to see if they should run. I don't want to have to freaking delete, rename, etc cron.d files. I just want the package files to be almost-untouched and have an option of working out of the box. Please, please allow an option to make this crap work out of the box already. A rc.conf script sounds good to me. That still won't get you want you want though because the port/pkg install wouldn't touch it? (would it?) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C smime.p7s Description: S/MIME cryptographic signature
Re: cron(8) improvement
On 2013-11-09 19:18, Adrian Chadd wrote: On 9 November 2013 16:05, Daniel O'Connor docon...@gsoft.com.au wrote: On 10 Nov 2013, at 24:24, Matthew Seaman matt...@freebsd.org wrote: 2) Should ports / packages populate these cron.d directories? This is a much more interesting question. Effectively its asking if a port / package should provide some level of automatic configuration -- a thing that has previously been a no-no for FreeBSD. I think it would be OK if they installed entries in a disabled state. ie either the file is named such that it is ignored by cron (preferable IMO) or the entries in them are commented out. I want the opposite. I'm kinda fed up installing packages that don't enable themselves. 'pkg install xorg' is not enough to get a working xorg. You have to enable hal and dbus and then restart (so things come up in the right order; manually starting them doesn't work) in order to get X working. If people are really worried about this, then I suggest a couple of package options for this stuff: * whether to default enable the package or not; * whether to default enable the cron scripts or not. Please install the cron scripts by default. Please then write up a simple rc.conf style setup where the cron scripts can check a config file to see if they should run. I don't want to have to freaking delete, rename, etc cron.d files. I just want the package files to be almost-untouched and have an option of working out of the box. Please, please allow an option to make this crap work out of the box already. -adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org Well, what about making these extra directories optional then? packages install the crontab entries, but crond ignores them unless you add: cron_flags=--scandir /etc/cron.d --scandir /usr/local/etc/cron.d or something to that effect As for packages enabling things, this seems like a good use of the /etc/rc.conf.d/ infrastructure, although it has a kind of odd structure, where the individual files are only included if the name of the service being started patches. So for example, /etc/rc.conf.d/sshd wouldn't be read when starting crond -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: cron(8) improvement
On 9 November 2013 16:28, Allan Jude free...@allanjude.com wrote: Well, what about making these extra directories optional then? packages install the crontab entries, but crond ignores them unless you add: cron_flags=--scandir /etc/cron.d --scandir /usr/local/etc/cron.d or something to that effect As for packages enabling things, this seems like a good use of the /etc/rc.conf.d/ infrastructure, although it has a kind of odd structure, where the individual files are only included if the name of the service being started patches. So for example, /etc/rc.conf.d/sshd wouldn't be read when starting crond Right. I'd rather it read in everything, but I realise that scales poorly. The other alternative is to have a config file populated with the contents of /etc/rc.conf.d/*, so to modify it you'd edit the individual config file(s), then do a commit operation to push it into the cache. If the cache file doesn't exist, it simply goes through and reads * if someone wanted to speed up the rcvar set, they could just replace it with a read from an sqlite table or an individual config file (as said above); the rcvar thing is -supposed- to just be attribute=value, so it can be stored anywhere. Note to previous poster: i think the existing policy sucks. :-) -adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: cron(8) improvement
On 2013-11-09 20:05, Adrian Chadd wrote: On 9 November 2013 16:28, Allan Jude free...@allanjude.com wrote: Well, what about making these extra directories optional then? packages install the crontab entries, but crond ignores them unless you add: cron_flags=--scandir /etc/cron.d --scandir /usr/local/etc/cron.d or something to that effect As for packages enabling things, this seems like a good use of the /etc/rc.conf.d/ infrastructure, although it has a kind of odd structure, where the individual files are only included if the name of the service being started patches. So for example, /etc/rc.conf.d/sshd wouldn't be read when starting crond Right. I'd rather it read in everything, but I realise that scales poorly. The other alternative is to have a config file populated with the contents of /etc/rc.conf.d/*, so to modify it you'd edit the individual config file(s), then do a commit operation to push it into the cache. If the cache file doesn't exist, it simply goes through and reads * if someone wanted to speed up the rcvar set, they could just replace it with a read from an sqlite table or an individual config file (as said above); the rcvar thing is -supposed- to just be attribute=value, so it can be stored anywhere. Note to previous poster: i think the existing policy sucks. :-) -adrian I suppose you could easily do something like: cat /etc/rc.conf.d/* /etc/rc.conf.cat and add rc.conf.cat to rc_conf_files -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: cron(8) improvement
On 9 November 2013 17:40, Allan Jude free...@allanjude.com wrote: On 2013-11-09 20:05, Adrian Chadd wrote: On 9 November 2013 16:28, Allan Jude free...@allanjude.com wrote: Well, what about making these extra directories optional then? packages install the crontab entries, but crond ignores them unless you add: cron_flags=--scandir /etc/cron.d --scandir /usr/local/etc/cron.d or something to that effect As for packages enabling things, this seems like a good use of the /etc/rc.conf.d/ infrastructure, although it has a kind of odd structure, where the individual files are only included if the name of the service being started patches. So for example, /etc/rc.conf.d/sshd wouldn't be read when starting crond Right. I'd rather it read in everything, but I realise that scales poorly. The other alternative is to have a config file populated with the contents of /etc/rc.conf.d/*, so to modify it you'd edit the individual config file(s), then do a commit operation to push it into the cache. If the cache file doesn't exist, it simply goes through and reads * if someone wanted to speed up the rcvar set, they could just replace it with a read from an sqlite table or an individual config file (as said above); the rcvar thing is -supposed- to just be attribute=value, so it can be stored anywhere. Note to previous poster: i think the existing policy sucks. :-) -adrian I suppose you could easily do something like: cat /etc/rc.conf.d/* /etc/rc.conf.cat and add rc.conf.cat to rc_conf_files Right. But what this scheme specifically needs is some semantics for thing I do to push new config changes into the rc.conf system and thing I do to force a commit of these changes. For the rc.conf.cat version, it would do the above. It may just wrap it in a lock file. For the sqlite hack version, it would grab a lock and dump everything into an sqlite table. The point is that it shouldn't be adhoc. there should be some tools in base for things to add/remove cron configs, add/remove rc.conf configs, and do a rebuild of them. -adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: cron(8) improvement
On 2013-11-09 20:55, Adrian Chadd wrote: On 9 November 2013 17:40, Allan Jude free...@allanjude.com wrote: On 2013-11-09 20:05, Adrian Chadd wrote: On 9 November 2013 16:28, Allan Jude free...@allanjude.com wrote: Well, what about making these extra directories optional then? packages install the crontab entries, but crond ignores them unless you add: cron_flags=--scandir /etc/cron.d --scandir /usr/local/etc/cron.d or something to that effect As for packages enabling things, this seems like a good use of the /etc/rc.conf.d/ infrastructure, although it has a kind of odd structure, where the individual files are only included if the name of the service being started patches. So for example, /etc/rc.conf.d/sshd wouldn't be read when starting crond Right. I'd rather it read in everything, but I realise that scales poorly. The other alternative is to have a config file populated with the contents of /etc/rc.conf.d/*, so to modify it you'd edit the individual config file(s), then do a commit operation to push it into the cache. If the cache file doesn't exist, it simply goes through and reads * if someone wanted to speed up the rcvar set, they could just replace it with a read from an sqlite table or an individual config file (as said above); the rcvar thing is -supposed- to just be attribute=value, so it can be stored anywhere. Note to previous poster: i think the existing policy sucks. :-) -adrian I suppose you could easily do something like: cat /etc/rc.conf.d/* /etc/rc.conf.cat and add rc.conf.cat to rc_conf_files Right. But what this scheme specifically needs is some semantics for thing I do to push new config changes into the rc.conf system and thing I do to force a commit of these changes. For the rc.conf.cat version, it would do the above. It may just wrap it in a lock file. For the sqlite hack version, it would grab a lock and dump everything into an sqlite table. The point is that it shouldn't be adhoc. there should be some tools in base for things to add/remove cron configs, add/remove rc.conf configs, and do a rebuild of them. -adrian Well, if the rc.conf config is specific to the daemon being installed by the package, then the existing /etc/rc.conf.d/ system works fine, it just falls down a little on xorg configuring hald, unless you just make the xorg package create /etc/rc.conf.d/hald and /etc/rc.conf.d/dbus I like the simplicity of rc.conf, and I would much rather not involve an sqlite database, I am not sure how that could possibly be faster then sourcing an extra shell script. -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: cron(8) improvement
On 9 November 2013 17:58, Allan Jude free...@allanjude.com wrote: Well, if the rc.conf config is specific to the daemon being installed by the package, then the existing /etc/rc.conf.d/ system works fine, it just falls down a little on xorg configuring hald, unless you just make the xorg package create /etc/rc.conf.d/hald and /etc/rc.conf.d/dbus If I install hal/dbus, why wouldn't they themselves populate /etc/rc.conf.d/hald and /etc/rc.conf.d/dbus ? If there are hal/dbus options that need configuring by other packages, then sure, you'll need to add some other things too. I like the simplicity of rc.conf, and I would much rather not involve an sqlite database, I am not sure how that could possibly be faster then sourcing an extra shell script. Don't focus on that. The sqlite example is just that - an example - showing what kind of operations you would want to implement to _allow_ you to do that. I'm not advocating for doing it in freebsd-base. The point I'm making is this: * when populating rc.conf.d/, don't just do 'cp' in a post-install script * when populating the cron daemon entries in rc.cron.d, don't just 'cp' in a post-install script. -adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: cron(8) improvement
On 2013-11-09 21:13, Adrian Chadd wrote: On 9 November 2013 17:58, Allan Jude free...@allanjude.com wrote: Well, if the rc.conf config is specific to the daemon being installed by the package, then the existing /etc/rc.conf.d/ system works fine, it just falls down a little on xorg configuring hald, unless you just make the xorg package create /etc/rc.conf.d/hald and /etc/rc.conf.d/dbus If I install hal/dbus, why wouldn't they themselves populate /etc/rc.conf.d/hald and /etc/rc.conf.d/dbus ? If there are hal/dbus options that need configuring by other packages, then sure, you'll need to add some other things too. ahh, right, why didn't I think of that I like the simplicity of rc.conf, and I would much rather not involve an sqlite database, I am not sure how that could possibly be faster then sourcing an extra shell script. Don't focus on that. The sqlite example is just that - an example - showing what kind of operations you would want to implement to _allow_ you to do that. I'm not advocating for doing it in freebsd-base. The point I'm making is this: * when populating rc.conf.d/, don't just do 'cp' in a post-install script * when populating the cron daemon entries in rc.cron.d, don't just 'cp' in a post-install script. -adrian If the cron daemon is just scanning /etc/cron.d/* and treating it as if those lines had been appended to /etc/crontab I don't see why you couldn't just cp in the post-install. I think it would be better if you didn't have to 'register' a change. -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: cron(8) improvement
Den 07/11/2013 kl. 13.11 skrev Kimmo Paasiala kpaas...@gmail.com: Snippets installed by ports should be disabled by default and enabled only selectively by variables in rc.conf(5) or some other configuration file to mirror what periodic(8) is doing now. This is an absolute must because having them enabled by default is a recipe for disaster. rc.conf is usually only for boot-time config and starting daemons. E.g. portaudit just installs a periodic script, and I think the disaster would happen when you forget to also enable it in some config file. PostgreSQL installs both a daemon and periodic scripts, but the scripts do nothing when the daemon is not running. So I think it really depends on what the port does. Erik ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: cron(8) improvement
On Thu, Nov 7, 2013 at 6:43 AM, Lyndon Nerenberg lyn...@orthanc.ca wrote: On Nov 6, 2013, at 7:49 PM, Kimmo Paasiala kpaas...@gmail.com wrote: What's wrong with using the existing tools for achieving the same effect? Periodic can be adapted to do exactly what you're describing as noted above by adding an hourly (even minutely? :D ) periodic run. Periodic is geared towards periodic system maintenance tasks. Once per day, once per week, once per month. It doesn't deal with tasks that need to be fired off at arbitrary intervals. As you say, it could be adapted to run things with per-minute granularity, but it wouldn't scale well. For per-minute granularity you would have to fire off a periodic run every minute. That's five times the rate that atrun(8) kicks off at. That's a lot of overhead for small, embedded, or power constrained systems. And to get the time-granularity cron has, you would have to re-implement cron(8)s dispatch control as a set of shell functions. That's just silly. --lyndon Well ok, I get your point. I guess there's no other option than to add support for a cron.d directory for crontab -snippets. I'd however like to emphasize one thing that has been noted already: - Snippets installed by ports should be disabled by default and enabled only selectively by variables in rc.conf(5) or some other configuration file to mirror what periodic(8) is doing now. This is an absolute must because having them enabled by default is a recipe for disaster. Compare this to services installed by ports, none of them are enabled by default. -Kimmo ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: cron(8) improvement
On 2013-11-07 07:11, Kimmo Paasiala wrote:
On Thu, Nov 7, 2013 at 6:43 AM, Lyndon Nerenberg lyn...@orthanc.ca wrote:
On Nov 6, 2013, at 7:49 PM, Kimmo Paasiala kpaas...@gmail.com wrote:
What's wrong with using the existing tools for achieving the same
effect? Periodic can be adapted to do exactly what you're describing
as noted above by adding an hourly (even minutely? :D ) periodic run.
Periodic is geared towards periodic system maintenance tasks. Once per day,
once per week, once per month. It doesn't deal with tasks that need to be
fired off at arbitrary intervals.
As you say, it could be adapted to run things with per-minute granularity,
but it wouldn't scale well. For per-minute granularity you would have to
fire off a periodic run every minute. That's five times the rate that
atrun(8) kicks off at. That's a lot of overhead for small, embedded, or
power constrained systems. And to get the time-granularity cron has, you
would have to re-implement cron(8)s dispatch control as a set of shell
functions. That's just silly.
--lyndon
Well ok, I get your point. I guess there's no other option than to add
support for a cron.d directory for crontab -snippets. I'd however like
to emphasize one thing that has been noted already:
- Snippets installed by ports should be disabled by default and
enabled only selectively by variables in rc.conf(5) or some other
configuration file to mirror what periodic(8) is doing now. This is
an absolute must because having them enabled by default is a recipe
for disaster. Compare this to services installed by ports, none of
them are enabled by default.
-Kimmo
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Right. The best way to handle this is likely to have the ports install
the example cron to ${PREFIX}/share/portname/ or wherever else they
normally put examples, with instructions in the pkg-message on how to
enable the cron. The same way that ports that add something to apache
don't install to the apache etc/apache22/Includes/ directory, but
instead tell you to add the lines to a file there.
--
Allan Jude
signature.asc
Description: OpenPGP digital signature
Re: cron(8) improvement
On Nov 7, 2013, at 9:13, Allan Jude free...@allanjude.com wrote:
Right. The best way to handle this is likely to have the ports install
the example cron to ${PREFIX}/share/portname/ or wherever else they
normally put examples, with instructions in the pkg-message on how to
enable the cron. The same way that ports that add something to apache
don't install to the apache etc/apache22/Includes/ directory, but
instead tell you to add the lines to a file there.
It’s probably better to have the port’s rc.d script verify the crontab is in
place, and install it if it’s not.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: cron(8) improvement
On 2013-11-07 22:39, Lyndon Nerenberg wrote:
On Nov 7, 2013, at 9:13, Allan Jude free...@allanjude.com wrote:
Right. The best way to handle this is likely to have the ports install
the example cron to ${PREFIX}/share/portname/ or wherever else they
normally put examples, with instructions in the pkg-message on how to
enable the cron. The same way that ports that add something to apache
don't install to the apache etc/apache22/Includes/ directory, but
instead tell you to add the lines to a file there.
It’s probably better to have the port’s rc.d script verify the crontab is in
place, and install it if it’s not.
That might make sense, it really depends on the port and what the cron
is doing.
--
Allan Jude
signature.asc
Description: OpenPGP digital signature
Re: cron(8) improvement
On Nov 7, 2013, at 19:41, Allan Jude free...@allanjude.com wrote: it really depends on the port and what the cron is doing. Why? Can you give some specific examples? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: cron(8) improvement
On Fri, Nov 8, 2013 at 5:42 AM, Lyndon Nerenberg lyn...@orthanc.ca wrote: On Nov 7, 2013, at 19:41, Allan Jude free...@allanjude.com wrote: it really depends on the port and what the cron is doing. Why? Can you give some specific examples? I don't like the idea of having untracked files installed by the rc(8) script. Why not install the cron.d snippet by default but leave everything in it commented out with instructions at the beginning to uncomment the contents to enable it? -Kimmo ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: cron(8) improvement
On 2013-11-07 22:46, Kimmo Paasiala wrote: On Fri, Nov 8, 2013 at 5:42 AM, Lyndon Nerenberg lyn...@orthanc.ca wrote: On Nov 7, 2013, at 19:41, Allan Jude free...@allanjude.com wrote: it really depends on the port and what the cron is doing. Why? Can you give some specific examples? I don't like the idea of having untracked files installed by the rc(8) script. Why not install the cron.d snippet by default but leave everything in it commented out with instructions at the beginning to uncomment the contents to enable it? -Kimmo That seems logical, and that modification will also keep the file from being removed by the port if you did enable it (so upgrades won't silently delete the cron) -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: cron(8) improvement
On Nov 7, 2013, at 19:46, Kimmo Paasiala kpaas...@gmail.com wrote: I don't like the idea of having untracked files installed by the rc(8) script. Why not install the cron.d snippet by default but leave everything in it commented out with instructions at the beginning to uncomment the contents to enable it? It’s un-necessarily complicated. The package manifest can specify both locations for the crontab file. If the copy isn’t made, at package removal the worst that will happen is a warning diagnostic will be printed about the missing file. —lyndon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: cron(8) improvement
On 2013-11-07 23:48, Lyndon Nerenberg wrote: On Nov 7, 2013, at 19:46, Kimmo Paasiala kpaas...@gmail.com wrote: I don't like the idea of having untracked files installed by the rc(8) script. Why not install the cron.d snippet by default but leave everything in it commented out with instructions at the beginning to uncomment the contents to enable it? It’s un-necessarily complicated. The package manifest can specify both locations for the crontab file. If the copy isn’t made, at package removal the worst that will happen is a warning diagnostic will be printed about the missing file. —lyndon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org My use case is puppet etc, not ports/packages, so I'll leave the policy about packages up to portsmgr@, I just want a less sloppy way to manage crontabs with my orchestration system (and feature parity with Linux) -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: cron(8) improvement
05.11.2013 20:21, Mark Felder wrote: On Tue, Nov 5, 2013, at 11:37, Nikolai Lifanov wrote: On 11/05/13 12:31, Allan Jude wrote: This came up in discussion on IRC and I thought I should throw it at the list so I don't forget. A user was asking how to do what linux cron does, where there is a directory /etc/cron.d/ that packages and add files to to create crontabs. Making FreeBSD's cron (Vixie Cron) include /etc/cron.d/ and /usr/local/etc/cron.d/ in the /etc/crontab format seems like a very useful feature, especially for pkg(8) as it makes it easy and safe to programatically add and remove crontabs as part of a package. Shouldn't we encourage packages to use periodic(8) when possible? Yes but our default periodic configuration in /etc/crontab is only configured to be as granular as daily. If this is something that should run hourly or at very strange intervals then cron is a better choice. So why we shouldn't add something like: 0 * * * * root periodic hourly @reboot root periodic reboot I already do this on some machines to take hourly and boot snapshots with zfSnap. And I think periodic is much better place for such tasks. -- Sphinx of black quartz, judge my vow. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: cron(8) improvement
On Wed, Nov 6, 2013, at 2:57, Volodymyr Kostyrko wrote: 05.11.2013 20:21, Mark Felder wrote: On Tue, Nov 5, 2013, at 11:37, Nikolai Lifanov wrote: On 11/05/13 12:31, Allan Jude wrote: This came up in discussion on IRC and I thought I should throw it at the list so I don't forget. A user was asking how to do what linux cron does, where there is a directory /etc/cron.d/ that packages and add files to to create crontabs. Making FreeBSD's cron (Vixie Cron) include /etc/cron.d/ and /usr/local/etc/cron.d/ in the /etc/crontab format seems like a very useful feature, especially for pkg(8) as it makes it easy and safe to programatically add and remove crontabs as part of a package. Shouldn't we encourage packages to use periodic(8) when possible? Yes but our default periodic configuration in /etc/crontab is only configured to be as granular as daily. If this is something that should run hourly or at very strange intervals then cron is a better choice. So why we shouldn't add something like: 0 * * * * root periodic hourly @reboot root periodic reboot I already do this on some machines to take hourly and boot snapshots with zfSnap. And I think periodic is much better place for such tasks. Submit a PR and a patch and maybe it can slip in to 10.0-RELEASE. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: cron(8) improvement
On Nov 5, 2013, at 9:31 AM, Allan Jude free...@allanjude.com wrote: This came up in discussion on IRC and I thought I should throw it at the list so I don't forget. A user was asking how to do what linux cron does, where there is a directory /etc/cron.d/ that packages and add files to to create crontabs. Making FreeBSD's cron (Vixie Cron) include /etc/cron.d/ and /usr/local/etc/cron.d/ in the /etc/crontab format seems like a very useful feature, especially for pkg(8) as it makes it easy and safe to programatically add and remove crontabs as part of a package. This is a good idea. We should do it. How and if this facility gets used is a separate question. Tools, not policy. Support for a cron.d directory is a tool that can be used in many ways. The policy of how it should be used is a separate discussion. (For example, whether or not ports or packages should install crontab files into /usr/local/etc/cron.d/ can be richly debated after that directory exists.) Tim ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: cron(8) improvement
Support for a cron.d directory is a tool that can be used in many ways. I have used cron.d on other UNIXen, and for package-installed cron jobs I find it significantly friendlier, in that it makes these jobs easily identifiable to the sysadmin. As we do it now, the per-user crontabs are quite opaque. It's easy to get a list of the 'logins' that have them, but the best you can do is cat the files and hope the entries are well documented or obvious from context. And editing a single file from an installer script is always subject to failure: it's hard to guard from failure if somebody comes along and, in the course of manually editing the file, upsets the markers the [un]installer scripts are looking for. Allowing a package to add/rm a self-contained file avoids these accidental editing muckups. And with a simple standardized naming convention, the mapping from cron files to packages can be both unique and obvious. This is a big win for the sysadmin trying to track down a mystery run-away cron job. Some attention must be given to setting things the uid/gid to run under, and it might be useful to allow specification of things like the login class, and perhaps capsicum capabilities. Actually, the latter two features are useful in the general case. Regardless, the core idea is both sound and useful. --lyndon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: cron(8) improvement
On Wed, Nov 6, 2013, at 18:21, Tim Kientzle wrote: On Nov 5, 2013, at 9:31 AM, Allan Jude free...@allanjude.com wrote: This came up in discussion on IRC and I thought I should throw it at the list so I don't forget. A user was asking how to do what linux cron does, where there is a directory /etc/cron.d/ that packages and add files to to create crontabs. Making FreeBSD's cron (Vixie Cron) include /etc/cron.d/ and /usr/local/etc/cron.d/ in the /etc/crontab format seems like a very useful feature, especially for pkg(8) as it makes it easy and safe to programatically add and remove crontabs as part of a package. This is a good idea. We should do it. How and if this facility gets used is a separate question. Tools, not policy. Support for a cron.d directory is a tool that can be used in many ways. The policy of how it should be used is a separate discussion. (For example, whether or not ports or packages should install crontab files into /usr/local/etc/cron.d/ can be richly debated after that directory exists.) Ok, so we create that directory. Now nobody can use it in a port until FreeBSD 8.4 is EoL -- approximately June 30, 2015. We should be using the existing cron tabs directory *now*. We can't easily force older versions of FreeBSD to update their cron software or configuration to support that new directory. I'm not saying we shouldn't create it, just that we can't effectively use it for 2 years. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: cron(8) improvement
On 2013-11-06 20:49, Mark Felder wrote: On Wed, Nov 6, 2013, at 18:21, Tim Kientzle wrote: On Nov 5, 2013, at 9:31 AM, Allan Jude free...@allanjude.com wrote: This came up in discussion on IRC and I thought I should throw it at the list so I don't forget. A user was asking how to do what linux cron does, where there is a directory /etc/cron.d/ that packages and add files to to create crontabs. Making FreeBSD's cron (Vixie Cron) include /etc/cron.d/ and /usr/local/etc/cron.d/ in the /etc/crontab format seems like a very useful feature, especially for pkg(8) as it makes it easy and safe to programatically add and remove crontabs as part of a package. This is a good idea. We should do it. How and if this facility gets used is a separate question. Tools, not policy. Support for a cron.d directory is a tool that can be used in many ways. The policy of how it should be used is a separate discussion. (For example, whether or not ports or packages should install crontab files into /usr/local/etc/cron.d/ can be richly debated after that directory exists.) Ok, so we create that directory. Now nobody can use it in a port until FreeBSD 8.4 is EoL -- approximately June 30, 2015. We should be using the existing cron tabs directory *now*. We can't easily force older versions of FreeBSD to update their cron software or configuration to support that new directory. I'm not saying we shouldn't create it, just that we can't effectively use it for 2 years. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org My use case is less about packages, and more about puppet, ansible etc. Puppet relies on these hideously large markers in the crontab files to programmatically add/remove crons, whereas a cron.d directory could be done nice and clean And in that case, the fact that it is not supported on 8.x does not bother me. -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: cron(8) improvement
On Thu, Nov 7, 2013 at 4:27 AM, Allan Jude free...@allanjude.com wrote: On 2013-11-06 20:49, Mark Felder wrote: On Wed, Nov 6, 2013, at 18:21, Tim Kientzle wrote: On Nov 5, 2013, at 9:31 AM, Allan Jude free...@allanjude.com wrote: This came up in discussion on IRC and I thought I should throw it at the list so I don't forget. A user was asking how to do what linux cron does, where there is a directory /etc/cron.d/ that packages and add files to to create crontabs. Making FreeBSD's cron (Vixie Cron) include /etc/cron.d/ and /usr/local/etc/cron.d/ in the /etc/crontab format seems like a very useful feature, especially for pkg(8) as it makes it easy and safe to programatically add and remove crontabs as part of a package. This is a good idea. We should do it. How and if this facility gets used is a separate question. Tools, not policy. Support for a cron.d directory is a tool that can be used in many ways. The policy of how it should be used is a separate discussion. (For example, whether or not ports or packages should install crontab files into /usr/local/etc/cron.d/ can be richly debated after that directory exists.) Ok, so we create that directory. Now nobody can use it in a port until FreeBSD 8.4 is EoL -- approximately June 30, 2015. We should be using the existing cron tabs directory *now*. We can't easily force older versions of FreeBSD to update their cron software or configuration to support that new directory. I'm not saying we shouldn't create it, just that we can't effectively use it for 2 years. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org My use case is less about packages, and more about puppet, ansible etc. Puppet relies on these hideously large markers in the crontab files to programmatically add/remove crons, whereas a cron.d directory could be done nice and clean And in that case, the fact that it is not supported on 8.x does not bother me. -- Allan Jude What's wrong with using the existing tools for achieving the same effect? Periodic can be adapted to do exactly what you're describing as noted above by adding an hourly (even minutely? :D ) periodic run. Also periodic already has support for ports installing their own jobs under /usr/local/etc/periodic.d that can be enabled/disabled in periodic.conf. -Kimmo ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: cron(8) improvement
On 2013-11-06 22:49, Kimmo Paasiala wrote: On Thu, Nov 7, 2013 at 4:27 AM, Allan Jude free...@allanjude.com wrote: On 2013-11-06 20:49, Mark Felder wrote: On Wed, Nov 6, 2013, at 18:21, Tim Kientzle wrote: On Nov 5, 2013, at 9:31 AM, Allan Jude free...@allanjude.com wrote: This came up in discussion on IRC and I thought I should throw it at the list so I don't forget. A user was asking how to do what linux cron does, where there is a directory /etc/cron.d/ that packages and add files to to create crontabs. Making FreeBSD's cron (Vixie Cron) include /etc/cron.d/ and /usr/local/etc/cron.d/ in the /etc/crontab format seems like a very useful feature, especially for pkg(8) as it makes it easy and safe to programatically add and remove crontabs as part of a package. This is a good idea. We should do it. How and if this facility gets used is a separate question. Tools, not policy. Support for a cron.d directory is a tool that can be used in many ways. The policy of how it should be used is a separate discussion. (For example, whether or not ports or packages should install crontab files into /usr/local/etc/cron.d/ can be richly debated after that directory exists.) Ok, so we create that directory. Now nobody can use it in a port until FreeBSD 8.4 is EoL -- approximately June 30, 2015. We should be using the existing cron tabs directory *now*. We can't easily force older versions of FreeBSD to update their cron software or configuration to support that new directory. I'm not saying we shouldn't create it, just that we can't effectively use it for 2 years. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org My use case is less about packages, and more about puppet, ansible etc. Puppet relies on these hideously large markers in the crontab files to programmatically add/remove crons, whereas a cron.d directory could be done nice and clean And in that case, the fact that it is not supported on 8.x does not bother me. -- Allan Jude What's wrong with using the existing tools for achieving the same effect? Periodic can be adapted to do exactly what you're describing as noted above by adding an hourly (even minutely? :D ) periodic run. Also periodic already has support for ports installing their own jobs under /usr/local/etc/periodic.d that can be enabled/disabled in periodic.conf. -Kimmo Programmatically installing a cron that runs at odd intervals (our use case, on minutes 9,24,39,54 of each hour, manually staggered across groups of hosts). To enable a new periodic run, you have to edit the /etc/crontab file. I could add my cronjobs there directly, or via the crontab command (how puppet does it now), but i'd rather drop files in a directory, so they can be more easily removed or updated. From a management perspective, when dealing with 100s of machines, it is just a much nicer way to do it. -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: cron(8) improvement
On Nov 6, 2013, at 7:49 PM, Kimmo Paasiala kpaas...@gmail.com wrote: What's wrong with using the existing tools for achieving the same effect? Periodic can be adapted to do exactly what you're describing as noted above by adding an hourly (even minutely? :D ) periodic run. Periodic is geared towards periodic system maintenance tasks. Once per day, once per week, once per month. It doesn't deal with tasks that need to be fired off at arbitrary intervals. As you say, it could be adapted to run things with per-minute granularity, but it wouldn't scale well. For per-minute granularity you would have to fire off a periodic run every minute. That's five times the rate that atrun(8) kicks off at. That's a lot of overhead for small, embedded, or power constrained systems. And to get the time-granularity cron has, you would have to re-implement cron(8)s dispatch control as a set of shell functions. That's just silly. --lyndon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: cron(8) improvement
On 11/05/13 12:31, Allan Jude wrote: This came up in discussion on IRC and I thought I should throw it at the list so I don't forget. A user was asking how to do what linux cron does, where there is a directory /etc/cron.d/ that packages and add files to to create crontabs. Making FreeBSD's cron (Vixie Cron) include /etc/cron.d/ and /usr/local/etc/cron.d/ in the /etc/crontab format seems like a very useful feature, especially for pkg(8) as it makes it easy and safe to programatically add and remove crontabs as part of a package. Shouldn't we encourage packages to use periodic(8) when possible? - Nikolai Lifanov ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: cron(8) improvement
On Tue, Nov 5, 2013, at 11:37, Nikolai Lifanov wrote: On 11/05/13 12:31, Allan Jude wrote: This came up in discussion on IRC and I thought I should throw it at the list so I don't forget. A user was asking how to do what linux cron does, where there is a directory /etc/cron.d/ that packages and add files to to create crontabs. Making FreeBSD's cron (Vixie Cron) include /etc/cron.d/ and /usr/local/etc/cron.d/ in the /etc/crontab format seems like a very useful feature, especially for pkg(8) as it makes it easy and safe to programatically add and remove crontabs as part of a package. Shouldn't we encourage packages to use periodic(8) when possible? Yes but our default periodic configuration in /etc/crontab is only configured to be as granular as daily. If this is something that should run hourly or at very strange intervals then cron is a better choice. If the application is installing its own user they could install their own crontab file in /var/cron/tabs. I'm certain I've seen a couple ports do this. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: cron(8) improvement
On 2013-11-05 13:21, Mark Felder wrote: On Tue, Nov 5, 2013, at 11:37, Nikolai Lifanov wrote: On 11/05/13 12:31, Allan Jude wrote: This came up in discussion on IRC and I thought I should throw it at the list so I don't forget. A user was asking how to do what linux cron does, where there is a directory /etc/cron.d/ that packages and add files to to create crontabs. Making FreeBSD's cron (Vixie Cron) include /etc/cron.d/ and /usr/local/etc/cron.d/ in the /etc/crontab format seems like a very useful feature, especially for pkg(8) as it makes it easy and safe to programatically add and remove crontabs as part of a package. Shouldn't we encourage packages to use periodic(8) when possible? Yes but our default periodic configuration in /etc/crontab is only configured to be as granular as daily. If this is something that should run hourly or at very strange intervals then cron is a better choice. If the application is installing its own user they could install their own crontab file in /var/cron/tabs. I'm certain I've seen a couple ports do this. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org I don't have a specific example off the top of my head, but I am sure there are some daemons that needs to do something at some interval as root. Personally I am not so sure about having a package create a crontab automatically. It seems like a POLA violation, but it is also something that seems to be expected by some modern applications. I assume it is mostly handled by pkg-message currently, and maybe it is best to continue that way, but having the additional flexibility may be very useful. If for nothing else, it would be a lot prettier than the way I currently manage crontabs using puppet. -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: cron(8) improvement
On 11/05/13 13:28, Allan Jude wrote: On 2013-11-05 13:21, Mark Felder wrote: On Tue, Nov 5, 2013, at 11:37, Nikolai Lifanov wrote: On 11/05/13 12:31, Allan Jude wrote: This came up in discussion on IRC and I thought I should throw it at the list so I don't forget. A user was asking how to do what linux cron does, where there is a directory /etc/cron.d/ that packages and add files to to create crontabs. Making FreeBSD's cron (Vixie Cron) include /etc/cron.d/ and /usr/local/etc/cron.d/ in the /etc/crontab format seems like a very useful feature, especially for pkg(8) as it makes it easy and safe to programatically add and remove crontabs as part of a package. Shouldn't we encourage packages to use periodic(8) when possible? Yes but our default periodic configuration in /etc/crontab is only configured to be as granular as daily. If this is something that should run hourly or at very strange intervals then cron is a better choice. If the application is installing its own user they could install their own crontab file in /var/cron/tabs. I'm certain I've seen a couple ports do this. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org I don't have a specific example off the top of my head, but I am sure there are some daemons that needs to do something at some interval as root. Personally I am not so sure about having a package create a crontab automatically. It seems like a POLA violation, but it is also something that seems to be expected by some modern applications. I assume it is mostly handled by pkg-message currently, and maybe it is best to continue that way, but having the additional flexibility may be very useful. If for nothing else, it would be a lot prettier than the way I currently manage crontabs using puppet. I would be frustrated if a port installed a root cron job without my intervention. How about an RC extension that dynamically adds these? Think 'drupal_cron_enable=YES'. I just think that there should be something an operator does, either explicitly or through configuration management, to add a cron job for root. We don't auto-enable daemons, so we should not auto-add these either. - Nikolai Lifanov ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
