Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.comm.software.newsreader > #13765 > unrolled thread

Tin am Leben halten

Back to article view | Back to de.comm.software.newsreader

Contents

  Tin am Leben halten Roland White <rp.white@e-mail.de> - 2026-05-12 07:33 +0000
    Re: Tin am Leben halten Wolfgang Bauer <wolfgang-bauer@mein.gmx> - 2026-05-12 10:20 +0200
    Re: Tin am Leben halten Urs Janßen <urs@oxycon.tin.org> - 2026-05-12 08:28 +0000
      Re: Tin am Leben halten Roland White <rp.white@e-mail.de> - 2026-05-12 11:41 +0000
    Re: Tin am Leben halten Ralph Aichinger <ra@h5.or.at> - 2026-05-12 10:57 +0000
      Re: Tin am Leben halten Roland White <rp.white@e-mail.de> - 2026-05-12 11:48 +0000
        Re: Tin am Leben halten Urs Janßen <urs@oxycon.tin.org> - 2026-05-12 17:44 +0000
          Re: Tin am Leben halten "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2026-05-12 20:24 +0200
            Re: Tin am Leben halten Urs Janßen <urs@oxycon.tin.org> - 2026-05-12 18:41 +0000
            Re: Tin am Leben halten Urs Janßen <urs@oxycon.tin.org> - 2026-05-12 19:10 +0000
            Re: Tin am Leben halten Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-05-13 17:49 +0200
    Re: Tin am Leben halten Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2026-05-13 20:12 +0000
      Re: Tin am Leben halten Urs Janßen <urs@oxycon.tin.org> - 2026-05-13 20:54 +0000
        Re: Tin am Leben halten Thomas Hochstein <thh@thh.name> - 2026-05-14 07:37 +0200

#13765 — Tin am Leben halten

