Project

General

Profile

Actions
Copy link

Bug #2104

closed

pid-file: in suricata.yaml

Added by Jan Eagleman almost 7 years ago. Updated over 5 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Jason Ish
Target version:
-
Affected Versions:
Effort:
Difficulty:
Label:

Description

The pid-file: option in the suricata.yaml is not functioning. I made sure this wasn't a permission problem by giving 777 (so secure!) rights to a new folder and placing the pid file in there.

I only managed to get the pid file being created by using --pidfile /var/run/suricata.pid in /etc/sysconfig/suricata (CentOS 7)

Actions
Copy link
 #1

Updated by Andreas Herz almost 7 years ago

  • Assignee set to OISF Dev
  • Target version set to 70

Before #1157 the pid file was just possible in daemon mode and then just when you pass it via command line. So this way we don't break any existing setups. So we might either change that or just add documentation for that. I leave it to Victor to decide :)

Actions
Copy link
 #2

Updated by Victor Julien almost 7 years ago

  • Description updated (diff)

Hmm I would expect the option on the commandline and in the yaml to behave the same.

Actions
Copy link
 #3

Updated by Jason Ish almost 7 years ago

When --pidfile was updated to create even when in non-daemon mode, care was taken to not change any existing behaviour, https://github.com/inliniac/suricata/pull/907#issuecomment-38788249

For the config file and command line option to operate the same, some existing behaviour would have to change.

1) Follow daemon mode and always create a pid file, even when running in the foreground. Note that when in daemon mode a pid file is created even without the option present in suricata.yaml. The only way to disable pid file creation is to set the value to an empty string. This could break some existing setups where there is no expectation that a PID is being written.

This changes non-daemon mode.

OR

2) Never create a pid file default. --pidfile or the option must be present in the configuration file. This changes daemon mode, and may break setups that are expecting a pid file to be created by default.

If we were to change, I'm in favour of #2, I think its more consistent. But leaving as is strikes a good balance as well IMO.

Actions
Copy link
 #4

Updated by Victor Julien almost 7 years ago

Makes sense, thanks for the explanation Jason. I'm inclined to keep as-is. Perhaps a yaml comment & doc update are best.

Actions
Copy link
 #5

Updated by Victor Julien over 6 years ago

  • Status changed from New to Assigned
  • Assignee changed from OISF Dev to Jason Ish

Jason can you review/add docs/comments in documentation and yaml?

Actions
Copy link
 #6

Updated by Jason Ish over 5 years ago

  • Status changed from Assigned to Closed
  • Target version deleted (70)

Closing. Behaviour is unchanged, but a better comment was added to the configuration file in commit 95a781d4b208ea8d82b9e0e21038f0fd6e0f1345. Looks like this was fixed in 4.0.0.

Actions
Copy link

Also available in: Atom PDF