On Wed, Feb 25, 2026 at 10:18:30AM +0100, lorenzo wrote: > On Mon, 23 Feb 2026 19:06:56 +0000 > Andrew Bower <[email protected]> wrote: > > > > minetest-server@percyworld2 and minetest-server@scaredlands have a > > > .meta/bin file inside their service directories (are they shipped > > > with a deb package?) but there is no .meta/bin file in > > > minetest-server@thedeeps: correct? > > > > You are right! > > > > Sorry, I should have run 'tree -a'. These files must have been left > > from an early experiment in supporting template services at the > > package level, before you added similar features for real - they > > aren't supposed to be there now! > > > > Thanks. > > > > RESOLVED INVALID. > > In fact I think this could be valid: the user does 'sv d foo', > then the trigger (upgrade loop) runs and brings 'foo' up with a > restart.. > for comparison, I tested what happens with a sysvinit script and it > does the same thing: > > # touch /etc/runit/override-sysv.d/cron.sysv > # update-service --remove cron > # # /etc/init.d/cron status > cron is not running ... failed! > # apt-get --reinstall install cron > [...] > Unpacking cron (3.0pl1-206) over (3.0pl1-206) ... > Setting up cron (3.0pl1-206) ... > runit override: cron: forwarding action restart to sysv via invoke-rc.d > Restarting periodic command scheduler: cronStopping periodic command > scheduler: cron. > Starting periodic command scheduler: cron. > [...] > # /etc/init.d/cron status > cron is running. > > I'm happy that you closed, I would have wontfixed otherwise because > there is no easy way to check if service is running or not - ideally we > should restart only if is 'foo' is up, regardless of the wanted status - > but there is no easy way to do that - 'sv check' test that foo is in the > wanted status, it can be 'down' and I don't want to grep 'sv s foo' in > the upgrade loop. > But if we get support upstream then I would be happy to fix > this (I think we need something like 'sv check up foo' --> check that > foo is up, regardless of the 'wanted' status)
Doesn't that mean undoing your recent change that did the opposite? I must admit I was never 100% confident about that! What will be the difference with 'status' - a wait loop calling the check script? > that said, may I ask why you use a down file instead of just disabling > the service? Currently these are standalone service directories but when I first created them they were instances of a template involving symlink to run file in template directory. I suppose it seemed less fragile to mark down than use my version of update-service that handled the templating. This is moot now because I removed all that magic. I suppose the documentation needs to make it clear to the user what the use case is for 'down' files, if it doesn't already.