Nein, ergugelt habe ich mir eine ganze Menge, auch nützliches, aber
irnkwie scheint jeder sowieso schon immer zu wissen, wie zu vermeiden
ist, daß sich tin nach einigen Minuten „aufhängt“, sprich: die
Verbindung abbricht, sich gar nichts mehr tut und ein Neustart nötig
wird (besonders lästig beim Verfassen längerer Postings, die dann
komplett im Nirwana verschwinden... #-).

Kurz: Wie halte ich tin alive?

TIA,

R-

-- 
Frihär hädd's des nedt gewwe! (Alt-hessische Weisheit)

[toc] | [next] | [standalone]

#13766

Roland White schrieb:
> Nein, ergugelt habe ich mir eine ganze Menge, auch nützliches, aber
> irnkwie scheint jeder sowieso schon immer zu wissen, wie zu vermeiden
> ist, daß sich tin nach einigen Minuten „aufhängt“, sprich: die
> Verbindung abbricht, sich gar nichts mehr tut und ein Neustart nötig
> wird (besonders lästig beim Verfassen längerer Postings, die dann
> komplett im Nirwana verschwinden... #-).
> 
> Kurz: Wie halte ich tin alive?
> 
Ich kann es nicht nachvollziehen. Tin und Editor sind 10 Minuten
offen und Tin ist nicht abgestürzt.

Freundliche Grüße
Wolfgang Bauer
-- 
Wenn die Guten nicht kämpfen, werden die Schlechten siegen.

[toc] | [prev] | [next] | [standalone]

#13767

Roland White wrote:
> ist, daß sich tin nach einigen Minuten „aufhängt“, sprich: die
> Verbindung abbricht, sich gar nichts mehr tut und ein Neustart nötig

tin trennt die verbidung nur, wenn auf eine anfrage an den server
zeitnah keine antwort kommt[1]. der _server_ trennt die verbindung
wenn eine zeitlang keine anfrage vom server kommt. 

[1] laesst sich (etwas)[2] mit -t bzw. nntp_read_timeout_secs
    steuern.
[2] TCP_USER_TIMEOUT wird automatisch bestimmt, das laesst sich
    ohne den code anzufassen (nntplib.c:33) nicht einfach
    abstellen.[3]
[3] dein tin ist zu alt dafuer, das gibt's erst mit 2.6.5.
    ohne kann es _sehr_ lange dauern bis tin mitbekommt,
    dass die verbindung weg ist (mit kannst du dir die
    werte via ConnectionInfo 'J' anzeigen lassen).

gegen das trennen von server kann[4] ein reread_active_file_secs
kleiner als das timeout des servers helfen (ueblich sind so ca.
10 min., mal mehr mal weniger) und/oder auto_reconnect=ON.

[4] das wird allerdings nur getriggert wenn eine eingabe in tin
    erfolgt (scrollen reicht); das ist (absichtlich) kein echtes
    keep-alive.

> Kurz: Wie halte ich tin alive?

auf die aktuelle version updaten und auto_reconnect=ON setzten.
reread_active_file_secs verursacht traffic und (etwas) last auf
server (und bei sehr grossem active und/oder sehr langsamer
leitung dauert es halt).

[toc] | [prev] | [next] | [standalone]

#13769

Urs Janßen <urs@oxycon.tin.org> schrieb:
> Roland White wrote:
>> ist, daß sich tin nach einigen Minuten „aufhängt“, sprich: die
>> Verbindung abbricht, sich gar nichts mehr tut und ein Neustart nötig
> 
> tin trennt die verbidung nur, wenn auf eine anfrage an den server
> zeitnah keine antwort kommt[1]. der _server_ trennt die verbindung
> wenn eine zeitlang keine anfrage vom server kommt. 

[...]

>> Kurz: Wie halte ich tin alive?
> 
> auf die aktuelle version updaten und auto_reconnect=ON setzten.
> reread_active_file_secs verursacht traffic und (etwas) last auf
> server (und bei sehr grossem active und/oder sehr langsamer
> leitung dauert es halt).

Ah, prima! Danke und Gruß

R- 

-- 
Zielbar in der opaken Fäulnis gelbt die strudelnde Nullhaftigkeit
allgegenwärtigen Gleichs.

[toc] | [prev] | [next] | [standalone]

#13768

Roland White <rp.white@e-mail.de> wrote:
> Nein, ergugelt habe ich mir eine ganze Menge, auch nützliches, aber
> irnkwie scheint jeder sowieso schon immer zu wissen, wie zu vermeiden
> ist, daß sich tin nach einigen Minuten „aufhängt“, sprich: die
> Verbindung abbricht, sich gar nichts mehr tut und ein Neustart nötig
> wird (besonders lästig beim Verfassen längerer Postings, die dann
> komplett im Nirwana verschwinden... #-).
> 
> Kurz: Wie halte ich tin alive?

Verwendest du tin lokal (auf dem Rechner an dem die Tastatur hängt, 
oder per ssh?

In Jahrzehnten der Nutzung von tin hat sich tin bei mir noch sehr
sehr selten aufgehängt, wenn, dann immer eine ssh-Verbindung zum
Server auf dem tin läuft.

Welches OS? Welches Terminal? Gibt es Fehlermeldungen?

/ralph
> 
> TIA,
> 
> R-
> 

[toc] | [prev] | [next] | [standalone]

#13770

Ralph Aichinger <ra@h5.or.at> schrieb:
> Roland White <rp.white@e-mail.de> wrote:
>> Nein, ergugelt habe ich mir eine ganze Menge, auch nützliches, aber
>> irnkwie scheint jeder sowieso schon immer zu wissen, wie zu vermeiden
>> ist, daß sich tin nach einigen Minuten „aufhängt“, sprich: die
>> Verbindung abbricht, sich gar nichts mehr tut und ein Neustart nötig
>> wird (besonders lästig beim Verfassen längerer Postings, die dann
>> komplett im Nirwana verschwinden... #-).
>> 
>> Kurz: Wie halte ich tin alive?
> 
> Verwendest du tin lokal (auf dem Rechner an dem die Tastatur hängt, 
> oder per ssh?

Lokal.
 
> In Jahrzehnten der Nutzung von tin hat sich tin bei mir noch sehr
> sehr selten aufgehängt, wenn, dann immer eine ssh-Verbindung zum
> Server auf dem tin läuft.

Ich hatte „aufhängt“ ganz bewußt in Anführungsstrichen geschrieben, da
ich schon vermutet hatte, daß es - wie Urs erklärt hat - wohl eher am
Server liegt, der die Verbindung unterbricht (war mit dem slrn genauso,
nur konnte dieser, wenn auch mit einiger Verzögerung, die Verbindung
wieder herstellen).
 
> Welches OS? Welches Terminal? Gibt es Fehlermeldungen?

Linux/7.0.5-1-default (x86_64), opensuse Tumbleweed
qterminal
Nein.

R-

-- 
Zielbar in der opaken Fäulnis gelbt die strudelnde Nullhaftigkeit
allgegenwärtigen Gleichs.

[toc] | [prev] | [next] | [standalone]

#13771

Roland White wrote:
> Server liegt, der die Verbindung unterbricht (war mit dem slrn genauso,
> nur konnte dieser, wenn auch mit einiger Verzögerung, die Verbindung
> wieder herstellen).

das sollte der angestaubte tin von dir mit auto_reconnect=ON
auch hinbekommen, dauert halt:

- server kick die verbindung wegen zu lange idle
- tin sendet was (z.b. POST) und wartet auf den server, und
  wartet, und wartet ...
- irgendwann (kann dauern) kommt dann der default tcp timeout
- jetzt verbindet sich tin entweder neu oder beendet sich

das sollte ab 2.6.5 mit setsockopt() (Linux > 2.6.37 und OSX >
10.6) deutlich schneller gehen.
der netzwerk code ist halt von ~1991 und eher auf portabel
ausgelegt.

[toc] | [prev] | [next] | [standalone]

#13772

On 2026-05-12 19:44, Urs Janßen <urs@oxycon.tin.org> wrote:
> Roland White wrote:
>> Server liegt, der die Verbindung unterbricht (war mit dem slrn genauso,
>> nur konnte dieser, wenn auch mit einiger Verzögerung, die Verbindung
>> wieder herstellen).
>
> das sollte der angestaubte tin von dir mit auto_reconnect=ON
> auch hinbekommen, dauert halt:
>
> - server kick die verbindung wegen zu lange idle
> - tin sendet was (z.b. POST) und wartet auf den server, und
>   wartet, und wartet ...

Wenn der Server die Verbindung kickt, sollte der der Tin da sofort einen
Fehler bekommen (vermutlich Connection Reset by Peer) und nicht warten.

Ewiges Warten tritt üblicherweise auf, wenn ein Firewall dazwischen die
Connection kappt und "aus Sicherheitsgründen" die Pakete einfach
kommentarlos fallen lässt.

        hjp

[toc] | [prev] | [next] | [standalone]

#13773

Peter J. Holzer wrote:
> Wenn der Server die Verbindung kickt, sollte der der Tin da sofort einen
> Fehler bekommen (vermutlich Connection Reset by Peer) und nicht warten.

du darfst dir gerne den netzwerkcode der alle flavours abhandeln will
(bsd, sysv, osi/tli, decnet) in nntplib.c angucken :-)

[toc] | [prev] | [next] | [standalone]

#13774

Peter J. Holzer wrote:
> Wenn der Server die Verbindung kickt, sollte der der Tin da sofort einen
> Fehler bekommen (vermutlich Connection Reset by Peer) und nicht warten.

du darfst dir gerne den netzwerkcode der alle flavours abhandeln will
(bsd, sysv, osi/tli, decnet) in nntplib.c angucken :-)

[toc] | [prev] | [next] | [standalone]

#13775

"Peter J. Holzer" <hjp-usenet4@hjp.at> wrote:
>Wenn der Server die Verbindung kickt, sollte der der Tin da sofort einen
>Fehler bekommen (vermutlich Connection Reset by Peer) und nicht warten.

Ich würde als erstes Mal einen tcpdump mitlaufen lassen und schauen
was in dem betreffenden Moment zwischen Sever und Client passiert.

Grüße
Marc
-- 
----------------------------------------------------------------------------
Marc Haber         |   " Questions are the         | Mailadresse im Header
Rhein-Neckar, DE   |     Beginning of Wisdom "     | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

[toc] | [prev] | [next] | [standalone]

#13776

On Tue, 12 May 2026 09:33:08 Roland White wrote:
> (besonders lästig beim Verfassen längerer Postings, die dann
> komplett im Nirwana verschwinden... #-).

Immerhin nicht komplett: Die Artikel werden ja ganz normal im
Dateisystem gespeichert. Man kann den tin neu starten, noch einmal
auf Beantworten gehen und dann den aktuellen Puffer durch die Datei
.article.OLDPID ersetzen.

Nicht überbordend elegant, aber immer noch besser, als alles noch
einmal zu schreiben.

Servus,
   Stefan

-- 
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Stefan konnte immer schon mehr als Vergnügen machen!
(Sloganizer)

[toc] | [prev] | [next] | [standalone]

#13777

Stefan Froehlich wrote:
> Immerhin nicht komplett: Die Artikel werden ja ganz normal im
> Dateisystem gespeichert. Man kann den tin neu starten, noch einmal

der lezte fehlgeschlagene artikel sollte sich in
${TIN_HOMEDIR:-"$HOME"}/dead.article befinden und bei
gesetztem keep_dead_articles auch noch in
${TIN_HOMEDIR:-"$HOME"}/dead.articles wenn das nicht der fall
ist, dann ${TIN_HOMEDIR:-"$HOME"}/.article[.OLDPID]

> Nicht überbordend elegant, aber immer noch besser, als alles noch
> einmal zu schreiben.

vorher mal updaten, z.b. wegen
|      ADD. set TCP_USER_TIMEOUT or TCP_CONNECTIONTIMEOUT and
|           TCP_RXT_CONNDROPTIME if available
und autore_connect setzten.

und so zum 40zigsten koennte man dann auch mal den TLI und DecNET
code entsorgen - wenn es dann noch usenet gibt.

[toc] | [prev] | [next] | [standalone]

#13778

Urs Janßen schrieb:

> und so zum 40zigsten koennte man dann auch mal den TLI und DecNET
> code entsorgen - wenn es dann noch usenet gibt.

Die fünf Jahre wird das Usenet wohl schon noch durchhalten ...

[toc] | [prev] | [standalone]

Back to top | Article view | de.comm.software.newsreader

csiph-web