Re: [DNG] Debian testing drop redis non systemd

[John Hughes]

On 26/10/17 15:55, John Hughes wrote:



They are around 89 lines long.  Hardly broken compared to most init 
scripts, check out /etc/init.d/sendmail -- a 1321 line monster in some 
versions.



Duh, hardly "bloated" I meant to say.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Debian testing drop redis non systemd

[John Hughes]

On 25/10/17 19:51, Steve Litt wrote:


How bout this: Have a "runit-supervisor-only" pacakge that installs
runit but doesn't make it PID1. Have sysvinit run runit, and have runit
run redis, with all the correct config. The runit run script is
probably 1/10 the size of its bloatacious and apparently broken sysvinit
init script, so it's easy to correctly design the runit run script.
As far as I know there is nothing  broken about the redis init scripts 
in Debian.


They are around 89 lines long.  Hardly broken compared to most init 
scripts, check out /etc/init.d/sendmail -- a 1321 line monster in some 
versions.


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Debian testing drop redis non systemd

[Steve Litt]

On Tue, 24 Oct 2017 07:44:51 -0500
Patrick Meade  wrote:


> However, if they are on Devuan, there is no systemd. And without 
> restoring the old functionality or providing new functionality, our 
> answer will be an empty one: "Debian upstream broke it. Sorry." And
> our poor system administrator goes away empty handed, and maybe
> starts looking for a new distro.

How bout this: Have a "runit-supervisor-only" pacakge that installs
runit but doesn't make it PID1. Have sysvinit run runit, and have runit
run redis, with all the correct config. The runit run script is
probably 1/10 the size of its bloatacious and apparently broken sysvinit
init script, so it's easy to correctly design the runit run script.

This could also be done with daemontools-encore, if there's a good
package for it (Debian's package for just plain daemontools really
sucked, last time I looked).
 
SteveT

Steve Litt 
October 2017 featured book: Rapid Learning for the 21st Century
http://www.troubleshooters.com/rl21
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Debian testing drop redis non systemd [update]

[Bardot Jérôme]

This is what the debian maintainer wrote to me about redis.

(i ask if i miss understood the patch loq )

> Maybe i miss understood the message ?

You did. As the changelog entry mentions, it's only the Debian-
specific (eg.) /etc/redis/redis-server.pre-up.d support that have
been removed... and they were removed from both SysV and the systemd
"variants".



0x03878A98.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Debian testing drop redis non systemd

[John Hughes]

On 24/10/17 14:44, Patrick Meade wrote:


Only the first option is acceptable to me, so what needs to be done is 
also clear to me. I'm hoping that the Debian maintainer will be 
willing to revert this change, as that would be the easiest way for 
everybody to win. If not, well... there is some work ahead.



Perfectly reasonable.

It seems the obvious way forward is for a redis user who uses this 
feature to make a bug report.


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Debian testing drop redis non systemd

[Patrick Meade]

On 10/23/2017 09:19 AM, John Hughes wrote:

On 23/10/17 15:59, Patrick Meade wrote:
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.


Also note that the upstream init script example doesn't support the 
Debian hook scripts.  Perhaps upstream don't think that's useful 
functionality?


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.


Given that there is no documentation for these scripts other than the 
Debian changelog is anyone using them?


These are two good questions, but unfortunately it seems run-parts is a 
common idiom in Debian that dates back to 1994. Even if the redis 
feature was not well documented, it is not unrealistic to think that a 
system administrator could have gone to /etc/redis, saw the directories, 
and understood by the name of the directory what kind of script goes 
there, and what it would do.


So we have two groups of systems here.

Group A: Systems that never used the init script hooks in redis.

Group B: Systems that made use of the init script hooks in redis.

Group A pretty obviously doesn't give a rip either way. They never used 
the functionality, so they don't miss it now that it's gone. If we bring 
it back, they almost certainly won't care that it came back. If we leave 
it gone, they almost certainly won't care that it's still gone. Any 
action on our part neither helps nor harms the Group A folks. So, we set 
them aside.


The Group B folks will notice their system break once they upgrade. If 
we bring the functionality back, they will be happy that their system 
still works (sunny day). If we leave it gone, they will be unhappy that 
their system is broken (rainy day). The sunny day case requires nothing 
further, so we set it aside.


The rainy day case has two possible paths; try to fix the system or let 
it stay broken. The path chosen by the user will depend on their goals. 
The case where they let it stay broken requires nothing further, so we 
set it aside. The case where they try to fix it gets interesting.


