* Vahis [2014-10-08 11:24]:

On 08.10.2014 11:50, Guido Berhoerster wrote:

...

I have smartd configured to execute a script that creates a warning message via wall(1) and I think that's a pretty robust solution. It will generate a message on every console a user is logged in (in case he isn't using X), on every terminal emulator, and a desktop notification via kwrited on KDE or xwrited on Xfce/GNOME/LXDE.

Sounds like exactly what I would like to have, too :)

You don't happen to have dummie's instructions somewhere, do you?

Well, it's rather simple. Put the following line in /etc/smartd.conf: DEVICESCAN -d removable -m <nomailer> -M exec /usr/local/lib/smartd_wall.sh Then create /usr/local/lib/smartd_wall.sh and make it executable: ----8<---- #!/bin/sh export PATH=/bin:/sbin:/usr/bin:/usr/sbin printf "%s\n" "${SMARTD_MESSAGE}" | wall -n ---->8---- If you're running KDE that's all you have to do, otherwise you need to download and install https://hg.guido-berhoerster.org/projects/xwrited/archive/tip.tar.bz2 or wait until I package it in home:gberh/xwrited later. -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Wed, Oct 8, 2014 at 6:24 AM, Vahis wrote:

On 08.10.2014 11:50, Guido Berhoerster wrote:

...

I have smartd configured to execute a script that creates a warning message via wall(1) and I think that's a pretty robust solution. It will generate a message on every console a user is logged in (in case he isn't using X), on every terminal emulator, and a desktop notification via kwrited on KDE or xwrited on Xfce/GNOME/LXDE.

Sounds like exactly what I would like to have, too :)

You don't happen to have dummie's instructions somewhere, do you?

You can configure a mail script for smartd with -w path, and that can be useful. The default script at /etc/smartd_warning.sh also doesn't do much more than sending an email, it can be useful to extend it to also wall. I'd go for the second option (extending smartd_warning.sh) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

* Jan Engelhardt [2014-10-08 11:37]:

On Wednesday 2014-10-08 10:50, Guido Berhoerster wrote:

...

I have smartd configured to execute a script that creates a warning message via wall(1) [...] and a desktop notification via kwrited on KDE or xwrited on Xfce/GNOME/LXDE.

Hm, I am using notify-send (not for SMART, but something else), might be the more portable solution?

I don't think so, notify-send requires access to each user's session DBus instance and you have to resort to some pretty gross and fragile hack to do that. In addition you don't reach users which are just logged in on a console. -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

* Jan Engelhardt [2014-10-08 12:39]:

On Wednesday 2014-10-08 12:18, Guido Berhoerster wrote:

...

...

Hm, I am using notify-send (not for SMART, but something else), might be the more portable solution?

I don't think so, notify-send requires access to each user's session DBus instance and you have to resort to some pretty gross and fragile hack to do that. In addition you don't reach users which are just logged in on a console.

Shouldn't user sessions (ideally) also listen to the system bus to receive exactly this kind of user-unspecific system events?

Sure, bute then you need just another daemon which subscribes to certain DBus signals by an emitter on the system bus and in turn invokes a method on the users notification daemon via the session bus. That's how gnome-disk-utility works. Basically udisks2 regularly polls SMART data and emits a signal via the system bus to which gnome-disk-utility instances running in the users sessions are subscribed and in turn create notifications over the session bus. -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2014-10-08 10:54, Frederic Crozat wrote:

Le mercredi 08 octobre 2014 à 10:30 +0200, Ludwig Nussel a écrit :

...

Hi,

After struggling with my harddisk I noticed that we don't have smartd enabled by default. Shouldn't we change that to get hard disk monitoring by default on every installation? But then IIUC smartd only logs to syslog which a desktop user will never see. Are there any ways to notify deskop users in case of imminent trouble?

IF monitoring is enabled, the desktop user does get a notification on emergencies. I've seen it. Provoking a fake fault in order to see if the notification works I don't know how to do.

gnome-disks-utility (through udisks2) have SMART capabilities and have a monitor for SMART failure.

I don't know if KDE has similar integration for this udisks2 capability.

