Update redis_init_script.tpl

status command currently reports success when redis has crashed and the pid file still exists. Changing to check the actual process is running.
FIXED redis-benchmark's idle mode.With idle mode shouldn't create write event
Fix function prototype in redis-cli.c.

Fix function prototype in redis-cli.c.
Fix zero-ordering SORT when called against lists

People mostly use SORT against lists, but our prior
behavior was pretending lists were an unordered bag
requiring a forced-sort when no sort was requested.

We can just use the native list ordering to ensure
consistency across replicaion and scripting calls.

Closes #2079
Closes #545 (again)
Fix redis-trib import SCAN call
Reconnect redis-cli when cluster return "moved"

    if redis works in cluster-mode and redis-cli was run with argv, reconnect if needs.
    example:
    ./redis-cli set foo bar

    if return is MOVED redis-cli just do nothing.
Typo fixes in redis.conf

Fix two typos in redis.conf:

- "trnasfers" --> "transfers"
- "enalbed" --> "enabled"
sds.c: Correct some comments
sds.c/sdscatvprintf: set va_end to finish va_list cpy
sds.c: Correct two spelling mistakes in comments
override histfile from env - fixes #831 and copies #833
Support daemon supervision by upstart or systemd

Both upstart and systemd provide a way for daemons to
be supervised, as well as a mechanism for them to
signal their readyness status.

This patch provides compatibility with this functionality while
not interfering with other methods.

With this, it will be possible to use `expect stop` with upstart
and `Type=notify` with systemd.

A more detailed explanation of the mechanism can be found here:
http://spootnik.org/entries/2014/11/09_pid-tracking-in-modern-init-systems.html
Add SENTINEL INFO-CACHE [masters...]

Sentinel queries the INFO from every master and from every replica of
every master.

We can cache the INFO results in Sentinel so Sentinel can be a single
place to quickly get all INFO output for an entire Sentinel monitoring
group.

This commit gives us SENTINEL INFO-CACHE in two forms:
  - SENTINEL INFO-CACHE — returns all masters and all replicas
  - SENTINEL INFO-CACHE master0 master1 ... masterN — vararg specify masters

Results are returned as a multibulk reply with two top-level entries
for each master.  The first entry for each master is the name of the master.
The second entry is a nested multibulk reply with the contents of INFO,
first for the master, then an additional entry for each of the
replicas.
zipmap.c: update comments above
redis-benchmark AUTH command to be discarded after the first send #2150
Fix implicit declaration of ioctl on Solaris
replaced // comments  #2150
bitops.c/redisPopcount: little optimization in loop
bitops.c/bitopCommand: skip short minlen for FAST PATH
Check that tcp-backlog is matched by /proc/sys/net/core/somaxconn.