| 23 Mar 2025 |
@elvishjerricco:matrix.org | or starting a systemd timer that waits an appropriate amount of time | 23:58:59 |
| 24 Mar 2025 |
uep | it might end up being timers anyway, because i don't want it to try counting to 36 and then only 35 disks appear one day | 00:00:13 |
@elvishjerricco:matrix.org | yea you'd really want to detect at the chassis level "all disks inside are powered up", not "36 disks are powered up" | 00:00:46 |
@elvishjerricco:matrix.org | that may or may not be possible | 00:00:59 |
@elvishjerricco:matrix.org | oh but you could combine this with Upholds | 00:01:11 |
uep | (same problem with just picking one particular disk as the trigger, but i could possibly trigger on the controller / sas expander / chassis ses device or something like that) | 00:01:21 |
@elvishjerricco:matrix.org | hm but you still have to deal with restarting when the other unit is started | 00:01:30 |
@elvishjerricco:matrix.org | yea, I'm thinking that you will either need to learn how to identify the state of the chassis as a whole, or otherwise just start a systemd timer to restart the service whenever any of the disks appears or disappears | 00:02:31 |
uep | at least then it's a different transaction | 00:03:06 |
@elvishjerricco:matrix.org | the nice thing about a timer is that starting it 36 times will still only cause it to elapse once | 00:03:32 |
@elvishjerricco:matrix.org | assuming the timer length is longer than the time it takes for 36 drives to come onlnie | 00:03:46 |
@elvishjerricco:matrix.org | * assuming the timer length is longer than the time it takes for 36 drives to come online | 00:03:48 |
uep | thanks.. this was roughly where I was expecting to go anyway, it's nice to have validation and that there wasn't something i was missing as a better way | 00:04:09 |
uep | on the way up is easy enough, i also have the pool import to tell me that "enough" disks are there | 00:04:45 |
uep | on the way down it's a little more fragile if i want to avoid all the spurious alarms.. i probably need to stop smartd, then power off the chassis, then start smartd | 00:05:40 |
@elvishjerricco:matrix.org | frankly I'm surprised smartd doesn't just handle disks appearing and disappearing gracefully though | 00:05:50 |
@elvishjerricco:matrix.org | like that seems like basic functionality to me | 00:06:00 |
uep | or go figure out if smartd has something to note disks as removable | 00:06:07 |
uep | yeah, it probably does, but isn't the default (except maybe for usb?) because telling you when disks go offline is it's job | 00:07:08 |
uep | i haven't gone looking at that yet | 00:07:20 |
uep | (and i also need it to keep state by wwn rather than by probe order /dev/sdak etc | 00:08:54 |
uep | * (and i also need it to keep state by wwn rather than by probe order /dev/sdak etc) | 00:09:07 |
antifuchs | oh lol, I have a little generator program for smartctl scan cron tasks, if you're interested | 00:15:16 |
antifuchs | (makes one per disk; it's not smart [ha ha] enough to not make one for a connected usb drive, but it does the job | 00:15:42 |
antifuchs | * oh lol, I have a little generator program for smartctl scan systemd timer tasks, if you're interested | 00:16:01 |
uep | to trigger selftests? | 00:19:27 |
uep | hm, there is -d removable but this seems to deal with it not being present on startup, doesn't mention anything about when it's removed..
removable - the device or its media is removable. This indicates to smartd that it should continue (instead of exiting, which is the default behavior) if the device does not appear to be present when smartd is started. This Directive may be used in conjunction with the other '-d' Directives.
| 00:28:14 |
uep | (it also looks like sending a SIGHUP might be enough rather than a restart, which seems nicer | 00:30:04 |
antifuchs | yup, I have one that triggers long and one that triggers short selftests every few weeks | 00:34:36 |
antifuchs | smartd could be smart enough to do what I want, but I don't wanna run smartd (: | 00:35:14 |