Description of problem ====================== Design of skynet daemon and systemd service is wrong. This may lead to other issues and subtle errors. Version-Release number of selected component ============================================ rhscon-agent-0.0.3-3.el7.noarch Actual results ============== Skynet daemon is not implemented as a proper systemd service: ~~~ # rpm -qlv rhscon-agent | grep systemd -rwxr-xr-x 1 root root 244 Feb 29 18:21 /usr/lib/systemd/system/systemd-skynetd.service # cat /usr/lib/systemd/system/systemd-skynetd.service [Unit] Description=SkyRing Node Eventing Daemon to push signals to SkyRing [Service] Type=simple PIDFile=/var/run/skynetd.pid ExecReload=/usr/bin/skynetd reload ExecStart=/usr/bin/skynetd start ExecStop=/usr/bin/skynetd stop KillMode=process [root@mbukatov-usm2-node1 ~]# ~~~ This approach is completely wrong. Instead of relying on systemd with daemonization and service management, skynetd does it on it's own, eg. PID management is a hack (see additional information below for details). The idea of systemd is that systemd handles service management for you so that you don't need to reimplement it yourself. Some other minor issues includes (this is not a full list): * the name of the service should not contain a 'systemd-' prefix, this makes sense for systemd components only. The correct name is just skynet.service or skynetd.service * systemd ini file should not be executable Expected results ================ Skynet service is implemented so that systemd handles all service related tasks (daemonization, handling of pid or lock files ...). Skynet service must follow *systemd packaging guidelines*: https://fedoraproject.org/wiki/Packaging:Systemd Additional info =============== I have discussed this issue with Branislav Blaskovic who has an experience in this area. His comments are: > Well as I wrote before, I am afraid that the situation here is, that > skynetd is handling PID file on its own and systemd should handle it. > So there could be some issues. > > I read the code just briefly, but I think the situation could be like > this: (I can be also wrong) :-) > > 1. systemd launches 'skynetd start' which returns PID 123. > 2. 'skynetd start' throws another process (pid 456) and dies. > 3. systemd wants to write PID 123 to PIDFile BUT skynetd is using the > same pidfile > |-- there could be maybe race condition or something similar > > It's working for you maybe because systemd writes 123 to PIDFIle and > then skynetd rewrites it to 456, so when systemd is checking status it > sees correct PID number. But it's not the one which systemd wrote to > it. > > So yes, it could basically works, but it would be better to rewrite > skynetd so systemd can handle it.
What is the version of the rhscon-agent package that fixes this bug?
Checking with: rhscon-agent-0.0.18-1.el7scon.noarch And skynetd service has a proper systemd service unit file now: * name of the service ('skynetd') no longer contains "systemd-" prefix * start, stop and restart is possible * enable/disable of the service works * restart on failure works * checking logs via journal works