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