If they are on Debian proper, the advice given will likely to be update 
the systemd unit to point to their scripts. systemd will run their 
scripts and they will be happy again. Since this case requires nothing 
further, we set it aside.


However, if they are on Devuan, there is no systemd. And without 
restoring the old functionality or providing new functionality, our 
answer will be an empty one: "Debian upstream broke it. Sorry." And our 
poor system administrator goes away empty handed, and maybe starts 
looking for a new distro.


Finally then, on the only path where our actions actually matter, we 
have two choices:


1. Restore the functionality, so that everybody including Devuan users, win.

2. Neglect the functionality, and let everybody except Devuan users, win.

Only the first option is acceptable to me, so what needs to be done is 
also clear to me. I'm hoping that the Debian maintainer will be willing 
to revert this change, as that would be the easiest way for everybody to 
win. If not, well... there is some work ahead.


Patrick
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Debian testing drop redis non systemd

[John Hughes]

On 23/10/17 15:59, Patrick Meade wrote:



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.


Also note that the upstream init script example doesn't support the 
Debian hook scripts.  Perhaps upstream don't think that's useful 
functionality?




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.


Given that there is no documentation for these scripts other than the 
Debian changelog is anyone using them?


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Debian testing drop redis non systemd

[Patrick Meade]

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 

Re: [DNG] Debian testing drop redis non systemd

[John Hughes]

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.


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Debian testing drop redis non systemd

[John Hughes]

On 22/10/17 11:37, Jaromil wrote:

Thanks everyone for adding details,

On Fri, 20 Oct 2017, Patrick Meade wrote:


https://github.com/lamby/pkg-redis/commit/6a9e4d0142b45195a0d55945bbc558df4c48707b#diff-9e388da7cd119765989cc22d2bc07e5c

This diff clearly shows that redis-sentinel example scripts provided
by upstream redis developers for compatibility with sysvinit are being
*deleted* from the package, de facto removing even the documentation
on how to start/stop from init.d despite it being just an example.

The scripts that are removed:


+rm_conffile /etc/redis/redis-sentinel.pre-up.d/00_example 4:4.0.2-3~

+rm_conffile /etc/redis/redis-sentinel.pre-down.d/00_example 4:4.0.2-3~

+rm_conffile /etc/redis/redis-sentinel.post-up.d/00_example 4:4.0.2-3~

+rm_conffile /etc/redis/redis-sentinel.post-down.d/00_example 4:4.0.2-3~


Do not exist in the upstream distribution of redis, *which does not 
include sysvinit scripts*.


They were added by the Debian redis developers as part of a poorly 
documented feature (only mentioned in the changelog!) which only exists 
on Debian.


Debian still include sysvinit scripts for redis, which provide as much 
functionality as sysvinit can give.  (The systemd service files allow 
running multiple copies of redis.  The Debian provided sysvinit scripts 
never allowed this, the only way of doing it would be for the user to 
write his own init scripts, which will be much easier to do without the 
{pre,post}-{up,down} complexity),


it is even worse than I initially thought.

No, it isn't.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Debian testing drop redis non systemd

[Jaromil]

Thanks everyone for adding details,

On Fri, 20 Oct 2017, Patrick Meade wrote:

> https://github.com/lamby/pkg-redis/commit/6a9e4d0142b45195a0d55945bbc558df4c48707b#diff-9e388da7cd119765989cc22d2bc07e5c

This diff clearly shows that redis-sentinel example scripts provided
by upstream redis developers for compatibility with sysvinit are being
*deleted* from the package, de facto removing even the documentation
on how to start/stop from init.d despite it being just an example.

it is even worse than I initially thought.

ciao



___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Debian testing drop redis non systemd

[Steve Litt]

On Thu, 19 Oct 2017 23:46:28 +0200
Adam Borowski  wrote:

