Re: root crontab @reboot for loop fails
Timothy M Butterworth (12022-07-16): > rc.local does not exist in Debian 11. "/etc/rc.local: No such file or > directory" should it be a file or a directory? rc.local is for compatibility with legacy admin practices. Somebody showed in this thread how it is implemented for systemd. In my opinion, your best course of action is to imitate that for your specific need. Regards, -- Nicolas George signature.asc Description: PGP signature
Re: root crontab @reboot for loop fails
On Sat, Jul 16, 2022 at 12:06:38PM -0400, Timothy M Butterworth wrote: > rc.local does not exist in Debian 11. "/etc/rc.local: No such file or > directory" should it be a file or a directory? If you wish to use it, it must be a file, with execute permission, and with a valid shebang (#!/bin/sh).
Re: root crontab @reboot for loop fails
On Fri, Jul 15, 2022 at 11:07 PM Greg Wooledge wrote: > On Sat, Jul 16, 2022 at 03:49:09AM +0100, Gareth Evans wrote: > > $ sudo crontab -l > > [...] > > @reboot for f in $(/usr/sbin/zfs list -t snap -o name|grep reboot); do > /usr/sbin/zfs destroy $f;done > > @reboot /usr/sbin/zfs snap -r rpool@reboot > > > > > > Prepending "/usr/sbin/" to "zfs" doesn't make a difference. > > Let me start by saying I don't know a single thing about ZFS. > > My first reaction to this thread of yours is, "Well, read the email that > cron sends you and see what the errors are." > > But that's the easy and obvious reaction. My second reaction goes a > little bit deeper: > > "All your crontab entries run in parallel. So your first line which > has zfs in it, and your second line which also has zfs in it, those both > run at the same time. Is that OK?" > > Since I have no idea what any of those ZFS commands do, I can't tell > whether it's OK to have that race condition. I suspect it's not OK, > but what do I know? > > My third reaction goes something like this: > > "If you wanted to run a bunch of commands a boot time, without setting > up systemd units for them, and proper dependencies, why didn't you just > use /etc/rc.local?" > rc.local does not exist in Debian 11. "/etc/rc.local: No such file or directory" should it be a file or a directory? > Using a crontab to duplicate the functionality of rc.local seems odd to me. > > Anyway, read your errors. They may tell you what's wrong. Figure out > whether your commands are allowed to run in parallel. If they're not, > use a *script*, instead of a bunch of parallel commands. That script > could be /etc/rc.local, or it could be a separate script that you call > from rc.local, or even call from crontab if you really insist. > > -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/ ⠈⠳⣄⠀⠀
Re: root crontab @reboot for loop fails
> On 16 Jul 2022, at 14:39, Anssi Saari wrote: > > Tixy writes: > >> rc.local is still run on the latest Debian stable. You need to make >> sure it's a proper executable, i.e. starts with a shebang like >> '#!/bin/sh' and the file has execute permissions. > > Yes and that's because the systemd package contains the rc-local.service > which just runs /etc/rc.local. With a ConditionFileIsExecutable too > which I wasn't aware of before. Thanks all, that was both helpful and informative Gareth
Re: root crontab @reboot for loop fails
Tixy writes: > rc.local is still run on the latest Debian stable. You need to make > sure it's a proper executable, i.e. starts with a shebang like > '#!/bin/sh' and the file has execute permissions. Yes and that's because the systemd package contains the rc-local.service which just runs /etc/rc.local. With a ConditionFileIsExecutable too which I wasn't aware of before.
Re: root crontab @reboot for loop fails
On Sat, Jul 16, 2022 at 08:13:56AM +0100, Tixy wrote: > On Sat, 2022-07-16 at 05:30 +0100, Gareth Evans wrote: > > I was of the impression (which I think it is fair to say has been created) > > that systemd had done away with /etc/rc.local > > rc.local is still run on the latest Debian stable. You need to make > sure it's a proper executable, i.e. starts with a shebang like > '#!/bin/sh' and the file has execute permissions. Correct. You can also see its systemd unit: unicorn:~$ systemctl status rc-local ● rc-local.service - /etc/rc.local Compatibility Loaded: loaded (/lib/systemd/system/rc-local.service; static) Drop-In: /lib/systemd/system/rc-local.service.d └─debian.conf Active: inactive (dead) Docs: man:systemd-rc-local-generator(8) unicorn:~$ systemctl cat rc-local # /lib/systemd/system/rc-local.service [...] [Unit] Description=/etc/rc.local Compatibility Documentation=man:systemd-rc-local-generator(8) ConditionFileIsExecutable=/etc/rc.local After=network.target [Service] Type=forking ExecStart=/etc/rc.local start [...] I'm not using one on this particular computer, hence "inactive (dead)". Note also the Debian changes at the end of the unit file (or in the separate Drop-In literal file if you aren't using "systemctl cat").
Re: root crontab @reboot for loop fails
On Sat, Jul 16, 2022 at 05:35:39AM +0100, Gareth Evans wrote: > On Sat 16 Jul 2022, at 05:30, Gareth Evans wrote: > > > Why isn't root's $PATH available to root crontab? ie. including the > > link /sbin -> /usr/sbin? > > By which I mean: why can't root crontab do everything sudo can do? Because they're different programs. crontab(5): Several environment variables are set up automatically by the cron(8) daemon. SHELL is set to /bin/sh, and LOGNAME and HOME are set from the /etc/passwd line of the crontab's owner.PATH is set to "/usr/bin:/bin". [...] Debian's /etc/sudoers file: Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin" So, it depends on whether you're using the default settings, or changing them.
Re: root crontab @reboot for loop fails
On Sat, 2022-07-16 at 05:30 +0100, Gareth Evans wrote: > I was of the impression (which I think it is fair to say has been created) > that systemd had done away with /etc/rc.local rc.local is still run on the latest Debian stable. You need to make sure it's a proper executable, i.e. starts with a shebang like '#!/bin/sh' and the file has execute permissions. -- Tixy
Re: root crontab @reboot for loop fails
On Sat 16 Jul 2022, at 05:30, Gareth Evans wrote: > Why isn't root's $PATH available to root crontab? ie. including the > link /sbin -> /usr/sbin? By which I mean: why can't root crontab do everything sudo can do? Thanks G
Re: root crontab @reboot for loop fails
Hi Greg, On Sat 16 Jul 2022, at 04:07, Greg Wooledge wrote: [...] > "Well, read the email that cron sends you and see what the errors are." [amongst others] /bin/sh: 1: zfs: not found suggests the need for /usr/sbin/zfs It seems reasonable that /usr/sbin/* should be available to root crontab. Why isn't root's $PATH available to root crontab? ie. including the link /sbin -> /usr/sbin? > "All your crontab entries run in parallel. OK thanks. Is this documented? $ man crontab then /parallel [ie search for "parallel"] returns nothing. > "If you wanted to run a bunch of commands a boot time, without setting > up systemd units for them, and proper dependencies, why didn't you just > use /etc/rc.local?" I was of the impression (which I think it is fair to say has been created) that systemd had done away with /etc/rc.local, and crontab @reboot is much simpler than systemd units and whatever dependencies there may be. > Figure out whether your commands are allowed to run in parallel [...] They are not. > If they're not, use a *script* [...] With /usr/bin/zfs, that's working, thank you. Best wishes, Gareth
Re: root crontab @reboot for loop fails
On Sat, Jul 16, 2022 at 03:49:09AM +0100, Gareth Evans wrote: > $ sudo crontab -l > [...] > @reboot for f in $(/usr/sbin/zfs list -t snap -o name|grep reboot); do > /usr/sbin/zfs destroy $f;done > @reboot /usr/sbin/zfs snap -r rpool@reboot > > > Prepending "/usr/sbin/" to "zfs" doesn't make a difference. Let me start by saying I don't know a single thing about ZFS. My first reaction to this thread of yours is, "Well, read the email that cron sends you and see what the errors are." But that's the easy and obvious reaction. My second reaction goes a little bit deeper: "All your crontab entries run in parallel. So your first line which has zfs in it, and your second line which also has zfs in it, those both run at the same time. Is that OK?" Since I have no idea what any of those ZFS commands do, I can't tell whether it's OK to have that race condition. I suspect it's not OK, but what do I know? My third reaction goes something like this: "If you wanted to run a bunch of commands a boot time, without setting up systemd units for them, and proper dependencies, why didn't you just use /etc/rc.local?" Using a crontab to duplicate the functionality of rc.local seems odd to me. Anyway, read your errors. They may tell you what's wrong. Figure out whether your commands are allowed to run in parallel. If they're not, use a *script*, instead of a bunch of parallel commands. That script could be /etc/rc.local, or it could be a separate script that you call from rc.local, or even call from crontab if you really insist.
Re: root crontab @reboot for loop fails
$ sudo crontab -l [...] @reboot for f in $(/usr/sbin/zfs list -t snap -o name|grep reboot); do /usr/sbin/zfs destroy $f;done @reboot /usr/sbin/zfs snap -r rpool@reboot Prepending "/usr/sbin/" to "zfs" doesn't make a difference. Thanks, Gareth
root crontab @reboot for loop fails
Hello, $ sudo crontab -l | grep reboot [...] [1] @reboot sleep 10; nmcli c up [2] @reboot for f in $(zfs list -t snap -o name|grep reboot); do zfs destroy $f;done [3] @reboot zfs snap -r rpool@reboot [1] succeeds, but [2,3] do not. Any ideas why would be gratefully received. Many thanks, Gareth