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 09:14:24
|
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
|
