Sounds correct to me too, after browsing the code a bit recently when I was adding the new names for old concepts.
As for login the word, here a client (upsmon) logs into the server (upsd) to be counted and informed about FSD due to a particular UPS going critical, if I got that correctly. Logins to web sites also don't give us a shell ;) On Thu, Jun 24, 2021, 15:22 Manuel Wolfshant <[email protected]> wrote: > On 6/24/21 3:48 PM, Roger Price wrote: > > During the ISE review of the proposed RFC, the IETF editor has asked > > for clarification of the LOGIN command, since he, like most people, > > assumes that "LOGIN" means something like "login to a shell". > > > > The Developer Guide Chapter 9 > > https://networkupstools.org/docs/developer-guide.chunked/ar01s09.html > > "Network Protocol Information" says > > > > 9.9. LOGIN > > > > LOGIN <upsname> Response: OK (upon success) or various errors > > > > Note This requires "upsmon slave" or "upsmon master" in upsd.users > > > > Use this to log the fact that a system is drawing power from this > > UPS. The > > upsmon master will wait until the count of attached systems reaches 1 > > - itself. > > This allows the slaves to shut down first. > > > > Note You probably shouldn’t send this command unless you are upsmon, > > or a > > upsmon replacement. > > > > 9.4 GET NUMLOGINS <upsname> > > Response: NUMLOGINS <UPSNAME> <VALUE> > > > > where <value> is the number of clients which have done LOGIN for this > > UPS. This > > is used by the master upsmon to determine how many clients are still > > connected > > when starting the shutdown process. > > > > I propose saying: > > > > Figure 4 "The client" > > ,--------------------,---------------------, > > ,-----, | UPS <-Commands Primary | > > | |---| Attachment | Management | Primary > > | |===| Daemon Responses-> Daemon | > > | | '--------------------'---------------------' > > | UPS | ^ > > | | '<-Commands---Responses->, > > | | v > > | | ,--------------,-----------------, > > | |============| | Secondary | > > /-----\ | | Management | Secondary > > | | Daemon | > > '--------------'-----------------' > > > > LOGIN is not the conventional user access to a shell. In a > > configuration such as Figure 4 in which a UPS protects more than one > > system, the Primary (2.8) Management Daemon (2.6), upsmon, needs to > > know how many Secondaries (2.9) are currently "active", i.e. powered > > by the UPS, either on wall or battery power. The Attachment Daemon > > (2.1), upsd, supports this by keeping a count of all the "active" > > systems powered by a UPS. The count is initialised, one secondary at a > > time by the LOGIN command, which should be understood as "count this > > secondary as active". LOGIN is one of a trio of commands for Secondary > > (2.9) counting: command LOGOUT (4.2.7) decrements the count and a > > Management Daemon (2.6), upsmon, may read the count at any time using > > command NUMLOGINS (4.2.2.3). > > > > The LOGIN command is also sent to the Attachment Daemon (2.1), upsd, > > for the Primary (2.8) so during normal, fully protected operation, the > > count is 1 (the Primary (2.8)) + the number of Secondaries (2.9). > > During a full system shutdown, the count drops as each Secondary (2.9) > > Management Daemon (2.6), upsmon, executes command LOGOUT (4.2.7) > > during its own shutdown. When the count drops to 1, only the Primary > > (2.8) is "active" and it knows that all the Secondaries (2.9) have > > shut down. > > > > Is that correct? > > I did not look at the code but based on my experience with the > application, your proposal sounds very good to me. > > > > > _______________________________________________ > Nut-upsuser mailing list > [email protected] > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser >
_______________________________________________ Nut-upsuser mailing list [email protected] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
