I did not actively follow the recent evolution of s6, and have just been bitten badly by s6 2.10.x on my Alpine servers (where slew [1] is used of course) when it comes along with other updates.
Sorry. This bears repeating: major version upgrades may break things. Compatibility is a good thing, that's why I try to keep major version changes few and far between; but the other side of the coin is that when I'm doing one, I want to make use of it and cram all the incompatible changes that may be needed in the foreseeable future. So, you have to pay attention less often, but when it happens, you do have to pay attention. Previous major version changes may have gone smoothly - I try to keep it as smooth as possible when there's no need to break UX - but it's no guarantee that it will always be smooth sailing. This time, there were very visible user changes; sorry for the inconvenience, but I reserve the right to do this, and I try to document the breaking changes in the release notes. It is, admittedly, a drawback of distributions that they make major version upgrades very silent - so, if you have local software that relies on an old API, and the distro updates it under your feet, you're caught unaware. I don't have a satisfying solution to this; maybe I should have added a post-upgrade file printing red blinking bold text, but that doesn't address automated or afk updates.
better if we kept the option supported for a transition period, and that only removed it from the manual pages while urging users to get rid of it. After all, in this case, silently ignoring `-s' is behaviourly similar to (if not perfectly compatible with) old `s6-svscan'.
It's always a delicate balance, because "better" is not one-dimensional.
It would be better UX, yes, definitely. But also legacy code to maintain until the next major update (which can take a while), and I tend to assign a *very* high cost to legacy code in s6-svscan and s6-supervise, for obvious reasons. And in my experience, few people (and you, Casper, certainly belong to them!) actually bother changing their scripts as long as they keep working - most only spring into action when something breaks. A compromise I've found relatively efficient was to add nagging warnings on deprecated option use, but 1. that's even more code that will be removed, and 2. I hate nagware, with a passion, in all its forms. There is no really good solution, and I prefer a short, sharp pain (when things break) followed by relief (when they're fixed) to a long dull ache (maintaining compat code). Especially when I'm not the one experiencing the sharp pain ;)
Second, `s6-svscan' now waits for its `s6-supervise' children to exit before exec()ing `.s6-svscan/finish'
You seem to have found the proper way of managing this with SIG files, but just in case: "s6-svscanctl -tb" will net you the old behaviour. -- Laurent
