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-05-31 13:20:25
|
Hi Ted, any update on this? Will a commit be signalled by the apcupsd-commits mailing list when this is integrated in the sources? Lorenzo Il giorno dom 17 apr 2022 alle ore 00:45 Ted Mittelstaedt < te...@mi...> ha scritto: > No that's perfectly fine! Probably the project is badly in need of > linting! :-) > > Ted > On 4/14/2022 6:33 AM, Lorenzo Buzzi wrote: > > If you grep for 'make_pid' in the whole tree of the project you will agree > that this declaration is a leftover of some past development. > Actually it is not strictly needed. And I won't get annoyed if you decide > to exclude it. > > Il giorno gio 14 apr 2022 alle ore 15:07 Ted Mittelstaedt < > te...@mi...> ha scritto: > >> Hi Lorenzo, >> >> I think I'm missing why this change is needed: >> >> diff -ruN a/include/extern.h b/include/extern.h >> --- a/include/extern.h 2015-03-21 02:47:16.000000000 +0100 >> +++ b/include/extern.h 2022-04-14 10:47:42.794516086 +0200 >> @@ -92,7 +92,6 @@ >> /* In apcfile.c */ >> extern int make_file(UPSINFO *ups, const char *path); >> extern void make_pid_file(void); >> -extern void make_pid(void); >> >> >> Ted >> >> >> On 4/14/2022 2:14 AM, Lorenzo Buzzi wrote: >> >> I propose to change the source as per attached patch file: >> >> - Done: >> - added a WAITFORPID integer flag, 0 by default (please check if I >> added everything is needed) >> - if the flag value is > 0, the parent process waits up to the >> specified number of seconds before quitting, checking the PID file >> existence once per second >> - updated platform/*etc*/apcupsd.conf.in (please check if the >> position of the flag is good and correct my english) >> - Won't do: >> - NOT updated platform/*mingw*/apcupsd.conf.in since in Windows the >> fork and PID file creation and nopped >> - To do (too early at present time): >> - update doc/manual/manual.html >> - update doc/manual/manual.rst >> - update doc/apcupsd.conf.5 >> >> >> Il giorno gio 14 apr 2022 alle ore 09:57 Lorenzo Buzzi < >> lor...@vd...> ha scritto: >> >>> Exactly! >>> >>> I am trying to develop something in this direction. >>> At this point I propose the value of the flag in the configuration file >>> to be the maximum amount of time (seconds is ok?) to be waited. >>> Could be WAITFORPID a good name for the flag? >>> >>> Lorenzo >>> >>> Il giorno gio 14 apr 2022 alle ore 09:16 Ted Mittelstaedt < >>> te...@mi...> ha scritto: >>> >>>> 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 >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>>> >>>> >>>> _______________________________________________ >>>> 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 >>> >> >> >> -- >> -- >> 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 > > > _______________________________________________ > 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 |
