Project

General

Profile

Actions

Bug #8168

closed

If syslog service is stopped, it is not restarted automatically by rudder-agent, so agent doesn't report anything

Added by Nicolas CHARLES over 8 years ago. Updated over 2 years ago.

Status:
Released
Priority:
2
Category:
System techniques
Target version:
Severity:
Critical - prevents main use of Rudder | no workaround | data loss | security
UX impact:
User visibility:
Operational - other Techniques | Technique editor | Rudder settings
Effort required:
Medium
Priority:
0
Name check:
Fix check:
Regression:

Description

On a sles11, if syslog-ng is stop, running the agent won't restart it
So the node doesn't report a thing, and the node is in the "no answer" state - and won't auto-heal

we should automatically restart the appropriate syslog deamon when none is running

Fails at least on SLES11 rudder 3.1, but most likely on previous version of Rudder


Subtasks 2 (0 open2 closed)

Bug #10949: Agent output contains error because of new syslog service checksReleasedBenoît PECCATTEActions
Bug #10959: We should only use the "syslog" service on SLES11ReleasedBenoît PECCATTEActions

Related issues 1 (0 open1 closed)

Related to Rudder - Bug #10758: No report on Debian 8RejectedActions
Actions #1

Updated by Jonathan CLARKE over 8 years ago

  • Priority changed from 1 (highest) to 2

This is easily fixed by adding a call to "service_ensure_running" in the common promises.

Actions #2

Updated by Jonathan CLARKE over 8 years ago

  • Assignee set to Nicolas CHARLES
Actions #3

Updated by Nicolas CHARLES over 8 years ago

  • Target version changed from 3.1.10 to 2.11.21

Actually, this was never implemented :/

Actions #4

Updated by Nicolas CHARLES over 8 years ago

Ha - i'm hitting an unexpected issue: how do I know which syslog service I shall start in priority ?
For instance, if a system is provisionned with ksyslog, and then syslog-ng is installed, how can I detect that syslog-ng has precedence over ksyslog ?

I could service_check_running on each of syslog_ng, rsyslog, syslog, and if any of them is up and running don't do anything, else start the most complex one ? (syslog-ng > rsyslog > syslog)

What do you think of it ?

Actions #5

Updated by Jonathan CLARKE over 8 years ago

  • Assignee changed from Nicolas CHARLES to Alexis Mousset

Nicolas CHARLES wrote:

Ha - i'm hitting an unexpected issue: how do I know which syslog service I shall start in priority ?
For instance, if a system is provisionned with ksyslog, and then syslog-ng is installed, how can I detect that syslog-ng has precedence over ksyslog ?

I could service_check_running on each of syslog_ng, rsyslog, syslog, and if any of them is up and running don't do anything, else start the most complex one ? (syslog-ng > rsyslog > syslog)

This order is subjective, so we shouldn't do that.

What do you think of it ?

On SuSE, this is quite easy because there is a config file in /etc that determines which syslog is in use.

Actions #6

Updated by Alexis Mousset over 8 years ago

  • Status changed from New to In progress
Actions #7

Updated by Alexis Mousset over 8 years ago

Not that easy on SuSE either (with the "syslog" pseudo-service which point to the actual logging service), because service_ensure_running("syslog") ends up greping the name of the service in ps output (and does not find it because syslog is never running), and therefore tries to start it on every run.

Actions #8

Updated by Jonathan CLARKE over 8 years ago

  • Translation missing: en.field_tag_list changed from Sponsored to Sponsored, Quick and important, Next minor release
Actions #9

Updated by Vincent MEMBRÉ over 8 years ago

  • Target version changed from 2.11.21 to 2.11.22
Actions #10

Updated by Vincent MEMBRÉ over 8 years ago

  • Target version changed from 2.11.22 to 2.11.23
Actions #11

Updated by Vincent MEMBRÉ over 8 years ago

  • Target version changed from 2.11.23 to 2.11.24
Actions #12

Updated by Vincent MEMBRÉ over 8 years ago

  • Target version changed from 2.11.24 to 308
Actions #13