> On Thu, Oct 19, 2017 at 10:22:33AM +0200, Jaromil wrote:
> > On Wed, 18 Oct 2017, Arnt Gulbrandsen wrote:
> >   
> > > Steve Litt writes:  
> > > > Does anyone here actually use redis? I looked it up, and to me
> > > > it looks like dbus on steroids. An in-memory data store
> > > > accessible by lots of different applications. What could
> > > > POSSIBLY go wrong?  
> > > 
> > > I've used in several contexts, it's great at its job and a joy to
> > > use.  
> > 
> > Same here, its a core part of many software projects, not only web
> > based but also on embedded systems and micro-service related.
> > 
> > One of its authors, antirez, is an old friend and coding made of
> > some of us here. Redis is heavily inspired by minimalism,
> > simplicity and UNIX principles since its inception. We will contact
> > upstream so they notice the fact the Debian maintainers are
> > removing a support which is provided upstream, since redis does
> > pack scripts for sysvinit that should be left in place.  
> 
> In that case, could you have someone from the upstream file a bug?
> If that support is provided, such a regression is not warranted --
> and a bug report from upstream carries a lot more weight than from a
> mere user.
> 
> > This episode is again of great shame on Debian maintainers, but it
> > should be addressed by upstream.  
> 
> Note that, while it might be tempting to "just fix it in Devuan",
> this would be a great duplication of effort.  A fix in Debian proper
> affects all derivatives, and thus applies to orders of magnitude more
> users than Devuan currently has.  It would also avoid forcing admins
> to use an inferior init/rc system.

Last I heard (which was about 2 years ago), Devuan's plan was to apply
changes to Debian distros for some time, but slowly migrate to a
completely different distro. If I remember correctly, one reason for
becomig independent was to avoid Debian sabotage like we're appearing
to see now on redis.

Devuan has no responsibility to Debian users. If Devuan and Debian can
cooperate, that's cool. But if Debian puts landmines in Devuan's path,
 em!

 
SteveT

Steve Litt 
October 2017 featured book: Rapid Learning for the 21st Century
http://www.troubleshooters.com/rl21
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Debian testing drop redis non systemd

[Patrick Meade]

On 10/20/2017 10:22 AM, John Hughes wrote:

On 20/10/17 16:37, Antony Stone wrote:
However, Bardot Jérôme's original posting in this thread, quoting 
Chris Lamb

 Wed, 11 Oct 2017 22:55:00 -0400 said:

"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."

So, yes, what's been dropped is Debian-specific, but shouldn't we 
still be

concerned about the "in favour of systemd's ... commands"?


That's not what the Debian changelog says:


That text is not from the Debian changelog, but rather from debian/NEWS.
The GitHub commit is here:

https://github.com/lamby/pkg-redis/commit/6a9e4d0142b45195a0d55945bbc558df4c48707b#diff-e2b5949461a30128734d213f0ead1565


In the buster/sid version (4:4.0.2-3) there is no code that I can find 
to run the {pre,post}-{up,down} scripts in sysvinit *or* systemd.


As version 4:4.0.2-3 is the version that "drops the Debian-specific 
support for the 
/etc/redis/redis-{server}.sentinel.{pre,post}-{up,down}.d directories", 
it would be rather surprising if you did find those scripts.


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?


https://github.com/lamby/pkg-redis/commit/6a9e4d0142b45195a0d55945bbc558df4c48707b#diff-9e388da7cd119765989cc22d2bc07e5c

Patrick
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Debian testing drop redis non systemd

[John Hughes]

On 20/10/17 16:37, Antony Stone wrote:

However, Bardot Jérôme's original posting in this thread, quoting Chris Lamb
 Wed, 11 Oct 2017 22:55:00 -0400 said:

"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."

So, yes, what's been dropped is Debian-specific, but shouldn't we still be
concerned about the "in favour of systemd's ... commands"?


That's not what the Debian changelog says:


