On 10/23/2017 04:10 AM, John Hughes wrote:
On 21/10/17 01:53, Patrick Meade wrote:
That text is not from the Debian changelog, but rather from debian/NEWS.
Ah, didn't notice that. Always trust the code before the doc.
Still don't understand why it says "in favour of systemd's ... commands"
when the patch does no such thing.
The only way I can understand it is as a poorly phrased way of saying
"we're dropping this feature, systemd users could do something to work
around that". I guess he could have added suggestions for sysvinit and
upstart users as well. But in no way does this patch somehow remove
sysvinit support for redis in Debian.
The GitHub commit is here:
https://github.com/lamby/pkg-redis/commit/6a9e4d0142b45195a0d55945bbc558df4c48707b#diff-e2b5949461a30128734d213f0ead1565
I must admit that I'm still learning the ropes with respect to Debian
packaging. Could you explain this diff of debian/redis-server.init to me?
What's to explain? It "drops the Debian-specific support for the
/etc/redis/redis-{server}.sentinel.{pre,post}-{up,down}.d directories"
by removing the calls to run-parts.
------
tl;dr:
- Neither redis-server 3.2.6 nor redis-server 4.0.2 provide the upstream
sysvinit examples
- redis-server 4.0.2 still has support for sysvinit commands in
etc/init.d/redis-server
- redis-server 4.0.2 removes the pre/post up/down hooks for sysvinit
- hopefully, we can ask Debian maintainer to revert, if not, we have
work ahead
------
Okay, I got a chance to dig into redis-server a little bit this morning.
I unpacked the stretch version of the package (3.2.6), and the
buster/sid version of the package (4.0.2):
http://http.us.debian.org/debian/pool/main/r/redis/redis-server_3.2.6-1_amd64.deb
http://http.us.debian.org/debian/pool/main/r/redis/redis-server_4.0.2-3_amd64.deb
ar x package.deb
tar xvf data.tar.xz
fgrep -R "init.d" *
I then looked into the files identified by the fgrep command.
redis-server 3.2.6 reports:
etc/init.d/redis-server: echo "Usage: /etc/init.d/$NAME
{start|stop|restart|force-reload|status}" >&2
etc/redis/redis-server.post-up.d/00_example:# "/etc/init.d/redis-server
start" does not result in unintended consequences.
etc/redis/redis-server.pre-up.d/00_example:# "/etc/init.d/redis-server
start" does not result in unintended consequences.
etc/redis/redis-server.post-down.d/00_example:#
"/etc/init.d/redis-server start" does not result in unintended consequences.
etc/redis/redis-server.pre-down.d/00_example:# "/etc/init.d/redis-server
start" does not result in unintended consequences.
redis-server 4.0.2 reports:
etc/init.d/redis-server: echo "Usage: /etc/init.d/$NAME
{start|stop|restart|force-reload|status}" >&2
I checked etc/init.d/redis-server against the upstream sysvinit examples:
https://github.com/antirez/redis/blob/unstable/utils/redis_init_script
https://github.com/antirez/redis/blob/unstable/utils/redis_init_script.tpl
The file provided upstream is an example script to start/stop in the
sysvinit style. In Debian, this file is neither included nor used.
Debian has its own custom script that relies on /sbin/start-stop-daemon
to manage daemon state.
The next task was to figure out what the changes to
etc/init.d/redis-server were doing. The Run_parts function and calls to
it are removed from the Debian script. This means the pre/post up/down
hook calls are removed when the daemon changes state.
The other files etc/redis/redis-server.{NEW_STATE}.d/00_example are just
empty stubs that give advice on how hook scripts should be written.
redis-server 4.0.2 removes these, because the pre/post up/down hooks are
removed, so the examples would advertise functionality that doesn't
exist any more.
Final takeaways:
- redis-server 4.0.2 still works with sysvinit; you can start/stop the
redis service per normal with the script that still exists in 4.0.2
- redis-server 4.0.2 did NOT remove upstream redis sysvinit scripts.
Upstream DOES provide an example script, but Debian DOES NOT include or
use that script. Debian has its own script.
- redis-server 4.0.2 support for sysvinit is LESS FUNCTIONAL than
redis-server 3.2.6; in particular, with 3.2.6, you can write pre/post
up/down hook scripts that get called by the sysvinit system. In 4.0.2
these scripts (if present) would be non-functional in the sysvinit system.
- The text from debian/NEWS, amended by the Debian maintainer in a later
commit, reads:
This version drops the Debian-specific support for the
/etc/redis/redis-{server,sentinel}.{pre,post}-{up,down}.d directories in
favour of using systemd's ExecStartPre, ExecStartPost, ExecStopPre,
ExecStopPost commands.
The meaning of this is: "We're dropping calls to the sysvinit hook
scripts. systemd already runs hook scripts via ExecStartPre,
ExecStartPost, ExecStopPre, ExecStopPost".
As John Hughes said, this isn't quite as bad as we originally thought.
We can still run redis-server with the Debian provided sysvinit script,
and Debian isn't throwing away upstream files for no reason.
However, it's not all sunshine and flowers either. The daemon state
change hooks are removed in the latest Debian package. If someone had a
script that pre-loaded data into the redis cache on daemon start, or
fired off a backup of the persistent store on daemon stop, these scripts
would no longer be called when redis goes up/down.
If someone's scripts stopped working, and they asked for support, the
likely answer would be "Add a ExecStopPost line to your unit file that
calls your script." Which is OK, if they are running systemd, but not so
great if they aren't running systemd.
At this point, we can ask the Debian maintainer Chris Lamb (@lamby)
politely to revert the commit, creating a 4.0.2-4 that brings back the
sysvinit hooks. [In my opinion, this would be the best of all worlds.]
If Chris Lamb refuses, we'll have to explore some other options:
1. Accept the Debian change and drop the functionality for sysvinit
hooks in redis. [In my opinion, the worst of all worlds.]
2. Add a new Devuan package redis-sysvinit-hooks that provides the 3.2.6
script and restores the old hook script directories. [In my opinion, the
least work to get the functionality we want, and probably our best
option if Chris Lamb refuses.]
3. Repackage redis for Devuan and track both upstream and Debian. [In my
opinion, this would work, but also is a lot of future work that would
deplete development resources that Devuan needs for other things.]
Patrick
_______________________________________________
Dng mailing list
[email protected]
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
