Re: [Apcupsd-users] apcupsd - systemd issue with pidfile
Brought to you by:
adk0212
Menu
▾
▴
Re: [Apcupsd-users] apcupsd - systemd issue with pidfile
|
From: Ted M. <te...@mi...> - 2022-04-14 07:15:44
|
I don't see a problem with putting a sleep() call in the code at exit - as long as it's only activated if a startup flag is passed to apcupsd saying it's needed. As I see it, if I understand you right, the root of the problem is due to choices the distribution maintainers make - whoever is compiling and configuring apcupsd for Debian or Ubuntu or whatever. If you just start apcupsd at the command line there is no issue. It's when the porters in a distribution decide to use systemd and decide to have systemd monitor if the daemon is alive by checking it's PID file is when you have the problem. But not every distribution uses systemd So it seems to me the right way to fix it would be to add another flag in the config file, commented out by default, that would add the sleep for whatever period of time the packager decided was appropriate up to a maximum amount of time. Then the packagers who are not affected would not need to change anything. Ted On 4/13/2022 11:51 PM, Lorenzo Buzzi wrote: > 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 <http://www.vdsrail.com/> >> >> >> _______________________________________________ >> Apcupsd-users mailing list >> Apc...@li... >> https://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 <http://www.vdsrail.com/> > > > _______________________________________________ > Apcupsd-users mailing list > Apc...@li... > https://lists.sourceforge.net/lists/listinfo/apcupsd-users |
