Hi *.*,
I use a RPi4 with an external USB-HD as backup solution.
It runs restic on
pi:~ $ uname -a
Linux resticrepo 5.10.60-v7l+ #1449 SMP Wed Aug 25 15:00:44 BST 2021
armv7l GNU/Linux
pi:~ $ lsb_release -a
No LSB modules are available.
Distributor ID: Raspbian
Description: Raspbian GNU/Linux 10 (buster)
Release: 10
Codename: buster

The USB-HD goes to sleep automatically a few minutes after usage.
But it awakes about every 30 minutes. Of course it should not.
It shall only work if needed for backup once a day.

How can I identify the process which awakes the USB-HD?

TIA, Stefan

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On Tue, 2 Nov 2021 08:00:03 +0100, Stefan Kaintoch wrote:

Hi *.*,
I use a RPi4 with an external USB-HD as backup solution.
It runs restic on pi:~ $ uname -a Linux resticrepo 5.10.60-v7l+ #1449
SMP Wed Aug 25 15:00:44 BST 2021 armv7l GNU/Linux pi:~ $ lsb_release -a
No LSB modules are available.
Distributor ID: Raspbian Description: Raspbian GNU/Linux 10 (buster) Release: 10 Codename: buster

The USB-HD goes to sleep automatically a few minutes after usage. But it awakes about every 30 minutes. Of course it should not.
It shall only work if needed for backup once a day.

How can I identify the process which awakes the USB-HD?

Try these suggestions:

- see if there are any cron jobs with a 30 minute repeat rate. If there
are any, they'll be in one of the /etc/cron.* directories

- run "systemctl", which uses less to display a list of all systemd
services, showing which are loaded and active together with a short
description of what the job does.

- run 'top' in a terminal window and watch it as the time for the disk
activity approaches.

- Better, run

ls -s /var/log/*

Make a note of all the logs with a timestamp thats a bit *later* than
the last time you know the disk was woken up, and use 'less' to see
what, activity was logged at that time. Then scan through these logs to
see what happened at that time. There probably won't be more
than half a dozen logs to look at.

Hint: if you look for the last ocurrence it will be near the end of
the log. Be sure to use a command like:

sudo less /var/log/syslog

to look at the log: log files are only intended to be read by the
sysadmin, which is why you need to prefix the command with 'sudo'
and provide a password when asked.

If you've never used 'less' before, do read its manpage because its got
very powerful file searching abilities, all triggered with with single
key commands. Its one of the essential Linux tools that you really
should know how to use.


--
--
Martin | martin at
Gregorie | gregorie dot org
--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

Martin Gregorie <martin@mydomain.invalid> wrote:

On Tue, 2 Nov 2021 08:00:03 +0100, Stefan Kaintoch wrote:

How can I identify the process which awakes the USB-HD?

Try these suggestions:

I'd also try:

sudo lsof | grep /media

where /media is (part of) the path to the USB-HD.

It's trickier if your root fs is on the HDD, because everything will be
living there.

For processes you might also run:

ps axl | awk '$10 ~ /D/'

which will tell you everything that's waiting on I/O. You could log that in
a file:

#!/bin/sh
while true; do
ps axl | awk '$10 ~ /D/' >> unintsleep.log
done

(although that may cause a feedback loop if the logging causes its own I/O
to block)

Theo

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

Thanks for the advice.
We had a power outage last night. Since then the external drive sleeps
as it should. Therefore: no chance to identify the root cause.

Bye, Stefan (semi-happy with the current state)
--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On 11/3/21 2:42 AM, Stefan Kaintoch wrote:

Thanks for the advice.
We had a power outage last night. Since then the external drive sleeps
as it should. Therefore: no chance to identify the root cause.

Bye, Stefan (semi-happy with the current state)

Keep watching it. Remember the old saying "Problems that go away by
themselves come back by themselves".

It may be a sequence of events that causes the problem, and that
sequence may take a while to happen.
--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)