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-16 22:45:02
|
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: >> o added a WAITFORPID integer flag, 0 by default (please >> check if I added everything is needed) >> o 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 >> o updated platform/_etc_/apcupsd.conf.in >> <http://apcupsd.conf.in> (please check if the position of >> the flag is good and correct my english) >> * Won't do: >> o NOT updated platform/_mingw_/apcupsd.conf.in >> <http://apcupsd.conf.in> since in Windows the fork and >> PID file creation and nopped >> * To do (too early at present time): >> o update doc/manual/manual.html >> o update doc/manual/manual.rst >> o 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 <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 >> _______________________________________________ >> 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/> >> >> >> >> -- >> -- >> 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 |