smartd is not on by default because supposedly dbus-daemon does it: /var/log/messages-20131104.xz:<3.6> 2013-11-04 01:00:07 Telcontar dbus-daemon 1460 - - helper(pid 11651): launched job udisks-helper-ata-smart-collect on /dev/sdd /var/log/messages-20131104.xz:<3.6> 2013-11-04 01:00:07 Telcontar dbus-daemon 1460 - - helper(pid 11653): launched job udisks-helper-ata-smart-collect on /dev/sde /var/log/messages-20131104.xz:<3.6> 2013-11-04 01:00:07 Telcontar dbus-daemon 1460 - - helper(pid 11654): launched job udisks-helper-ata-smart-collect on /dev/sdb /var/log/messages-20131104.xz:<3.6> 2013-11-04 01:00:07 Telcontar dbus-daemon 1460 - - helper(pid 11655): launched job udisks-helper-ata-smart-collect on /dev/sdc /var/log/messages-20131104.xz:<3.6> 2013-11-04 01:30:07 Telcontar dbus-daemon 1460 - - **** Refreshing ATA SMART data for /sys/devices/pci0000:00/0000:00:1f.2/ata9/host8/target8:0:0/8:0:0:0/block/sdb /var/log/messages-20131104.xz:<3.6> 2013-11-04 01:30:07 Telcontar dbus-daemon 1460 - - helper(pid 14055): launched job udisks-helper-ata-smart-collect on /dev/sdb /var/log/messages-20131104.xz:<3.6> 2013-11-04 01:30:07 Telcontar dbus-daemon 1460 - - **** Refreshing ATA SMART data for /sys/devices/pci0000:00/0000:00:1f.2/ata10/host9/target9:0:1/9:0:1:0/block/sde /var/log/messages-20131104.xz:<3.6> 2013-11-04 01:30:07 Telcontar dbus-daemon 1460 - - helper(pid 14056): launched job udisks-helper-ata-smart-collect on /dev/sde /var/log/messages-20131104.xz:<3.6> 2013-11-04 01:30:07 Telcontar dbus-daemon 1460 - - **** Refreshing ATA SMART data for /sys/devices/pci0000:00/0000:00:1f.2/ata10/host9/target9:0:0/9:0:0:0/block/sdd /var/log/messages-20131104.xz:<3.6> 2013-11-04 01:30:07 Telcontar dbus-daemon 1460 - - helper(pid 14057): launched job udisks-helper-ata-smart-collect on /dev/sdd Although the messages are not supposed to be read by a human reading syslog. For that, the smard daemon is far better. And it emails you. Maybe dbus triggers the desktop notification :-? The messages stopped on 2014-08-09. I don't know why. zgrep -i smart /var/log/messages*xz | grep dbus-daemon | less -S Last entries: /var/log/messages-20140907.xz:<3.6> 2014-08-09 17:45:03 Telcontar dbus-daemon 1041 - - helper(pid 25517): launched job udisks-helper-ata-smart-collect on /dev/sdf /var/log/messages-20140907.xz:<3.6> 2014-08-09 17:45:03 Telcontar dbus-daemon 1041 - - **** Refreshing ATA SMART data for /sys/devices/pci0000:00/0000:00:1c.3/0000:05:00.0/ata3/host2/target2:0:0/2:0:0:0/block/sdb /var/log/messages-20140907.xz:<3.6> 2014-08-09 17:45:03 Telcontar dbus-daemon 1041 - - helper(pid 25518): launched job udisks-helper-ata-smart-collect on /dev/sdb Now empty: Telcontar:~ # grep -i smart /var/log/messages | grep dbus-daemon Telcontar:~ # Telcontar:~ # locate udisks-helper-ata-smart-collect /other/test_a1/usr/lib/udisks/udisks-helper-ata-smart-collect /usr/lib/udisks/udisks-helper-ata-smart-collect Telcontar:~ # It's a binary, so I don't know what it is supposed to do really. HTH. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlQ1E8UACgkQtTMYHG2NR9WjegCbBAmo7QBa4Uem2lvvuxPcZE5D Jt8An34NBM54TcvWfRYtjxwIM5S9ulCD =BQ0G -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2014-10-08 12:59, Guido Berhoerster wrote:

