Sorry for the confusion, I'll try to make it more clear.
In my first message I was proposing to change the behavior of
"invoke-rc.d restart" to do "stop" for floating services as a short term
(and not ideal) solution to the question of how to manage a service
manually, and because it seems more se
> > For packages with maintainer scripts that do "invoke-rc.d restart" or
> > equivalent, the multiuser runlevel directories must contain either an
> > S or a K symlink. This will remain true even when #243159 is
> > implemented.
>
> Must this be so? As long as the no-S-and-K-links situation is o
Thomas Hood <[EMAIL PROTECTED]> said:
> We are talking here, after all, about how invoke-rc.d handles an
> invalid setup.
Well, but making this invalid setup a "locally valid" one by defining
the most useful invoke-rc.d behavior for it is one of two ways to solve
the (otherwise still unsolvable, r
> Therefore, I vote for changing the behavior of invoke-rc.d from 1) to
> 2), until something like "try-restart" is implemented.
Perhaps it would be better, as you suggest, if we saw this in the
absence of S and K symlinks:
invoke-rc.d stop -> stop
invoke-rc.d start -> (nothing)
than th
Thomas mentioned three possible behaviors of invoke-rc.d in case of a
missing symlink, all of which are somehow bad: 1) starting a manually
stopped service on upgrade, 2) stopping a manually started service on
upgrade, and 3) not restarting a manually started service on upgrade.
Option 3) may be a
5 matches
Mail list logo
