Re: root crontab @reboot for loop fails

2022-07-16 Thread Nicolas George
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

2022-07-16 Thread Greg Wooledge
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

2022-07-16 Thread Timothy M Butterworth
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

2022-07-16 Thread Gareth Evans



> 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

2022-07-16 Thread Anssi Saari
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

2022-07-16 Thread Greg Wooledge
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

2022-07-16 Thread Greg Wooledge
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

2022-07-16 Thread Tixy
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

2022-07-15 Thread Gareth Evans
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

2022-07-15 Thread Gareth Evans
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

2022-07-15 Thread Greg Wooledge
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

2022-07-15 Thread Gareth Evans
$ 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

2022-07-15 Thread Gareth Evans
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