| 23 Mar 2025 |
 uep | random idle musing: what's the right way to express dependencies between services, that says service A needs to be running, but should also be restarted whenever service B starts or stops?
Use case:
- Service A: smartd, which either doesn't notice new disks arriving, or gets very upsetti when they go offline
- Service B: something that's going to power on/off and zpool import an external chassis with 36 disks in a backup pool, to be triggered by other conditions
| 23:50:32 |
| uep | * random idle musing: what's the right way to express dependencies between services, that says service A needs to be running, but should also be restarted whenever service B starts or stops?
Use case:
- Service A: smartd, which either doesn't notice new disks arriving, or gets very upsetti when they go offline
- Service B: something that's going to power on/off and zpool import an external chassis with 36 disks in a backup pool, to be triggered by other conditions
| 23:50:39 |
| uep | (B might get split into separate power state and import state units, but that's not really important for this question. I want to restart smartd around the disks either arriving or leaving | 23:52:17 |
| uep | * (B might get split into separate power state and import state units, but that's not really important for this question. I want to restart smartd around the disks either arriving or leaving) | 23:52:21 |
 @elvishjerricco:matrix.org | uep: I wonder if that's more of a job for udev | 23:54:36 |
| @elvishjerricco:matrix.org | * uep: I wonder if that's more of a job for udev rules | 23:54:49 |
| uep | maybe | 23:54:51 |
| uep | it might also just be better smartd configuration | 23:55:00 |
| uep | but that's a question for somewhere else, so I asked this one here ;-) | 23:55:29 |
| @elvishjerricco:matrix.org | there's StopPropagatedFrom= / PropagatesStopTo= to propagate stops from one unit to another | 23:56:42 |
| @elvishjerricco:matrix.org | but that's not a restart | 23:56:46 |
| uep | (my initial guess about udev rules was that it might be hard to avoid restarting smartd 36 times) | 23:58:17 |
| @elvishjerricco:matrix.org | yea you'd have to use the right udev rule. | 23:58:41 |
| @elvishjerricco:matrix.org | either something that can detect the completed state | 23:58:49 |
| @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 |
