Назад | Перейти на главную страницу

Redis не запускается в OpenSuse Leap 42.1 после обновления

Я решил обновить машину с 13.2 до последней версии Leap 42.1. Я начал процесс, и он сделал обновление. После перезагрузки все работает, кроме службы redis server. Я не могу запустить службу Redis, используя:

# service redis start

Статус:

# service redis status
redis.target - Redis target allowing to start/stop all redis@.service instances at once
   Loaded: loaded (/usr/lib/systemd/system/redis.target; static)
   Active: active since Fri 2015-11-20 03:47:07 EET; 1s ago

Хотя он говорит, что он «активен», когда я проверяю, запущен ли процесс, на самом деле это не так:

# ps ax | grep -i redis
20892 pts/0    S+     0:00 grep -i redis

Единственный способ запустить сервер Redis - это запустить вручную:

# redis-server /etc/redis/default.conf

который запускает сервер без проблем.

Я попытался переустановить пакет redis и попытался сменить поставщика с "официального" репозитория на "сервер: база данных". Похоже, что ни одно из этих действий не решает проблему.

Мой default.conf file - это в значительной степени шаблон "по умолчанию", в котором были изменены только следующие:

daemonize yes #default is no
bind 127.0.0.1 1.2.3.4 #default is 127.0.0.1

Служебные файлы:

/usr/lib/systemd/system/redis.target
[Unit]
Description=Redis target allowing to start/stop all redis@.service instances at once

/usr/lib/systemd/system/redis@.service
[Unit]
Description=Redis
After=network.target
PartOf=redis.target

[Service]
Type=simple
User=redis
Group=redis
PrivateTmp=true
PIDFile=/var/run/redis/%i.pid
ExecStart=/usr/sbin/redis-server /etc/redis/%i.conf
Restart=on-failure

#ExecStart=/usr/sbin/openvpn --daemon --suppress-timestamps --writepid /var/run/openvpn/%i.pid --cd /etc/openvpn/ --config %i.conf
#ExecReload=/sbin/killproc -p /var/run/openvpn/%i.pid -HUP /usr/sbin/openvpn

[Install]
WantedBy=multi-user.target redis.target

Есть идеи, что изменилось с 13.2 на 42.1 и почему служба перестала работать? Также я, кажется, не помню, как раньше я перечислял Redis в chkconfig - после обновления оно исчезло, хотя я не совсем уверен, что это часть проблемы.

Изменить: вот файл журнала благодаря @Michael Hampton:

9042:signal-handler (1448036091) Received SIGTERM scheduling shutdown...
                _._
           _.-``__ ''-._
      _.-``    `.  `_.  ''-._           Redis 3.0.4 (00000000/0) 64 bit
  .-`` .-```.  ```\/    _.,_ ''-._
 (    '      ,       .-`  | `,    )     Running in standalone mode
 |`-._`-...-` __...-.``-._|'` _.-'|     Port: 6379
 |    `-._   `._    /     _.-'    |     PID: 9042
  `-._    `-._  `-./  _.-'    _.-'
 |`-._`-._    `-.__.-'    _.-'_.-'|
 |    `-._`-._        _.-'_.-'    |           http://redis.io
  `-._    `-._`-.__.-'_.-'    _.-'
 |`-._`-._    `-.__.-'    _.-'_.-'|
 |    `-._`-._        _.-'_.-'    |
  `-._    `-._`-.__.-'_.-'    _.-'
      `-._    `-.__.-'    _.-'
          `-._        _.-'
              `-.__.-'

9042:M 20 Nov 18:14:51.090 # Server started, Redis version 3.0.4
9042:M 20 Nov 18:14:51.091 * DB loaded from disk: 0.000 seconds
9042:M 20 Nov 18:14:51.091 * The server is now ready to accept connections on port 6379
9042:M 20 Nov 18:14:51.091 # User requested shutdown...
9042:M 20 Nov 18:14:51.091 * Saving the final RDB snapshot before exiting.
9042:M 20 Nov 18:14:51.126 * DB saved on disk
9042:M 20 Nov 18:14:51.126 * Removing the pid file.
9042:M 20 Nov 18:14:51.126 # Redis is now ready to exit, bye bye...

Я не уверен, почему он решает самопроизвольно просто выйти из-за «выключения, запрошенного пользователем».

Это модуль systemd, способный создавать несколько копий сервера с разными конфигурациями.

Чтобы использовать его, укажите имя экземпляра, который вы хотите использовать. Например, ваша существующая конфигурация, кажется, имеет имя default:

systemctl enable redis@default
systemctl start redis@default

Вам, вероятно, придется изменить /etc/redis/default.conf так что он пишет pidfile в том месте, которое ожидает systemd.

pidfile /var/run/redis/default.pid

После некоторого поиска я обнаружил, что нужно закомментировать daemonize yes или установите его на no. Самое смешное, что у меня была такая же конфигурация на 13.2, и она работала без проблем.

В любом случае надеюсь, что это кому-нибудь поможет.