Error on /etc/cron.weekly/openmediavault-update-smart-drivedb: broken pipe

I'm getting the same error. No idea what it means.

Same error for me - did anybody find out how to fix this?

Yes, but I don't remember now how I did it. I should have posted back. Sorry 'bout that.

Can you maybe post some points where I can continue to investigate?

You might try searching for that error as it relates to Debian.

I tried, but unfortunately I was not very successful - all threads I found didn't have solution... Only one with a solution was this, but I don't have clamav...

ClamAV Fehler?

I mean search the web, not just OMV forums.

I am trying

I think I found it:
https://www.thomas-krenn.com/d…ve_Database_aktualisieren

update-smart-drivedb verwendet veralteten Download-Link

Aufgrund von Änderungen in der Infrastruktur von Sourceforge stimmt seit mindestens Anfang August 2013 der ursprüngliche Download-Link in update-smart-drivedb nicht mehr.[2][3]

Es erscheint dabei folgende Fehlermeldung:

$ sudo update-smart-drivedb
/usr/share/smartmontools/drivedb.h.error: rejected by /usr/sbin/smartctl, probably no longer compatible

Durch Änderung der URL in /usr/sbin/update-smart-drivedb kann das Problem behoben werden:

# ViewVC repository browser
## MANUALLY UPDATED: commented orginial URL and inserted URL from script of smartmontools v6.2 package.
## SRCEXPR='http://smartmontools.svn.sourceforge.net/viewvc/smartmontools/$location/smartmontools/drivedb.h?revision=HEAD'
SRCEXPR='http://sourceforge.net/p/smartmontools/code/HEAD/tree/$location/smartmontools/drivedb.h?format=raw'

After changing the link with nano I could run update-smart-drivedb again and everything the email was fixed!

Hope this helps!

For me, even after the above update I got the same error. To make it work, I had to replace 'http' with 'https' in the file, so:
$ nano /usr/sbin/update-smart-drivedb

replace lines

# ViewVC repository browser
SRCEXPR='http://smartmontools.svn.sourceforge.net/viewvc/smartmontools/$location/smartmontools/drivedb.h?revision=HEAD'

with

# ViewVC repository browser
## MANUALLY UPDATED: commented orginial URL and inserted URL from script of smartmontools v6.2 package.
## SRCEXPR='http://smartmontools.svn.sourceforge.net/viewvc/smartmontools/$location/smartmontools/drivedb.h?revision=HEAD'
SRCEXPR='https//sourceforge.net/p/smartmontools/code/HEAD/tree/$location/smartmontools/drivedb.h?format=raw'

mhm - I also fear I celebrated too early. With the above changes (also including the https change!) I still get the error when the weekly job is executed automatically.

But now it gets interesting:

The openmediavault weekly script has also the correction:

set -e


tmpscript=$(mktemp)


cleanup() {
    rm -f ${tmpscript}
    exit
}


trap cleanup 0 1 2 5 15


# Does the script exist? If not, then exit immediatelly. In this case the
# Debian smartmontools package is not installed.
which update-smart-drivedb >/dev/null || exit 0


origscript=$(which update-smart-drivedb)
version=$(sed -n 's/^VERSION="\(.*\)"$/\1/p' ${origscript})


# Note, the script shipped with the Debian Wheezy smartmontools package
# contains a wrong URL. Because of that this must be modified to get the
# script working. To do not modify the original script, which is under
# APT control, we simply create a copy of the script, modify the URL and
# finally execute it.
cp -p ${origscript} ${tmpscript}
sed -i "/^SRCEXPR/{s#=.*#='https://sourceforge.net/p/smartmontools/code/HEAD/tree/\$location/smartmontools/drivedb.h?format=raw'#}" ${tmpscript}
echo "Updating smartmontools ${version} drive database ..."
eval ${tmpscript}


exit 0

I am no sed-Expert - but is it possible there is an issue because the script is trying to change the path again? May anyone help me please?

Is it possible this is a right problem? I had a look: the drivedb.h is root:root... Is it possible it is not accessible by anacron?

After many many testings I did a restart and the restart fixed it... Didn't know this windows approach also works on Linux

Zitat von Linkinsoldier

After many many testings I did a restart and the restart fixed it... Didn't know this windows approach also works on Linux

The number of times I've experienced this has lead me to always doing a reboot and testing before posting any questions. It usually has to do with a service not being restarted which I am unaware needed to be restarted, or depending on the problem just logging into a new session to refresh user permissions.