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 13:33:33
|
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 |
