Re: [Apcupsd-users] apcupsd - systemd issue with pidfile
Brought to you by:
adk0212
Menu
▾
▴
Re: [Apcupsd-users] apcupsd - systemd issue with pidfile
|
From: Lorenzo B. <lor...@vd...> - 2022-04-14 06:51:30
|
Ted, thank you for the reply. The solution *is* "postpone the termination of the parent process after the child has written the PID file". What I did not post is *how* to implement the solution. This is because I believe that putting a sleep(1) in the code is rather a workaround. Infact, with my post and email I was asking you to implement it (in any way you like). After all, as long as you are the maintainer you know the code more deeply than me. At this point I will implement something and send you a patch. Keep in mind that QNX forks in a different way than Linux and I don't have a QNX platform for testing. Regards, Lorenzo Buzzi Il giorno gio 14 apr 2022 alle ore 08:36 Ted Mittelstaedt < te...@mi...> ha scritto: > Lorenzo, > > Currently there are only 2 developers who have commit rights setup for > apcupd, myself and Adam. All other developers of this project are no > longer involved with it, and Adam is also essentially no longer involved > with it either. > > My rule on patches is simple - if you don't post it publicly on the > mailing list, it's not EVER going into the distribution. Anything that > anyone sends me directly in the way of a patch will be posted to the list > for public review. The apcupsd project is lower volume (mainly because it > Just Works) and there's no benefit to having a double secret mailing list > just for developers and patches. > > I'm glad you found a bug and you have a solution. I'm disappointed that > the extent of the issue is you saying you have a solution, without that > solution posted to the list. > > I remain hopeful that you WILL post the solution to the list. > > Thanks! > > Ted > On 4/13/2022 5:19 AM, Lorenzo Buzzi wrote: > > "vendor preset: disabled" only means that the service will be "disabled > at startup" by default at RPM package installation. > The Red Hat packagers likely decided to let the system > administrator decide whether or not to enable the service at startup. > > My post is rather related to the following message, that appears in the > systemd apcupsd related messages: > Apr 01 10:08:31 bacon systemd[1]: *apcupsd.service: Can't open PID file > /run/apcupsd.pid (yet?) after start: Operation not permitted* > > As I extensively explained, I found the source of the issue. I also have a > solution. > But I believe that it is safer if the apcupsd developers will implement it. > I assert this since there are many ways to delay the termination of the > apcupsd daemon's ancestor process and only the developers that wrote it > knows which is the best one. > > Il giorno mer 13 apr 2022 alle ore 13:52 Jean-David Beyer via > Apcupsd-users <apc...@li...> ha scritto: > >> On 4/13/22 05:46, Lorenzo Buzzi wrote: >> > Although the daemon is started and works correctly, the startup log >> > always reports the following: >> > root@bacon:/etc/apcupsd# systemctl status apcupsd.service >> > ● apcupsd.service - UPS power management daemon >> > Loaded: loaded (/lib/systemd/system/apcupsd.service; enabled; >> > vendor preset: enabled) >> > Active: active (running) since Fri 2022-04-01 10:08:31 CEST; 2s ago >> > Docs: man:apcupsd(8) >> > Process: 15683 ExecStartPre=/lib/apcupsd/prestart (code=exited, >> > status=0/SUCCESS) >> > Process: 15697 ExecStart=/sbin/apcupsd (code=exited, >> status=0/SUCCESS) >> > Main PID: 15699 (apcupsd) >> > Tasks: 3 (limit: 9042) >> > Memory: 1.2M >> > CGroup: /system.slice/apcupsd.service >> > └─15699 /sbin/apcupsd >> > >> > Apr 01 10:08:31 bacon systemd[1]: Starting UPS power management >> daemon... >> > Apr 01 10:08:31 bacon systemd[1]: *apcupsd.service: Can't open PID file >> > /run/apcupsd.pid (yet?) after start: Operation not permitted* >> > Apr 01 10:08:31 bacon apcupsd[15699]: apcupsd 3.14.14 (31 May 2016) >> > debian startup succeeded >> > Apr 01 10:08:31 bacon systemd[1]: Started UPS power management daemon. >> > Apr 01 10:08:31 bacon apcupsd[15699]: NIS server startup succeeded >> >> I am running Red Hat Enterprise Linux release 8.5 (Ootpa) with a >> Smart-Ups 750. 3.14.14 (31 May 2016) redhat >> FIRMWARE : UPS 04.6 / 00.5 >> >> On my system, I get: >> >> localhost:root[/var/log]# systemctl status apcupsd.service >> ● apcupsd.service - APC UPS Power Control Daemon for Linux >> Loaded: loaded (/usr/lib/systemd/system/apcupsd.service; enabled; >> vendor preset: disabled) <---<<< >> Active: active (running) since Sun 2022-04-10 15:02:46 EDT; 2 days ago >> Process: 18057 ExecStartPre=/bin/rm -f /etc/apcupsd/powerfail >> (code=exited, status=0/SUCCESS) >> Main PID: 18082 (apcupsd) >> Tasks: 3 (limit: 408540) >> Memory: 1.0M >> CGroup: /system.slice/apcupsd.service >> └─18082 /sbin/apcupsd -b -f /etc/apcupsd/apcupsd.conf >> >> Apr 10 15:02:46 localhost.localdomain systemd[1]: Starting APC UPS Power >> Control Daemon for Linux... >> Apr 10 15:02:46 localhost.localdomain systemd[1]: Started APC UPS Power >> Control Daemon for Linux. >> Apr 10 15:02:46 localhost.localdomain apcupsd[18082]: apcupsd 3.14.14 >> (31 May 2016) redhat startup succeeded >> Apr 10 15:02:46 localhost.localdomain apcupsd[18082]: NIS server startup >> succeeded >> >> >> -- >> .~. Jean-David Beyer >> /V\ Shrewsbury, New Jersey >> /( )\ Red Hat Enterprise Linux >> ^^-^^ up 2 days, 16 hours, 27 minutes >> >> >> _______________________________________________ >> Apcupsd-users mailing list >> Apc...@li... >> https://lists.sourceforge.net/lists/listinfo/apcupsd-users >> > > > -- > -- > Lorenzo Buzzi > VDS Rail > www.vdsrail.com > > > _______________________________________________ > Apcupsd-users mailing lis...@li...://lists.sourceforge.net/lists/listinfo/apcupsd-users > > _______________________________________________ > Apcupsd-users mailing list > Apc...@li... > https://lists.sourceforge.net/lists/listinfo/apcupsd-users > -- -- Lorenzo Buzzi VDS Rail www.vdsrail.com |
