raingl...@riseup.net writes: > Would others find this useful? Where in the stack would this be solved? > Could we, for example, catch an issue in the init system and still > perform a rollback? Or if not a full rollback, then at least a reboot > into the previous config? (And if that is also broken, then the one > before, etc, etc) > > Obviously there are a lot of edge cases and potential bugs in this > mechanism as well. Sticking with the SSH example, rolling back to a > version that was kept around where the authorized keys are different > would also make the machine unreachable via SSH.
I would definitely find this useful, particularly when combined with unattended-upgrade-service. I don't know the best way to handle an init system failure. Perhaps a starting point would be a one-shot conditional-rollback-service with a "shepherd-requirements" field and a "test" field that takes an file-like object. This service would execute that file, write the output to some log file, and trigger a rollback if an error is signaled. Presumably this service should only trigger on boot, not reconfigure so we don't risk running the test with old services. I don't believe Guix has a mechanism yet to say "Yes, this service is new, and I /do/ want Shepherd to auto-start it, but not on reconfigure". This shouldn't be too hard to add though. -- Take it easy, Richard Sent Making my computer weirder one commit at a time.