redis (4:4.0.2-3) unstable; urgency=medium

   * Drop Debian-specific support for
 /etc/redis/redis-{server,sentinel}.{pre,post}-{up,down}.d and remove them
 if unchanged.
   * Include systemd redis-server@.service and redis-sentinel@.service template
 files to easily run multiple instances. (Closes: #877702)
   * Patch redis.conf and sentinel.conf with quilt instead of maintaining our
 own versions under debian/.
   * Refresh all patches.
   * Bump Standards-Version to 4.1.1.

  -- Chris Lamb   Thu, 12 Oct 2017 14:54:27 -0400


In the buster/sid version (4:4.0.2-3) there is no code that I can find 
to run the {pre,post}-{up,down} scripts in sysvinit *or* systemd.


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Debian testing drop redis non systemd

[John Hughes]

On 20/10/17 16:48, goli...@dyne.org wrote:

On 2017-10-20 09:27, John Hughes wrote:


My appologies for posting to a list from which I have been banned . . .



If you were 'banned' you would would not have been able to post. I 
just checked and your account has no restrictions on it.



Yup, I misrembered.  Sorry.

Also, appologies to golinux for replying off-list, cause by my lack of 
attention and Thunderbirds stupid defaults.


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Debian testing drop redis non systemd

[golinux]

On 2017-10-20 09:27, John Hughes wrote:


My appologies for posting to a list from which I have been banned . . .



If you were 'banned' you would would not have been able to post. I just 
checked and your account has no restrictions on it.


Wouldn't it be more to the point to find out *if* you were banned before 
declaring you were?


golinux
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Debian testing drop redis non systemd

[Antony Stone]

On Friday 20 October 2017 at 16:33:09, Adam Borowski wrote:

> On Fri, Oct 20, 2017 at 04:27:44PM +0200, John Hughes wrote:
> > Jaromil wrote:
> > > I would like to know here if anyone knows in detail the "reasons"
> > > Debian is removing the support for sysvinit scripts in the redis
> > > package.
> > 
> > Wouldn't it be more to the point to find out *if* Debian is removing the
> > support for sysvinit scripts in the redis package before trying to find
> > out why?
> > 
> > Because they aren't.
> 
> [...]
> 
> > The Debian supplied init scripts (debian/redis-server.init and
> > debian/redis-sentinel.init) still exist, they just no longer include the
> > (Debian specific) calls to "Run_parts".
> > 
> > These init scripts do not exist in the upstream redis distribution.  They
> > were added by Debian.
> > 
> > My apologies for posting to a list from which I have been banned, but I
> > thought it might be wise to have a little more light and a little less
> > heat.
> 
> Thanks for the correction -- that's always appreciated.

However, Bardot Jérôme's original posting in this thread, quoting Chris Lamb 
 Wed, 11 Oct 2017 22:55:00 -0400 said:

"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."

So, yes, what's been dropped is Debian-specific, but shouldn't we still be 
concerned about the "in favour of systemd's ... commands"?


Antony.

-- 
This email was created using 100% recycled electrons.

   Please reply to the list;
 please *don't* CC me.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Debian testing drop redis non systemd

[Adam Borowski]

On Fri, Oct 20, 2017 at 04:27:44PM +0200, John Hughes wrote:
> Jaromil wrote:
> > I would like to know here if anyone knows in detail the "reasons"
> > Debian is removing the support for sysvinit scripts in the redis
> > package.
> 
> Wouldn't it be more to the point to find out *if* Debian is removing the
> support for sysvinit scripts in the redis package before trying to find out
> why?
> 
> Because they aren't.
[...]
> The Debian supplied init scripts (debian/redis-server.init and
> debian/redis-sentinel.init) still exist, they just no longer include the
> (Debian specific) calls to "Run_parts".
> 
> These init scripts do not exist in the upstream redis distribution.  They
> were added by Debian.
> 
> My appologies for posting to a list from which I have been banned, but I
> thought it might be wise to have a little more light and a little less heat.

Thanks for the correction -- that's always appreciated.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ Laws we want back: Poland, Dz.U. 1921 nr.30 poz.177 (also Dz.U. 
⣾⠁⢰⠒⠀⣿⡁ 1920 nr.11 poz.61): Art.2: An official, guilty of accepting a gift
⢿⡄⠘⠷⠚⠋⠀ or another material benefit, or a promise thereof, [in matters
⠈⠳⣄ relevant to duties], shall be punished by death by shooting.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] Debian testing drop redis non systemd

[John Hughes]

Jaromil wrote:


I would like to know here if anyone knows in detail the "reasons"
Debian is removing the support for sysvinit scripts in the redis
package.


Wouldn't it be more to the point to find out *if* Debian is removing the 
support for sysvinit scripts in the redis package before trying to find 
out why?


Because they aren't.

What they have done is what the changelog says:


   * Drop*Debian-specific*  support for
 /etc/redis/redis-{server,sentinel}.{pre,post}-{up,down}.d and remove them
 if unchanged.


The Debian supplied init scripts (debian/redis-server.init and 
debian/redis-sentinel.init) still exist, they just no longer include the 
(Debian specific) calls to "Run_parts".


These init scripts do not exist in the upstream redis distribution.  
They were added by Debian.


My appologies for posting to a list from which I have been banned, but I 
thought it might be wise to have a little more light and a little less heat.






___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Debian testing drop redis non systemd

[Joel Roth]