* Carlos E. R. <> [2014-10-08 12:37]:

...

smartd is not on by default because supposedly dbus-daemon does it:

No, that is not how it works. udisks2 has nothing to do with smartd, it has its own helper binary which reads SMART attributes,

I know that.

that is /usr/lib/udisks/udisks-helper-ata-smart-collect, and it doesn't log anything by default AFAIK. Rather it can signal warnings to desktop clients like gnome-disk-utility which in turn can create a notification for the user.

It did generate a lot of entries in the log, till recently (I don't know why they stopped). And yes, someone told me that smartd was no longer needed, when I asked about it. That dbus/udisks did a better job. I did see the desktop notification once or twice. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlQ1JeIACgkQtTMYHG2NR9VxqACeJTqHbZa5fyMZso0zLvZnIXfk sg0AnjqBugzPBprygem3nl29KiHwGRYH =mQXA -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On October 8, 2014 6:36:55 AM EDT, "Carlos E. R." wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 2014-10-08 10:54, Frederic Crozat wrote:

...

Le mercredi 08 octobre 2014 à 10:30 +0200, Ludwig Nussel a écrit :

...

Hi,

After struggling with my harddisk I noticed that we don't have smartd enabled by default. Shouldn't we change that to get hard disk monitoring by default on every installation? But then IIUC smartd only logs to syslog which a desktop user will never see. Are there any ways to notify deskop users in case of imminent trouble?

IF monitoring is enabled, the desktop user does get a notification on emergencies. I've seen it. Provoking a fake fault in order to see if the notification works I don't know how to do.

Create a trash file with a small amount of data in it. Figure out which physical sectors the data lives on. Flush the disk cache. (Drop cache) Use "hdparm --make-bad-sector" to temporarily trash one of those sectors. It will force an internal disk crc failure for the sector. (Hdparm does direct i/o and will bypass the kernel cache.) Then access the file (cp trash1 trash2). You should get an I/O error on the cp. When you're done "hdparm --repair-sector" should undo the damage. Greg -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Wed, Oct 8, 2014 at 7:35 AM, Carlos E. R. wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 2014-10-08 13:29, Greg Freemyer wrote:

...

On October 8, 2014 6:36:55 AM EDT, "Carlos E. R." <> wrote:

...

...

Provoking a fake fault in order to see if the notification works I don't know how to do.

Create a trash file with a small amount of data in it.

Figure out which physical sectors the data lives on.

Flush the disk cache. (Drop cache)

Use "hdparm --make-bad-sector" to temporarily trash one of those sectors. It will force an internal disk crc failure for the sector. (Hdparm does direct i/o and will bypass the kernel cache.)

Then access the file (cp trash1 trash2).

You should get an I/O error on the cp.

When you're done "hdparm --repair-sector" should undo the damage.

My hair is standing up in my back... yiks!

:-)

I left out a key step I use: Find a SATA HDD with no content on it you care about and connect it to your system via sata and put a nice new filesystem on it. (I don't know if the above works for USB3 connected drives. I have never tried that.) You may also need to experiment with the 4K physical sectors vs. 512 byte logical sectors. All my testing has been with older 512 byte physical sector drives. Greg -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Wed, Oct 8, 2014 at 10:04 AM, Carlos E. R. wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 2014-10-08 15:21, Greg Freemyer wrote:

...

On Wed, Oct 8, 2014 at 7:35 AM, Carlos E. R. <> wrote:

...

...

My hair is standing up in my back... yiks!

:-)

I left out a key step I use: Find a SATA HDD with no content on it you care about and connect it to your system via sata and put a nice new filesystem on it.

Ah, yes.

...

