Project

General

Profile

Actions

Bug #27184

closed

[smart_proxy_dynflow_core] "PID file /var/run/foreman-proxy/smart_proxy_dynflow_core.pid not readable (yet?) after start"

Added by Adam Ruzicka almost 5 years ago. Updated almost 4 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
-
Target version:
-
Difficulty:
Triaged:
No
Fixed in Releases:
Found in Releases:

Description

Cloned from https://bugzilla.redhat.com/show_bug.cgi?id=1724494

Description of problem:
After reboot of Capsule, the service 'smart_proxy_dynflow_core' shows message

"PID file /var/run/foreman-proxy/smart_proxy_dynflow_core.pid not readable (yet?) after start"

Version-Release number of selected component (if applicable):
tfm-rubygem-smart_proxy_dynflow_core-0.2.1-5.el7sat.noarch

How reproducible:
always

Steps to Reproduce:
1. Reboot cpasule server
2. systemctl status smart_proxy_dynflow_core
3.

Actual results:
Jun 26 17:29:25 capsule01 systemd1: Starting Foreman smart proxy dynflow core service...
Jun 26 17:29:29 capsule01 systemd1: PID file /var/run/foreman-proxy/smart_proxy_dynflow_core.pid not readable (yet?) after start.
Jun 26 17:29:29 capsule01 systemd1: Started Foreman smart proxy dynflow core service.

Expected results:
The service should start without any warning/error

Jun 26 17:29:25 capsule01 systemd1: Starting Foreman smart proxy dynflow core service...
Jun 26 17:29:29 capsule01 systemd1: Started Foreman smart proxy dynflow core service.

Additional info:
if the service is restarted, everything runs fine

  1. foreman-maintain service restart --only smart_proxy_dynflow_core
Actions #1

Updated by Adam Ruzicka almost 5 years ago

  • Subject changed from [smart_proxy_dynflow_core] "PID file /var/run/foreman-proxy/smart_proxy_dynflow_core.pid not readable (yet?) after start" to [smart_proxy_dynflow_core] "PID file /var/run/foreman-proxy/smart_proxy_dynflow_core.pid not readable (yet?) after start"

Smart proxy dynflow core writes its pidfile into /var/run/foreman-proxy/smart_proxy_dynflow_core.pid. However /var/run/foreman-proxy is created by systemd-tmpfiles (and configuration provided by foreman-proxy). If /var/run is backed by a volatile storage which gets emptied on reboot and the machine reboots, smart proxy dynflow core may be started earlier than systemd-tmpfiles created the needed directory, leading to this issue.

Actions #2

Updated by Adam Ruzicka almost 5 years ago

  • Project changed from Foreman Remote Execution to foreman-tasks
  • Assignee set to Adam Ruzicka
Actions #3

Updated by Adam Ruzicka almost 4 years ago

  • Status changed from New to Ready For Testing
  • Pull request https://github.com/theforeman/smart_proxy_dynflow/pull/64 added
Actions #4

Updated by The Foreman Bot almost 4 years ago

  • Fixed in Releases smart_proxy_dynflow-0.2.5 added
Actions #5

Updated by Adam Ruzicka almost 4 years ago

  • Status changed from Ready For Testing to Closed
Actions

Also available in: Atom PDF