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 13:06:18
|
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 |