(I don't know if the above works for USB3 connected drives. I have never tried that.)

Maybe. Depends on the particular chipset of the hd box.

...

You may also need to experiment with the 4K physical sectors vs. 512 byte logical sectors. All my testing has been with older 512 byte physical sector drives.

Right.

Also, use ext3, not xfs: it is difficult to find the lba; far from trivial.

My testing has actually been with raw unformated disks. Fill with random data: dd if=/dev/urandom of=/dev/sdx bs=4K use hdparm to corrupt a sector (or more) Use various raw sector level read tools to attempt to read the sector. Verify dd terminates when it hits the bad sector. What about "dd conv=noerror". Compare that to "dd conv=noerror,sync". What about shred /dev/sdx. Does it terminate on the bad sector? etc, etc, etc. I have run large numbers of similar tests over the last 10 years. Greg -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Wednesday 2014-10-08 16:04, Carlos E. R. wrote:

...

You may also need to experiment with the 4K physical sectors vs. 512 byte logical sectors. All my testing has been with older 512 byte physical sector drives.

Right.

Also, use ext3, not xfs: it is difficult to find the lba; far from trivial.

How so? The inode number multiplied by the inode size generally yields the LBA where the inode lives. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Wednesday 2014-10-08 19:45, Carlos E. R. wrote:

...

...

...

You may also need to experiment with the 4K physical sectors vs. 512 byte logical sectors. All my testing has been with older 512 byte physical sector drives.

Right.

Also, use ext3, not xfs: it is difficult to find the lba; far from trivial.

How so? The inode number multiplied by the inode size generally yields the LBA where the inode lives.

My memory is fuzzy on this, but I think there is a thread on the xfs mail list asking about how to map sectors to files, nobody knows.

And this is supposed to be easier on ext3? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Wednesday 2014-10-08 22:08, Stefan Seyfried wrote:

Am 08.10.2014 um 20:19 schrieb Jan Engelhardt:

...

On Wednesday 2014-10-08 19:45, Carlos E. R. wrote:

...

My memory is fuzzy on this, but I think there is a thread on the xfs mail list asking about how to map sectors to files, nobody knows.

And this is supposed to be easier on ext3?

Yes, see http://smartmontools.sourceforge.net/badblockhowto.html (I don't know if it is hard on xfs, but it is easy on ext{23}

For XFS, there is xfs_ncheck, which is a bit more direct than ext's debugfs. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2014-10-09 00:49, Carlos E. R. wrote:

Well, it is at least documented, by the smartd people, in this precise scenario :-)

Oh, sorry, confusion: The hard part is locating which file is on a known (lba) sector. It is much easier to locate on which sector lies a known file - obviously, as the kernel needs that knowledge and fast, in order to read any file. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlQ1xxEACgkQtTMYHG2NR9WqNQCdF+siy/HSGUS7O2v40R78i5SI KosAnj0Wi/lCj4bMU6ttYw63IYjE9a4N =RrNO -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Wednesday, October 08, 2014 02:51:30 PM Cristian Rodríguez wrote:

El 08/10/14 a las #4, Ludwig Nussel escribió:

...

Hi,

After struggling with my harddisk I noticed that we don't have smartd enabled by default. Shouldn't we change that to get hard disk monitoring by default on every installation? But then IIUC smartd only logs to syslog which a desktop user will never see. Are there any ways to notify deskop users in case of imminent trouble?

cu Ludwig

Hrmmm.. I thought all major desktop environments reported smart failure if udisks tells so..I do not think we should enable smartd by default but make the notification work if it does not.

What happens if nobody is logged in while the error occurs? Does udisk write a message to the syslog/journal? Should udisks or some watcher send an email to root@localhost or some other email address? Kind regards, Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen home: +49 241 53809034 mobile: +49 151 50412019 work: +49 2405 49936-424 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Cristian Rodríguez schrieb:

El 08/10/14 a las #4, Ludwig Nussel escribió:

...

After struggling with my harddisk I noticed that we don't have smartd enabled by default. Shouldn't we change that to get hard disk monitoring by default on every installation? But then IIUC smartd only logs to syslog which a desktop user will never see. Are there any ways to notify deskop users in case of imminent trouble?

Hrmmm.. I thought all major desktop environments reported smart failure if udisks tells so..I do not think we should enable smartd by default but make the notification work if it does not.

I wasn't aware of udisks taking care. If that is the case smartd doesn't make sense on default desktop installs of course. It would still be interesting to know which desktops support smart via udisks. Too bad qemu doesn't seem to have support for SMART so we can't use openqa to check. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org