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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 nut-driver.service nut-server.service

%preun
%systemd_preun nut-driver.service nut-server.service

%postun
%systemd_postun_with_restart nut-driver.service nut-server.service

%posttrans
# phase 2: start upsmon again
if [ -e %restart_flag ]; then
  /bin/systemctl restart nut-monitor.service >/dev/null 2>&1 || :
  rm -f %restart_flag
else
  # maybe we did not stop it - if we reinstalled just nut-client
  /bin/systemctl try-restart nut-monitor.service >/dev/null 2>&1 || :
fi


Now, the first thing that needs to get done is remove nut-driver.service,
because that no longer exists.  But what other of the installed units should
be listed on the %systemd_* macro lines?
https://docs.fedoraproject.org/en-US/packaging-guidelines/Scriptlets/#_systemd
doesn't go into too much detail.

%systemd_post seems to just call systemctl preset - so presumably we really
only need to list those units that might be preset.

%systemd_preun calls sytemctl disable - so probably reasonable to list every
unit that might be enabled (all of them)

%systemd_postun_with_restart runs systemctl try-restart - so I thought that
this should be just "nut.target".  But that doesn't do anything if a user has
just enabled and started nut-server.  So looks like:

%systemd_postun_with_restart nut-driver.target nut-server.service

is what I want.  That seems to restart both the drivers and the server.


nut-client has:

%post client
%systemd_post nut-monitor.service

%preun client
%systemd_preun nut-monitor.service

%postun client
%systemd_postun_with_restart nut-monitor.service

but that seems fine.



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

<<attachment: smime.p7s>>

_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux