Re: Need help with nut systemd scriptlets and multiple services and targets

2023-04-07 Thread Robert Nichols 

On 4/7/23 16:17, Orion Poplawski wrote:

On 4/6/23 21:27, Robert Nichols wrote:

...

The user needs to enable nut-driver-enumerator.service if there is any UPS
hardware monitored by this system (i.e., not needed if this is a "secondary"
system and some other "primary" system is actually monitoring the UPS).


Why should the user have to explicitly enable nut-driver-enumerator.service?
It does seem necessary for some reason to enable it to have it start with
nut.target below.  But I don't understand why.  It has PartOf=nut.target:

[Unit]
# This unit starts early in system lifecycle to set up nut-driver instances.
# End-user may also restart this unit after editing ups.conf to automatically
# un-register or add new instances as appropriate.
Description=Network UPS Tools - enumeration of configure-file devices into
systemd unit instances
After=local-fs.target
Before=nut-driver.target
PartOf=nut.target

just like nut-server.service:


But nut.driver.target is an empty target that contains no "wants". If you
enable nut-driver-enumerator.service, that generates a link in
/etc/systemd/system/nut.target.wants, so the enumerator gets started when
nut.target starts. Unless the user explicitly enables the enumerator
service, nothing starts it.

I had some discussion of this with the developer on
.
The developer seems to feel it's just a documentation issue. The docs
currently imply that the enumerator starts automatically.

--
Bob Nichols "NOSPAM" is really part of my email address.
Do NOT delete it.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Need help with nut systemd scriptlets and multiple services and targets

2023-04-07 Thread Orion Poplawski 
On 4/6/23 21:27, Robert Nichols wrote:
> On 4/6/23 17:56, Orion Poplawski wrote:
>> The nut package has a number of different systemd units:
>>
>>   /usr/lib/systemd/system/nut-driver-enumerator.path
>>   /usr/lib/systemd/system/nut-driver-enumerator.service
>> '/usr/lib/systemd/system/nut-driver@.service'
>>   /usr/lib/systemd/system/nut-driver.target
>>   /usr/lib/systemd/system/nut-server.service
>>   /usr/lib/systemd/system/nut.target
>>
>> And I have a number of questions about how to handle them:
>>
>> * I think we want a preset to automatically enable and start
>> nut-driver-enumerator.path.  This monitors /etc/ups/ups.conf and runs
>> nut-driver-enumerator.service when it does.  It also has:
>>
>> [Install]
>> WantedBy=nut.target
>>
>> Does that seem appropriate?  Is is possible to start it immediately after
>> install in %post?
> 
> You don't want to start _anything_ until the user has done the rather 
> extensive
> editing required in the config files to tell the package what hardware to look
> for and what to do.

I still think that auto-enabling nut-driver-enumerator.path may be the right
thing to do.  That way when a user edits /etc/ups/ups.conf the needed
nut-driver-enumerator.service run is done.  Or, see below..

>> * What is a user expected to do to enable and start "nut"?  It seems like:
>>
>> systemctl enable nut.target
>> systemctl start nut.target
> 
> The user needs to enable nut-driver-enumerator.service if there is any UPS
> hardware monitored by this system (i.e., not needed if this is a "secondary"
> system and some other "primary" system is actually monitoring the UPS).

Why should the user have to explicitly enable nut-driver-enumerator.service?
It does seem necessary for some reason to enable it to have it start with
nut.target below.  But I don't understand why.  It has PartOf=nut.target:

[Unit]
# This unit starts early in system lifecycle to set up nut-driver instances.
# End-user may also restart this unit after editing ups.conf to automatically
# un-register or add new instances as appropriate.
Description=Network UPS Tools - enumeration of configure-file devices into
systemd unit instances
After=local-fs.target
Before=nut-driver.target
PartOf=nut.target

just like nut-server.service:

[Unit]
Description=Network UPS Tools - power devices information server
After=local-fs.target network.target nut-driver.target
# We don't Require drivers to be successfully started! This would be
# a change of behavior compared to init SysV, and could prevent from
# accessing successfully started, at least to audit a system.
Wants=nut-driver.target
# The `upsd` is a networked service (even if bound to a `localhost`)
# so it requires that the OS has some notion of networking already.
# Extending the unit does not require *this* file to be edited, you
# can instead drop in an additional piece of configuration, e.g. add
# a `/etc/systemd/system/nut-server.service.d/network.conf` with:
#   [Unit]
#   Requires=network-online.target
#   After=network-online.target
Requires=network.target
Before=nut-monitor.service
PartOf=nut.target

but nut-server.service is started automatically when nut.target is started
despite not being explicitly enabled itself:

# systemctl status nut-server
● nut-server.service - Network UPS Tools - power devices information server
   Loaded: loaded (/usr/lib/systemd/system/nut-server.service; disabled;
vendor preset: disabled)
   Active: active (running) since Fri 2023-04-07 14:34:09 MDT; 1min 27s ago

I would have hoped it would be fine to enable nut-driver-enumerator.service
automatically via presets - but after some testing it looks like their are
situations where it can hang or fail which is not good.

This step of needing to enable nut-driver-enumerator.service seems like a very
unfortunate step and would be nice to avoid if possible.


> Then, running "systemctl enable nut.target" will start the package on the
> next boot. Include "--now", or run "systemctl start nut.target" to start it
> immediately.
> 
> But all of that has to wait until the user has made the necessary edits in
> the config scripts in /etc/ups.conf and edited the /usr/bin/upssched-cmd
> script to set up any additional actions (e.g., notifications, etc) that are
> wanted.
> 
>> Would do the trick, but I don't think it's very intuitive - most users think
>> in terms of service units I think.
> 
> Overall, it's a pretty user-unfriendly package. Some things that used to
> "Just Work" back in the days of CentOS 6 need manual configuration now.

Yeah, and unfortunately some packaging mistakes have been making it trickier
as well.

I also still need to address the scriptlets:

%pre
# do not let upsmon run during upgrade rhbz#916472
# phase 1: stop upsmon before upsd changes
if [ "$1" = "2" ]; then
  rm -f %restart_flag
  /bin/systemctl is-active nut-monitor.service >/dev/null 2>&1 && touch
%restart_flag ||:
  /bin/systemctl stop nut-monitor.service >/dev/null 2>&1
fi

%post
%systemd_post

Re: Need help with nut systemd scriptlets and multiple services and targets

2023-04-06 Thread Robert Nichols 

On 4/6/23 17:56, Orion Poplawski wrote:

The nut package has a number of different systemd units:

  /usr/lib/systemd/system/nut-driver-enumerator.path
  /usr/lib/systemd/system/nut-driver-enumerator.service
'/usr/lib/systemd/system/nut-driver@.service'
  /usr/lib/systemd/system/nut-driver.target
  /usr/lib/systemd/system/nut-server.service
  /usr/lib/systemd/system/nut.target

And I have a number of questions about how to handle them:

* I think we want a preset to automatically enable and start
nut-driver-enumerator.path.  This monitors /etc/ups/ups.conf and runs
nut-driver-enumerator.service when it does.  It also has:

[Install]
WantedBy=nut.target

Does that seem appropriate?  Is is possible to start it immediately after
install in %post?


You don't want to start _anything_ until the user has done the rather extensive
editing required in the config files to tell the package what hardware to look
for and what to do.


* What is a user expected to do to enable and start "nut"?  It seems like:

systemctl enable nut.target
systemctl start nut.target


The user needs to enable nut-driver-enumerator.service if there is any UPS
hardware monitored by this system (i.e., not needed if this is a "secondary"
system and some other "primary" system is actually monitoring the UPS).

Then, running "systemctl enable nut.target" will start the package on the
next boot. Include "--now", or run "systemctl start nut.target" to start it
immediately.

But all of that has to wait until the user has made the necessary edits in
the config scripts in /etc/ups.conf and edited the /usr/bin/upssched-cmd
script to set up any additional actions (e.g., notifications, etc) that are
wanted.


Would do the trick, but I don't think it's very intuitive - most users think
in terms of service units I think.


Overall, it's a pretty user-unfriendly package. Some things that used to
"Just Work" back in the days of CentOS 6 need manual configuration now.

--
Bob Nichols "NOSPAM" is really part of my email address.
Do NOT delete it.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Need help with nut systemd scriptlets and multiple services and targets

2023-04-06 Thread Orion Poplawski 
The nut package has a number of different systemd units:

 /usr/lib/systemd/system/nut-driver-enumerator.path
 /usr/lib/systemd/system/nut-driver-enumerator.service
'/usr/lib/systemd/system/nut-driver@.service'
 /usr/lib/systemd/system/nut-driver.target
 /usr/lib/systemd/system/nut-server.service
 /usr/lib/systemd/system/nut.target

And I have a number of questions about how to handle them:

* I think we want a preset to automatically enable and start
nut-driver-enumerator.path.  This monitors /etc/ups/ups.conf and runs
nut-driver-enumerator.service when it does.  It also has:

[Install]
WantedBy=nut.target

Does that seem appropriate?  Is is possible to start it immediately after
install in %post?


* What is a user expected to do to enable and start "nut"?  It seems like:

systemctl enable nut.target
systemctl start nut.target

Would do the trick, but I don't think it's very intuitive - most users think
in terms of service units I think.

It also doesn't seem to work without nut-driver-enumerator.service having run
to configure and start the nut-driver@UPS.service instance.  Because starting
nut.target does not appear to run nut-driver-enumerator.service, at least on 
EL8.


* What systemd scriptlets should get called?  Do we call them on target or
path units as well?  The packaging guidelines don't seem to mention those
types specifically, but I do see them in various spec files.


Thank you very much for any guidance.

-- 
Orion Poplawski
IT Systems Manager 720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/


smime.p7s
Description: S/MIME Cryptographic Signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue