Power down of hard disk by systemd after running backup

I issued a sync in Konsole right prior to shutting down. The disk still spins up even after that. Any chance to get journalctl to spit out the culprit after next boot?

Btw. I didn’t get a message / mail like usually after you posted. Any idea what changed?

@matsch journalctl -r -b -1 to look at the last boot/shutdown, starting at the final entry in the log and in reverse :wink:

The file naming seems to be incorrect.
Rename to: ST6000VX001-2BD186-ZR10EVLM.conf

@malcolmlewis

Whoa, somehow I missed the options of journalctl, now those are nice. I’ll keep them in mind for the future, thanks for the pointer :slight_smile:

On the other hand the output is overwhelming in sheer mass so I didn’t see any commands re-starting the disk. I tried to grep e.g. for “mount”, “rsync” but no joy. Which program could cause this?

@heitormoreira

Renaming didn’t help either. but then I noticed in the (abbreviated) output of udisksctl:

matthias@ryzen:~> udisksctl info -b /dev/sda
...
    Drive:                      '/org/freedesktop/UDisks2/drives/ST6000VX001_2BD186_ZR10EVLM'
...
    Id:                         by-id-ata-ST6000VX001-2BD186_ZR10EVLM
...
    Symlinks:                   /dev/disk/by-diskseq/3
                                /dev/disk/by-id/ata-ST6000VX001-2BD186_ZR10EVLM
...
matthias@ryzen:~> 

As you can see, the descriptor changes “_” and “-” seemingly random. Next I’ll try the Symlinks notation…

Did you add the --no-pager option when using grep? You might want to try sda or ata…

@heitormoreira

No Joy, the disk simply stays active/idle.

@malcolmlewis

Since the disk didn’t spin down (and up again) I couldn’t test your suggestion yet. Will do it later.

Here it comes:

matthias@ryzen:~> sudo journalctl  -r -b -1 --no-pager -g sda
Jul 17 23:44:12 ryzen smartd[1111]: Device: /dev/sda [SAT], state written to /var/lib/smartmontools/smartd.ST6000VX001_2BD186-ZR10EVLM.ata.state
Jul 17 23:44:12 ryzen systemd[1]: Stopped File System Check on /dev/sda1.
Jul 17 23:44:12 ryzen systemd[1]: systemd-fsck@dev-sda1.service: Deactivated successfully.
Jul 17 23:44:12 ryzen systemd[1]: spindown-sda.service: Deactivated successfully.
Jul 17 23:43:55 ryzen sudo[15146]: matthias : TTY=pts/0 ; PWD=/home/matthias ; USER=root ; COMMAND=/usr/sbin/hdparm -C /dev/sda
Jul 17 21:51:36 ryzen sudo[8130]: matthias : TTY=pts/0 ; PWD=/home/matthias ; USER=root ; COMMAND=/usr/sbin/hdparm -C /dev/sda
Jul 17 20:00:25 ryzen sudo[6540]: matthias : TTY=pts/0 ; PWD=/home/matthias ; USER=root ; COMMAND=/usr/sbin/hdparm -C /dev/sda
Jul 17 19:22:32 ryzen sh[4914]: /dev/sda:
Jul 17 19:22:31 ryzen kernel: EXT4-fs (sda1): unmounting filesystem 792fc662-3296-4884-8743-4868ce71f55c.
Jul 17 19:17:20 ryzen spindown-sda.sh[1862]: /dev/sda:
Jul 17 19:17:20 ryzen spindown-sda.sh[1852]: Setting spindown timeout for /dev/sda...
Jul 17 19:17:16 ryzen CRON[1572]: (root) CMDEND (/usr/bin/nice -n19 /usr/bin/ionice -c2 -n7 /usr/bin/backintime backup-job >/dev/null hdparm -y /dev/sda)
Jul 17 19:17:16 ryzen CRON[1575]: (root) CMD (/usr/bin/nice -n19 /usr/bin/ionice -c2 -n7 /usr/bin/backintime backup-job >/dev/null hdparm -y /dev/sda)
...

If I understand this correctly systemd started and aborted a file system check on the disk / partition in question. Is that normal during shutdown?

As an aside the disk spins up also when a “zypper dup” finishes…