Notification-email plugin gets restarted twice (fails one time) on startup

crowdsec
1

Hi team,

in my logs I found this:

time="29-12-2023 12:24:19" level=debug msg="starting plugin" args="[/usr/lib64/crowdsec/plugins/notification-email]" path=/usr/lib64/crowdsec/plugins/notification-email
time="29-12-2023 12:24:19" level=debug msg="plugin started" path=/usr/lib64/crowdsec/plugins/notification-email pid=1474227
time="29-12-2023 12:24:19" level=debug msg="waiting for RPC address" path=/usr/lib64/crowdsec/plugins/notification-email
time="29-12-2023 12:24:23" level=info msg="plugin process exited" path=/usr/lib64/crowdsec/plugins/notification-email pid=1474227
time="29-12-2023 12:24:24" level=debug msg="starting plugin" args="[/usr/lib64/crowdsec/plugins/notification-email]" path=/usr/lib64/crowdsec/plugins/notification-email
time="29-12-2023 12:24:24" level=debug msg="plugin started" path=/usr/lib64/crowdsec/plugins/notification-email pid=1474345
time="29-12-2023 12:24:24" level=debug msg="waiting for RPC address" path=/usr/lib64/crowdsec/plugins/notification-email
time="29-12-2023 12:24:24" level=info msg="registered plugin email_default"

I wonder why the plugin fails when run for the first time.

I am running the latest version of crowdsec (1.5.5), Linux server, no docker.

This is my email.yaml file

type: email           # Don't change
name: email_default   # Must match the registered plugin in the profile

# One of "trace", "debug", "info", "warn", "error", "off"
log_level: debug

# group_wait:         # Time to wait collecting alerts before relaying a message to this plugin, eg "30s"
# group_threshold:    # Amount of alerts that triggers a message before <group_wait> has expired, eg "10"
# max_retry:          # Number of attempts to relay messages to plugins in case of error
timeout: 20s          # Time to wait for response from the plugin before considering the attempt a failure, eg "10s"

#-------------------------
# plugin-specific options

# The following template receives a list of models.Alert objects
# The output goes in the email message body
format: |
  {{range . -}}
    {{$alert := . -}}
    {{range .Decisions -}}
      <html><body><p><a href=https://www.whois.com/whois/{{.Value}}>{{.Value}}</a> will get a <b>{{.Type}}</b> for the next <b>{{.Duration}}</b> for triggering <b>{{.Scenario}}</b> on machine <b>{{$alert.MachineID}}</b>.</p> <p><a href=https://app.crowdsec.net/cti/{{.Value}}>CrowdSec CTI</a></p></body></html>
    {{end -}}
  {{end -}}

smtp_host: mail.xy-space.de         # example: smtp.gmail.com
smtp_username: redacted             # Replace with your actual username
smtp_password: "redacted"           # Replace with your actual password
smtp_port: 587                      # Common values are any of [25, 465, 587, 2525]
auth_type: login                    # Valid choices are "none", "crammd5", "login", "plain"
sender_name: "redacted"
sender_email: redacted@mail.xy-space.de
email_subject: "CrowdSec Notification"
receiver_emails:
  - redacted@mail.xy-space.de

encryption_type: ssltls

Any ideas?

2

So tried to debug this, so all the logging is within the plugin lib we use.

So from what I can tell is by default the plugin will try to find the RPC address within the defered functions, however, the child process is being exited somehow either killed or OOM or something.

Log code here

However, looking at the log code I dont see how the runner would even return the error :person_shrugging:

RPC wait code

By default the RPC will wait a minute before classing the PID as “lost” then it will retry, however, your is being exited within 4 seconds so we cant debug further unless syslog or journalctl logs the actual reason and the plugin lib doesnt have an error to bubble to us.

Hope this helps understand that we cant actually debug further from CrowdSec point of view.