Jaromil wrote:
> I would like to know here if anyone knows in detail the "reasons"
> Debian is removing the support for sysvinit scripts in the redis
> package. Is there a limitation of sorts, or a problem generated by
> having the init scripts left in the package, or is it just vandalism?
> is there a discussion or bug open?

Don't know if a bug is open, but ISTR that reducing the
burden of maintaining and supporting users of sysv init
scripts was mentioned as one of Debian's reasons for
adopting systemd.

-- 
Joel Roth
  

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Debian testing drop redis non systemd

[Jaromil]

On Thu, 19 Oct 2017, Steve Litt wrote:

> When you contact them, you might want to also give them the runit run
> script for redis from the Void distro:

cheers Steve, I will pass it on.

ah!! now you like redis do you??? :^

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Debian testing drop redis non systemd

[Steve Litt]

On Thu, 19 Oct 2017 10:22:33 +0200
Jaromil  wrote:

> On Wed, 18 Oct 2017, Arnt Gulbrandsen wrote:
> 
> > Steve Litt writes:  
> > > Does anyone here actually use redis? I looked it up, and to me it
> > > looks like dbus on steroids. An in-memory data store accessible
> > > by lots of different applications. What could POSSIBLY go wrong?  
> > 
> > I've used in several contexts, it's great at its job and a joy to
> > use.  
> 
> Same here, its a core part of many software projects, not only web
> based but also on embedded systems and micro-service related.
> 
> One of its authors, antirez, is an old friend and coding made of some
> of us here. Redis is heavily inspired by minimalism, simplicity and
> UNIX principles since its inception. We will contact upstream so they
> notice the fact the Debian maintainers are removing a support which is
> provided upstream, since redis does pack scripts for sysvinit that
> should be left in place.

Hi Jaromil,

When you contact them, you might want to also give them the runit run
script for redis from the Void distro:

=
#!/bin/sh
if [ ! -d /var/lib/redis ]; then
mkdir -m0700 -p /var/lib/redis
fi
chown redis:redis /var/lib/redis
if [ ! -d /run/redis ]; then
mkdir -m0750 -p /run/redis
fi
chown redis:redis /run/redis
exec chpst -u redis:redis redis-server /etc/redis/redis.conf > /dev/null

=

Everything but the last line sets up properly permissioned directories.
The last line replaces the run script's process with redis-server,
running as user redis, group redis, configured
by /etc/redis/redis.conf. The fact that it's piped to /dev/null means
no logging takes place,  which is kind of weird. Maybe redis has a
logging facility of its own???

I installed it on my Void box, and it runs the command 
redis-server 127.0.0.1:6379
as a daemon.

Thanks,
 
SteveT

Steve Litt 
October 2017 featured book: Rapid Learning for the 21st Century
http://www.troubleshooters.com/rl21
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Debian testing drop redis non systemd

[golinux]

On 2017-10-19 06:24, Arnt Karlsen wrote:

On Thu, 19 Oct 2017 11:09:34 +0300, Aldemir wrote in message
:


>
> No need to panic. The situation is under control. Noone will pull
> sysv init support from redis.
>
> HND
>
> KatolaZ
>
>
That's the spirit! Many many thanks!
--
aldemir


..maybe we should file a bug (fix) demonstrating this proper
Devuan way to fix this and future such Debian/systemd bugs?



Choice is rapidly disappearing in the Debian camp.  In addition to 
Arnt's suggestion, this should be brought to light in the Debian user 
community - FDN and debian-user for starts. It is yet another wake up 
call for those who have been slow to grasp the gravity of the path that 
Debian has chosen.


I no longer have a Debian user account but when I have the time and 
mental clarity to find the right words (that won't be today), I will 
post to FDN. That should produce some lively discussion!


golinux

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Debian testing drop redis non systemd

[Arnt Karlsen]

On Thu, 19 Oct 2017 11:09:34 +0300, Aldemir wrote in message 
:

> >
> >
> >
> >
> > No need to panic. The situation is under control. Noone will pull
> > sysv init support from redis.
> >
> > HND
> >
> > KatolaZ
> >
> >  
> That's the spirit! Many many thanks!
> --
> aldemir

..maybe we should file a bug (fix) demonstrating this proper 
Devuan way to fix this and future such Debian/systemd bugs?

-- 
..med vennlig hilsen = with Kind Regards from Arnt Karlsen
...with a number of polar bear hunters in his ancestry...
  Scenarios always come in sets of three: 
  best case, worst case, and just in case.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Debian testing drop redis non systemd

[Jaromil]

On Wed, 18 Oct 2017, Alberto Zuin - Liste wrote:

> Redis project started by an Italian guy which is also in the VUA
> group.


indeed. yet another VUA being outed :^) let's hope systemd-hooligans
don't go and delete wikipedia pages about him and his work too now.


