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 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
