Re: [Apcupsd-users] apcupsd - systemd issue with pidfile

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

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