antirez just replied me on the fly because he is traveling and
confirms that official Redis position is that of supporting all init
systems. He also says that: the most "obvious" way to start redis is
from init.d scripts. distros may do whatever they want, but the
support to start redis from a sysvinit script will never be removed.

I would like to know here if anyone knows in detail the "reasons"
Debian is removing the support for sysvinit scripts in the redis
package. Is there a limitation of sorts, or a problem generated by
having the init scripts left in the package, or is it just vandalism?
is there a discussion or bug open?

ciao

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Debian testing drop redis non systemd

[Arnt Gulbrandsen]

jaro...@dyne.org writes:

Same here, its a core part of many software projects, not only web
based but also on embedded systems and micro-service related.


Totally offtopic but some if you will be fascinated by the references to 
redis in this talk by John Regehr: https://youtu.be/Ux0YnVEaI6A


Summary: Compiler research (and in particular superoptimiser research) 
involves spending a LOT of CPU time on finding optimisation candidates and 
judging their potential. Hours or even days to compile an executable. 
Caching across invocations helps speed that up, and sharing redis dumps is 
useful for discussing results and reporting bugs.


Arnt
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Debian testing drop redis non systemd

[Jaromil]

On Wed, 18 Oct 2017, Arnt Gulbrandsen wrote:

> Steve Litt writes:
> > Does anyone here actually use redis? I looked it up, and to me it looks
> > like dbus on steroids. An in-memory data store accessible by lots of
> > different applications. What could POSSIBLY go wrong?
> 
> I've used in several contexts, it's great at its job and a joy to use.

Same here, its a core part of many software projects, not only web
based but also on embedded systems and micro-service related.

One of its authors, antirez, is an old friend and coding made of some
of us here. Redis is heavily inspired by minimalism, simplicity and
UNIX principles since its inception. We will contact upstream so they
notice the fact the Debian maintainers are removing a support which is
provided upstream, since redis does pack scripts for sysvinit that
should be left in place.

This episode is again of great shame on Debian maintainers, but it
should be addressed by upstream.

ciao

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Debian testing drop redis non systemd

[Aldemir Akpinar]

>
>
>
>
> No need to panic. The situation is under control. Noone will pull sysv
> init support from redis.
>
> HND
>
> KatolaZ
>
>
That's the spirit! Many many thanks!
--
aldemir
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Debian testing drop redis non systemd

[KatolaZ]

On Wed, Oct 18, 2017 at 03:46:39PM +0200, Bardot Jérôme wrote:
> redis (4:4.0.2-3) unstable; urgency=medium
> 
>   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.
> 
>  -- Chris Lamb   Wed, 11 Oct 2017 22:55:00 -0400
> 


No need to panic. The situation is under control. Noone will pull sysv
init support from redis. 

HND

KatolaZ

