Hello Stephen.
Stephen Isard wrote in
<[email protected]>:
|On Mon, 6 Sep 2021, Steffen Nurpmeso steffen-at-sdaoden.eu |s-nail| wrote:
|> I hope you are rich enough to have not only survived the flooding,
|> but are also able to solve the damage done!
|
|Thanks for your concern. I was fortunate and was not personally
|affected by the floods.
That is good. Coastlines will drown. In the Netherlands they are
building houses which can rise with water for many years now.
|> We will always read back the edited
|> file _if_ the size or its timestamp changed (aka whenever it seems
|> to have been modified, easy approach aka not checksum-checked),
|> _unless_ the editor exits with a non-0 exit status.
|
|I hadn't realized about that "unless", and that the non-0 status could
|be caused by a signal passed down by the parent s-nail process, as
|opposed to some event within the editor itself.
No, not really. Only ALRM, if you set a keepalive option. s-nail
gives up the terminal to the editor, which then is the foreground
process. Of course some signals are sent to the entire process
group, but nothing is "passed down".
|> If your editor would be
|>
|> #!/bin/sh -
|> trap : ALRM HUP INT QUIT TERM
|> the-real-editor "$@"
|> exit 0
|>
|> then your problem with not reading back the temporary file should
|> not happen.
|
|Right, that does seem to prevent the edit from getting lost. It is
|difficult to test, because the imap server disconnects in an
|unpredictable way, but, so far, so good.
The question of course is why your editor exits non-0. :)
|> 5.4. Autologout Timer
|>
|> If a server has an inactivity autologout timer, the duration
|> of that timer MUST be at least 30 minutes. The receipt of
|> ANY command from the client during that interval SHOULD
|> suffice to reset the autologout timer.
|
|My impression is that the disconnections are caused by something other
|than the timer timing out. Some days it happens a lot, other days not
|at all.
Then surely this is about network stability. Like i said, IMAP
cache may help you there. Automatically re-establishing
connections will not happen with the current state of IMAP and
POP3. (It implements that alarm-based keepalive entirely within
signals handlers. We do have no event loop, but the one that
ticks from prompt to prompt. And that one is in a different
galaxy if you are currently in compose mode. Yes sorry, my error
was in 2012, i should not have taken maintainership of Heirloom
mailx, but instead take OpenBSD Mail and just take from Heirloom
what is good, then come in 2014 or 2015 with a base program, and
extend it over time. So this ... lingers some more.)
...
|> With these three patches which are on [master, stable/stable,
|> stable/latest, stable/v14.9] (uff) i can wholeheartly put the
|> blame on other people.
|
|So with the patches in place, why should I need to wrap the editor with
|the script above? Is there some other way for signals to get through?
I do not know why your editor exits non-0, Stephen.
But for SIGALRM and all the job control related signals (TSTP aka
^Z etc), as well as signals send to the entire process group
S-nail and the editor are distinct regarding signals.
Btw i finally came back to the S-nail driven ML code that should
have arrived in July. But i think i will first do a little
postfix policy server in order to have a "catch early" thing for
blocked addresses and such. As part of a greylisting thing.
Then the ML, so that i can removed python2 and mailman2 from the
server. And then finally S-nail will be the thing again. Except,
maybe a PAM session-reaper module, i would really be interested in
writing an optional true session support for non-systemd driven
systems, now that my pam_xdg module says
CAVEATS
On Unix systems any “daemonized” program or script is reparented to the
program running with PID 1, most likely leaving the PAM user session
without PAM recognizing this. Yet careless such code may hold or expect
availability of resources of the session it just left, truly performing
cleanup when sessions end seems thus unwise. Since so many PAM modules
do support session tracking and cleanup pam_xdg.so readded optional sup‐
port for this.
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