Updated by Vincent MEMBRÉ over 8 years ago

  • Target version changed from 308 to 3.1.14
Actions #14

Updated by Vincent MEMBRÉ about 8 years ago

  • Target version changed from 3.1.14 to 3.1.15
Actions #15

Updated by Vincent MEMBRÉ about 8 years ago

  • Target version changed from 3.1.15 to 3.1.16
Actions #16

Updated by Vincent MEMBRÉ about 8 years ago

  • Target version changed from 3.1.16 to 3.1.17
Actions #17

Updated by Vincent MEMBRÉ about 8 years ago

  • Target version changed from 3.1.17 to 3.1.18
Actions #18

Updated by Vincent MEMBRÉ almost 8 years ago

  • Target version changed from 3.1.18 to 3.1.19
Actions #19

Updated by Alexis Mousset almost 8 years ago

  • Status changed from In progress to New
Actions #20

Updated by Jonathan CLARKE almost 8 years ago

  • Severity set to Major - prevents use of part of Rudder | no simple workaround
Actions #21

Updated by François ARMAND over 7 years ago

  • Severity changed from Major - prevents use of part of Rudder | no simple workaround to Critical - prevents main use of Rudder | no workaround | data loss | security
  • User visibility set to Operational - other Techniques | Technique editor | Rudder settings

We are setting it to "critical" because data are lost (no reports during the period).

Actions #22

Updated by Benoît PECCATTE over 7 years ago

  • Priority set to 71
Actions #23

Updated by Alexis Mousset over 7 years ago

The only easy fix is for SLES11 (syslog pseudo-service) on Rudder 4.1 (because of the new service methods). All other cases require some more thinking about the issue.

Actions #24

Updated by Vincent MEMBRÉ over 7 years ago

  • Target version changed from 3.1.19 to 3.1.20
Actions #25

Updated by Jonathan CLARKE over 7 years ago

  • Assignee deleted (Alexis Mousset)
Actions #26

Updated by Alexis Mousset over 7 years ago

  • Effort required set to Medium
  • Priority changed from 71 to 70

This is a medium issue because we do not know how to properly detect the service to start in the general case.

Actions #27

Updated by Vincent MEMBRÉ over 7 years ago

  • Target version changed from 3.1.20 to 3.1.21
Actions #28

Updated by François ARMAND over 7 years ago

  • Related to Bug #10758: No report on Debian 8 added
Actions #29

Updated by Jonathan CLARKE over 7 years ago

  • Translation missing: en.field_tag_list changed from Sponsored, Quick and important, Next minor release to Sponsored, Next minor release
Actions #30

Updated by Benoît PECCATTE over 7 years ago

  • Assignee set to Benoît PECCATTE
Actions #31

Updated by Benoît PECCATTE over 7 years ago

  • Target version changed from 3.1.21 to 4.1.4

Let's ensure running all syslog services present.

This will work in all the cases except when someone installs 2 syslog services and doesn't configure them to work together.

Actions #32

Updated by Benoît PECCATTE over 7 years ago

  • Status changed from New to In progress
Actions #33

Updated by Benoît PECCATTE over 7 years ago

  • Status changed from In progress to Pending technical review
  • Assignee changed from Benoît PECCATTE to Alexis Mousset
  • Pull Request set to https://github.com/Normation/rudder-techniques/pull/1150
Actions #34

Updated by Benoît PECCATTE over 7 years ago

  • Status changed from Pending technical review to Pending release
Actions #35

Updated by Alexis Mousset over 7 years ago

  • Subject changed from If syslog-ng is stopped, it is not restarted automatically by rudder-agent, so agent doesn't report anything to If syslog service is stopped, it is not restarted automatically by rudder-agent, so agent doesn't report anything
Actions #36

Updated by Alexis Mousset over 7 years ago

  • Status changed from Pending release to Released

This bug has been fixed in Rudder 4.1.4 which was not released (see changelog for details), and is available in Rudder 4.1.5.

Actions #37

Updated by Alexis Mousset over 2 years ago

  • Priority changed from 70 to 0
Actions

Also available in: Atom PDF