-- 
[ ~.,_  Enzo Nicosia aka KatolaZ - GLUGCT -- Freaknet Medialab  ]  
[ "+.  katolaz [at] freaknet.org --- katolaz [at] yahoo.it  ]
[   @)   http://kalos.mine.nu ---  Devuan GNU + Linux User  ]
[ @@)  http://maths.qmul.ac.uk/~vnicosia --  GPG: 0B5F062F  ] 
[ (@@@)  Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ  ]


signature.asc
Description: Digital signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Debian testing drop redis non systemd

[tirveni yadav]

On Thu, Oct 19, 2017 at 4:56 AM, Hendrik Boom  wrote:
> On Wed, Oct 18, 2017 at 03:46:39PM +0200, Bardot Jérôme wrote:
>> redis (4:4.0.2-3) unstable; urgency=medium
>>
>>   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.
>>
>>  -- Chris Lamb   Wed, 11 Oct 2017 22:55:00 -0400
>>
>
>> pub  4096R/03878A98 2015-08-26 Bardot Jérôme 
>> sub  4096R/4144A514 2015-08-26 [expires: 2020-08-24]
>
> From all the responses in this thread, it looks as if there is ample
> reason to keep it around for Devuan.
>
> -- hendrik
>

+1

We are using Redis for caching and sessions in the applications servers.

Redis is very useful application.


-- 
Regards,

Tirveni Yadav
www.udyansh.org
www.bael.io

What is this Universe ? From what it arises ? Into what does it go?
In freedom it arises, In freedom it rests and into freedom it melts away.
Upanishads.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Debian testing drop redis non systemd

[Hendrik Boom]

On Wed, Oct 18, 2017 at 03:46:39PM +0200, Bardot Jérôme wrote:
> redis (4:4.0.2-3) unstable; urgency=medium
> 
>   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.
> 
>  -- Chris Lamb   Wed, 11 Oct 2017 22:55:00 -0400
> 

> pub  4096R/03878A98 2015-08-26 Bardot Jérôme 
> sub  4096R/4144A514 2015-08-26 [expires: 2020-08-24]

From all the responses in this thread, it looks as if there is ample 
reason to keep it around for Devuan. 

-- hendrik
 




> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Debian testing drop redis non systemd

[Clarke Sideroad]

On 18/10/17 09:46 AM, Bardot Jérôme wrote:

redis (4:4.0.2-3) unstable; urgency=medium

   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.

  -- Chris Lamb   Wed, 11 Oct 2017 22:55:00 -0400




Debian takes another step in the wrong direction.

            DESKTOP
Debian - The Universal Operating System
  ^
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Debian testing drop redis non systemd

[Alberto Zuin - Liste]

Redis, for sure, is one of the most used in memory datastore, a good 
cache system like memcache but more flexible when you have to store real 
data and a standard SQL database is not fast enough: one common example 
of application, is to store the authentication tokens in a clustered web 
server environment. Maybe it is one of the most powerful component used 
in almost every online system.


In my company we have a cluster of 12 devuan nodes with redis managed by 
sentinel: yes, it is used. And, as someone else said, no it is not a 
system tool.


Also, just a curiosity: Redis project started by an Italian guy which is 
also in the VUA group.


Alberto


On 18/10/17 16:04, Steve Litt wrote:

On Wed, 18 Oct 2017 15:46:39 +0200
Bardot Jérôme  wrote:


redis (4:4.0.2-3) unstable; urgency=medium

   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.

  -- Chris Lamb   Wed, 11 Oct 2017 22:55:00 -0400

Does anyone here actually use redis? I looked it up, and to me it looks
like dbus on steroids. An in-memory data store accessible by lots of
different applications. What could POSSIBLY go wrong?
  
SteveT


Steve Litt
October 2017 featured book: Rapid Learning for the 21st Century
http://www.troubleshooters.com/rl21
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Debian testing drop redis non systemd

[Rick Moen]

Quoting Steve Litt (sl...@troubleshooters.com):
 
> Does anyone here actually use redis? I looked it up, and to me it looks
> like dbus on steroids. An in-memory data store accessible by lots of
> different applications. What could POSSIBLY go wrong?

Extremely useful for large Web sites.  _Not_ a system-level tool at all.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Debian testing drop redis non systemd

[dev]

On 10/18/2017 10:04 AM, Steve Litt wrote:


> Does anyone here actually use redis? I looked it up, and to me it looks
> like dbus on steroids. An in-memory data store accessible by lots of
> different applications. What could POSSIBLY go wrong?
>  
> SteveT

The Nextcloud project[1] recommends it as one of it's supported cache
system. Likely it's a pretty common tool for web based apps but not sure
on that.

[1]
https://docs.nextcloud.com/server/12/admin_manual/configuration_server/caching_configuration.html
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Debian testing drop redis non systemd

[Steve Litt]

On Wed, 18 Oct 2017 15:46:39 +0200
Bardot Jérôme  wrote:

> redis (4:4.0.2-3) unstable; urgency=medium
> 
>   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.
> 
>  -- Chris Lamb   Wed, 11 Oct 2017 22:55:00 -0400

Does anyone here actually use redis? I looked it up, and to me it looks
like dbus on steroids. An in-memory data store accessible by lots of
different applications. What could POSSIBLY go wrong?
 
SteveT

Steve Litt 
October 2017 featured book: Rapid Learning for the 21st Century
http://www.troubleshooters.com/rl21
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] Debian testing drop redis non systemd

[Bardot Jérôme]

redis (4:4.0.2-3) unstable; urgency=medium

  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.

 -- Chris Lamb   Wed, 11 Oct 2017 22:55:00 -0400



0x03878A98.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng