keithh666
September 25, 2018, 9:46am
18
if you use -ve number it takes the newest files
core-ssh:/backup# find /backup/* -mtime -5
/backup/55f83d3e.tar
/backup/93282f30.tar
/backup/cd708564.tar
/backup/f510d046.tar
core-ssh:/backup# find /backup/* -mtime +5
/backup/0d00a7d8.tar
/backup/31238b08.tar
/backup/3c14e9d6.tar
/backup/3ea6fbd3.tar
/backup/a6f2844a.tar
/backup/b2f5c512.tar
/backup/b9336de2.tar
core-ssh:/backup# ls --full-time -t
total 742532
-rw-r--r-- 1 root root 8192 2018-09-24 23:29:17 +0100 f510d046.tar
-rw-r--r-- 1 root root 69632 2018-09-23 23:27:18 +0100 93282f30.tar
-rw-r--r-- 1 root root 96716800 2018-09-23 01:04:29 +0100 cd708564.tar
-rw-r--r-- 1 root root 24576 2018-09-20 23:26:59 +0100 55f83d3e.tar
-rw-r--r-- 1 root root 86650880 2018-09-19 23:06:03 +0100 ec7bfd29.tar
-rw-r--r-- 1 root root 64020480 2018-09-15 23:04:11 +0100 a6f2844a.tar
-rw-r--r-- 1 root root 77598720 2018-09-14 23:05:33 +0100 3c14e9d6.tar
-rw-r--r-- 1 root root 78172160 2018-09-13 23:05:08 +0100 b2f5c512.tar
-rw-r--r-- 1 root root 123033600 2018-09-12 23:07:15 +0100 0d00a7d8.tar
-rw-r--r-- 1 root root 101079040 2018-09-11 23:05:58 +0100 3ea6fbd3.tar
-rw-r--r-- 1 root root 75755520 2018-09-10 23:04:23 +0100 31238b08.tar
-rw-r--r-- 1 root root 57210880 2018-09-09 23:03:38 +0100 b9336de2.tar
Yeah ok… perhaps it’s different with the windows command I used… was just a thought.
In Windows I have this command:
ForFiles /p “C:\Users\david\Dropbox\Apps\Docker Backups NUC” /s /d -2 /c “cmd /c del @file ”
Where the /d -2 denotes files older than 2 days. It does exactly that and stops my dropbox filling up…
tom_l
September 26, 2018, 12:26am
21
Still not deleting old files.
This works fine via ssh: find /backup/* -mtime +30 -exec rm {} +
But trying to run it as a shell command:
delete_old_snapshots: find /backup/* -mtime +30 -exec rm {} +
fails with
2018-09-26 01:15:11 ERROR (MainThread) [homeassistant.components.shell_command] Error running command: find /backup/* -mtime +30 -exec rm {} +, return code: 1
I can only assume it is some sort of permissions thing.
keithh666
September 26, 2018, 12:36am
22
My hassio build is down atm as I’m moving over to a small desktop ubuntu machine so I can’t test it. There must be a way to add the permissions needed by rm, but I don’t know them
I think I worked it out…
I had a similar issue. I can run this in ssh:
/usr/bin/mosquitto_sub -h sonoff.maddox.co.uk -t '#' -C 1
But as a command line sensor it fails.
I think in ssh it’s running in the host system but in a command line it’s running in the docker container or I might have them around the wrong way. In my case, one container or the other didn’t have the mosquitto_sub command available.
Just confirmed in WinSCP, the host doesn’t work as mosquitto_sub does not exist in the /usr/bin folder. The hass.io …
tom_l
September 26, 2018, 2:52am
24
Thanks David. I’ll give this a go.
delete_old_snapshots: find /usr/share/hassio/backup/* -mtime +30 -exec rm {} +
Might have to wait a couple of days for confirmation. I deleted the old files via ssh.
tom_l
September 26, 2018, 3:17pm
25
No luck unfortunately.
Error running command: `find /usr/share/hassio/backup/* -mtime +30 -exec rm {} +`, return code: 1
NoneType: None
turboc
September 26, 2018, 5:45pm
26
run
tom_l
September 26, 2018, 10:55pm
27
turboc:
run
The trouble with that is SSH might work in a different container to HA, as evidenced by the previous commands working via SSH but not as shell_commands.
turboc
September 27, 2018, 2:32pm
28
but the “find” command should be installed in the same directory regardless. There shouldn’t be two of them on the same server. What I’m thinking is that “find” isn’t being found in whatever environment you have when your shell command is run. You may have said this earlier, is this being run as a cron job or some other scheduler.
tom_l
September 27, 2018, 2:34pm
29
A time triggered automation calls the shell command.
tom_l
September 27, 2018, 2:36pm
30
core-ssh:~# which find
turboc
September 27, 2018, 2:44pm
31
so try putting /usr/bin in front of your find command and see if specifying the path to find helps.
tom_l
September 28, 2018, 3:24pm
32
Sigh.
Error running command: /usr/bin/find /usr/share/hassio/backup/* -mtime +30 -exec rm {} +, return code: 1
One last thing to try:
/usr/bin/find /backup/* -mtime +30 -exec rm {} +
tom_l
September 29, 2018, 3:18pm
33
Error running command: `/usr/bin/find /backup/* -mtime +30 -exec rm {} +`, return code: 1
NoneType: None
That’s it. I’m out of ideas. Going to delete them from the samba share using task scheduler on another always on PC on the network.
Which is the approach I’m using. I think the issue as I said is the docker container running the command_line in yaml is different to the ssh container and those files just aren’t available in the command_line container.
tom_l
September 30, 2018, 2:26am
35
@DavidFW1960 do you just have a batch file with the command you posted above called by windows task scheduler?
Not a batch file. Using Task Scheduler defining an action like this:
1 Like
tom_l
September 30, 2018, 2:40am
37
Just as well I tested this first. Going to have to map the samba share to a drive.
C:\Users\Tom>ForFiles /p "\\hassio\backup" /s /d -30 /c "cmd /c del @file"
ERROR: UNC paths (\\machine\share) are not supported.
1 Like
