Bug#784115: inn: incoming feed is garbled
Hi Julien, On Sat, May 30, 2015 at 12:26:58PM +0200, Julien ÉLIE wrote: > So maybe the issue comes from Perl... Is it possible to disable the > Perl filters in inn.conf to see if it then works OK? I don't know where/how to disable the filters in the configuration but I disabled them immediately after starting the daemon with $ ctlinnd perl n This did not make any change, I still get those errors. > Or a large-file support issue? > Is the problem only with the amd64 package? > [...] Sorry, but I can't try this here :-( Stefan -- Für den anspruchsvollen Herren - hüpfen mit Stefan! http://www.sloganizer.de/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#784115: inn: incoming feed is garbled
Hi Stefan,
Good: inn_1.7.2q-41_amd64.deb
Fail: inn_1.7.2q-41+b1_amd64.deb
I don't know anything about the differences of these two versions.
However, 41 has been running without a single error for a couple of
hours now. When I switched to 41+b1 again, errors came within seconds.
The only change between -41 and -41b1 is a rebuild against perl 5.18,
isn't it?
So maybe the issue comes from Perl... Is it possible to disable the
Perl filters in inn.conf to see if it then works OK?
Or a large-file support issue? (I do not know if LFS also exists in INN
1.7.2 but one should note that we had issues with INN 2.x against latest
versions of Perl.)
Is the problem only with the amd64 package?
Fixing the pointer-cast-size-mismatch warnings may be helpful if that is
the case:
https://qa.debian.org/bls/packages/i/inn.html
We can see the warnings in:
https://buildd.debian.org/status/fetch.php?pkg=inn&arch=amd64&ver=1%3a1.7.2q-44%2bb2&stamp=1412186175
I notably see that one concerns Perl in the CHECK command (used for
streaming!):
nc.c: In function 'NCcheck':
nc.c:1592:24: warning: cast to pointer from integer of different size
[-Wint-to-pointer-cast]
else if ((perlrc = (char *)HandleMessageID(p)) != NULL) {
--
Julien ÉLIE
« Ce n'est pas en tournant le dos aux choses qu'on leur fait face. »
(Pierre Dac)
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#784115: inn: incoming feed is garbled
On Thu, May 28, 2015 at 06:26:36PM +0200, Stefan Froehlich wrote:
> On Thu, May 28, 2015 at 03:58:51PM +0200, Marco d'Itri wrote:
> > > Good: inn_1.7.2q-41_amd64.deb
> > > Fail: inn_1.7.2q-41+b1_amd64.deb
> I don't know anything about the differences of these two versions.
> However, 41 has been running without a single error for a couple of
> hours now. When I switched to 41+b1 again, errors came within seconds.
To justify this I did straces on these two versions. Have a look at the
two calls to writev() in the respective attachment.
strace-inn41.txt reads 2818 bytes and writes 2750. The difference of 68
bytes comes from the "TAKETHIS" string at the beginning and the
conversion of \r\n to \n, but otherwise the posting is stored without
modification.
strace-inn41+b1.txt reads 2641 bytes and writes 2502. In addition to the
expected difference mentioned above there is a part of the signature
missing:
| read(17, "[...] Beginning of Wisdom \" |
=\r\nhttp://www.zugschlus.de/\r\nNordisch by Nature | Lt. Worf, TNG \"Rightful
Heir\" | Fon: *49 621 =\r\n72739834\r\n.\r\n", 4095) = 2641
| [...]
| writev(18, [{"Path: ", 6}, {"hetzner2.epaxios.com!", 21}, {"87.106.167.149",
14}, {"!", 1}, {"[...] Beginning of Wisdom \" | =\nhttp: *49 621
=\n72739834\n", 1439}], 8) = 2502
And as always, a part of the missing text (but neither the exact
beginning nor the exact end of the gap) appears as a "bad command" in
the error message:
| sendto(3, "<61>May 30 09:11:50 innd: pasture.szaf.org:17 bad_command l Heir\"
| Fon: *49 621 =", 82, MSG_NOSIGNAL, NULL, 0) = 82
So there *must* be a significant difference between these two versions.
In fact I did not find a single article without errors in 41+b1. Could
it be helpful if I provide a dozen of them in order to find some common
pattern?
Stefan
read(17, "TAKETHIS \r\nPath:
news.szaf.org!weretis.net!feeder1.news.weretis.net!news1.tnib.de!feed.news.tnib.de!news.tnib.de!.POSTED!not-for-mail\r\nFrom:
Marc Haber \r\nNewsgroups:
de.rec.tv.technik\r\nSubject: Re: Fehlersuche in Sat-Anlage mit
Multischalter\r\nDate: Fri, 29 May 2015 20:40:24 +0200\r\nOrganization: private
site, see http://www.zugschlus.de/ for details\r\nLines: 50\r\nMessage-ID:
\r\nReferences:
\r\nMime-Version: 1.0\r\nContent-Type:
text/plain; charset=utf-8\r\nContent-Transfer-Encoding:
quoted-printable\r\nX-Trace: news1.tnib.de 1432924824 3868 37.49.103.85 (29 May
2015 18:40:24 GMT)\r\nX-Complaints-To: ab...@tnib.de\r\nX-Newsreader: Forte
Agent 6.00/32.1186\r\nXref: news.szaf.org de.rec.tv.technik:40311\r\n\r\nMarc
Haber wrote:\r\n>ich habe hier ein kleines
Problem mit der Sat-Anlage im (vermieteten)\r\n>Haus meiner Frau. Ich vermute,
der Multischalter ist kaputt.\r\n\r\nHeute war der Elektriker endlich da. Er
hat - ohne sich vorher das\r\n=46ehlerbild im Haus anzuschauen - auf dem Dach
die Sch=C3=BCssel neu\r\njustiert und alle Stecker des LNB =C3=BCberpr=C3=BCft.
Als sich dann im =\r\nHaus das\r\ngleiche Fehlerbild weiterhin zeigt,
konstatierte er einen defekten LNB\r\nund k=C3=BCndigte direkt an, dass das nur
ein =C3=9Cberspannungsschaden =\r\nsein\r\nk=C3=B6nnte und dass der Tausch des
LNB nicht auf Gew=C3=A4hrleistung =\r\nginge.\r\n\r\nBei der dann folgenden
hochnotpeinlichen Befragung verstrickte er sich\r\nderart in Widerspr=C3=BCche,
dass ich kurz in die Tischkante bei=C3=9Fen =\r\nund\r\ndanach ein wenig laut
werden musste. Der Elektriker kehrte daraufhin\r\nzu Multischalter zur=C3=BCck,
erkannte nach wenigen weiteren Minuten der\r\nMessung die zwei vertauschten
Downlink-Kabel und schwupps waren alle\r\nvier Ebenen dort, wo sie
hingeh=C3=B6ren.\r\n\r\nIch freue mich schon auf die Diskussion, wenn die
Rechnung kommt, was\r\nzweifelsfrei passieren wird.\r\n\r\nSo ganz
erkl=C3=A4ren kann ich mir meine Me=C3=9Fergebnisse in diesem =\r\nThread
mit\r\ndiesem Fehler aber nicht. Kann das jemand
erkl=C3=A4ren?\r\n\r\nInteressant finde ich =C3=BCbrigens, dass sein
Me=C3=9Fger=C3=A4t[1] =\r\nsofort angezeigt\r\nhat, welche Ebene auf diesem
Downlink-Kabel liegt. Gibt es vielleicht\r\nim Spektrom doch einen Marker, den
ein Sat-Me=C3=9Fger=C3=A4t direkt
=\r\nanzeigen\r\nkann?\r\n\r\nGr=C3=BC=C3=9Fe\r\nMarc\r\n\r\n[1] er hatte drei
dabei, weil man \"auf dem modernen Zeug\" nicht mehr\r\nalles einstellen
kann\r\n--=20\r\n-- !! No courtesy copies,
please !! =\r\n-\r\nMarc Haber | \" Questions are the |
Mailadresse im =\r\nHeader\r\nMannheim, Germany | Beginning of Wisdom \"
| =\r\nhttp://www.zugschlus.de/\r\nNordisch by Nature | Lt. Worf, TNG
\"Rightful Heir\" | Fon: *49 621 =\r\n72739834\r\n.\r\n", 8192) = 2818
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2309, ...}) = 0
lseek(7, 471040, SEEK_SET) = 471040
read(7, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", 32)
= 32
read(7,
"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\
Bug#784115: inn: incoming feed is garbled
On Thu, May 28, 2015 at 03:58:51PM +0200, Marco d'Itri wrote: > > Good: inn_1.7.2q-41_amd64.deb > > Fail: inn_1.7.2q-41+b1_amd64.deb > I do not think that this is right, because 41+b1 is just a binNMU which > is supposed to be in every way identical to 41. I don't know anything about the differences of these two versions. However, 41 has been running without a single error for a couple of hours now. When I switched to 41+b1 again, errors came within seconds. Sorry... Bye, Stefan -- Stefan - die vornehmste Ueberraschung der Poesie! http://www.sloganizer.de/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#784115: inn: incoming feed is garbled
On May 28, Stefan Froehlich wrote: > Good: inn_1.7.2q-41_amd64.deb > Fail: inn_1.7.2q-41+b1_amd64.deb I do not think that this is right, because 41+b1 is just a binNMU which is supposed to be in every way identical to 41. If the problem is really between 41 and 42 then I am screwed, because it is when the conversion to git happened. :-( -- ciao, Marco pgpU2e93kGBvP.pgp Description: PGP signature
Bug#784115: inn: incoming feed is garbled
On Sun, May 10, 2015 at 11:36:59PM +0200, Marco d'Itri wrote: > What would really help is if you could test some of the older packages > to find out which one introduced this regression: > http://snapshot.debian.org/package/inn/ Good: inn_1.7.2q-41_amd64.deb Fail: inn_1.7.2q-41+b1_amd64.deb (There is no inn_1.7.2q-42_amd64.deb available, inn_1.7.2q-43_amd64.deb and above all fail) Bye, Stefan -- Geht nicht!? Das gibt's nicht, jedenfalls nicht bei uns: Stefan. http://www.sloganizer.de/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#784115: inn: incoming feed is garbled
On May 10, Marco d'Itri wrote: > What would really help is if you could test some of the older packages > to find out which one introduced this regression: > http://snapshot.debian.org/package/inn/ BTW, you can just replace on the fly the innd binary: there is no need to downgrade/reinstall the package. -- ciao, Marco pgpO7bkBjMPxw.pgp Description: PGP signature
Bug#784115: inn: incoming feed is garbled
On May 04, Stefan Froehlich wrote: > A little bit unexpected but luckily: the problems stopped immediately > when switching to non-streaming. Not so unexpected, they are very different code paths. > > Another interesting test would be to manually start innd without using > > systemd's socket activation protocol. > This did not make any difference however. There are not many other changes, so this bu is very non-obvious. :-( > The workaround with on-streaming is sufficent for me. However, if you > want to dig into this to fix the acutal bug, I can do/change/try > whatever you want to provide you with further details. What would really help is if you could test some of the older packages to find out which one introduced this regression: http://snapshot.debian.org/package/inn/ -- ciao, Marco pgpPk31Yvn8Nn.pgp Description: PGP signature
Bug#784115: inn: incoming feed is garbled
On Mon, May 04, 2015 at 01:58:54AM +0200, Marco d'Itri wrote: > Can you check if a non-streaming feed (IHAVE only, i.e. "streaming: > false" in innfeed.conf) triggers the bug too? A little bit unexpected but luckily: the problems stopped immediately when switching to non-streaming. > Another interesting test would be to manually start innd without using > systemd's socket activation protocol. This did not make any difference however. The workaround with on-streaming is sufficent for me. However, if you want to dig into this to fix the acutal bug, I can do/change/try whatever you want to provide you with further details. Stefan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#784115: inn: incoming feed is garbled
On May 03, news wrote: > Unfortunately I have no idea WHAT would cause this and thus as > well have no suggestion how to fix it. The error is easily Me neither, I do not see any obvious changes since oldstable (and I do not use NNTP with INN 1.x): http://anonscm.debian.org/cgit/users/md/inn.git/log/ Can you check if a non-streaming feed (IHAVE only, i.e. "streaming: false" in innfeed.conf) triggers the bug too? Another interesting test would be to manually start innd without using systemd's socket activation protocol. -- ciao, Marco pgptrci_xPVwB.pgp Description: PGP signature
Bug#784115: inn: incoming feed is garbled
Package: inn
Version: 1:1.7.2q-44+b2
Severity: important
Dear Maintainer,
*** Reporter, please consider answering these questions, where appropriate ***
Inn was installed to a fresh Jessie system, minor changes have been done
to the configuration (see attachments) and a single feed was added. As soon
as the feed began to transmit, strange error messages showed up, claiming
"bad_command"s having been sent.
I did several straces of tin trying to understand what happens. One example
is shown in the attachment inn.strace. It corresponds to the log entries
| May 3 10:23:01 hetzner2 innd: pasture.szaf.org connected 17 streaming allowed
| May 3 10:23:01 hetzner2 innd: pasture.szaf.org:17 NCmode "mode stream"
received
| May 3 10:23:01 hetzner2 innd: pasture.szaf.org:17 bad_messageid
@mid.individual.net>
| May 3 10:23:01 hetzner2 innd: pasture.szaf.org:17 bad_command net>
| May 3 10:23:01 hetzner2 innd: pasture.szaf.org:17 bad_command
3e
| May 3 10:23:01 hetzner2 innd: pasture.szaf.org:17 bad_command
t>3epF3jf6ual.ividuaividuaividuaividual.net>
| May 3 10:23:01 hetzner2 innd: pasture.szaf.org:17 bad_command 63 Zeichen.
| May 3 10:23:01 hetzner2 innd: pasture.szaf.org:17 bad_command Viele s
| May 3 10:23:01 hetzner2 innd: pasture.szaf.org:17 bad_command .,
| May 3 10:23:01 hetzner2 innd: pasture.szaf.org:17 bad_command Johanne . .,
Johanne ., ohaJoha Joha Joh Johannes s . . es s . Joh...
| May 3 10:23:01 hetzner2 innd: pasture.szaf.org:17 bad_command .,
| May 3 10:23:01 hetzner2 innd: pasture.szaf.org:17 bad_command Johanne ., s
sJohansJohanneannesnnes s . . nes s . . es s . Joh...
| May 3 10:23:01 hetzner2 innd: pasture.szaf.org:17 bad_command ., sJohannes s
| May 3 10:23:01 hetzner2 innd: pasture.szaf.org:17 bad_command .
| May 3 10:23:01 hetzner2 innd: pasture.szaf.org:17 bad_command s s
| May 3 10:23:01 hetzner2 innd: pasture.szaf.org:17 closed seconds 0 accepted
1 refused 1 rejected 0
Please note especially line 48 (with TAKETHIS) and line 51. In line 49 an
article is received over the network, in line 51 the same article is
written to /var/spool/news/de/sci/mathematik/15 in the local file system.
Note the fact that 2056 bytes are read (with 42 bytes overhead) but only
1919 bytes are written. If you compare the two payloads of read() and
write(), a couple of bytes are missing in the locally stored version of
the article. (And the following "500" error messages cite text which
is close to that garbled part of the posting.
The very same thing (with similar, but not identical amounts of data
missing) happens with the major part of articles transferred. This
seems to me as a clear case of data loss - and if the server had an
outgoing feed, the wrong versions of the articles would be spread
into the world.
Unfortunately I have no idea WHAT would cause this and thus as
well have no suggestion how to fix it. The error is easily
reproducible however (in fact, I get reports every couple of
minuates), so if additional information is required, feel free
to ask.
Stefan
*** End of the template - remove these template lines ***
-- System Information:
Debian Release: 8.0
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages inn depends on:
ii bsd-mailx [mailx]8.1.2-0.20141216cvs-2
ii cron 3.0pl1-127
ii init-system-helpers 1.22
ii libc62.19-18
ii libperl5.20 5.20.2-3
ii libsystemd0 215-17
ii perl 5.20.2-3
ii perl-base [perlapi-5.20.1] 5.20.2-3
ii sendmail-bin [mail-transport-agent] 8.14.4-8
ii time 1.7-25
inn recommends no packages.
Versions of packages inn suggests:
ii gnupg 1.4.18-7
-- Configuration Files:
/etc/news/hosts.nntp changed:
localhost/t:
pasture.szaf.org:
/etc/news/inn.conf changed:
organization: Reusenet
server: localhost
/etc/news/newsfeeds changed:
ME:*,!control,!junk,!local.*/!local::
overview:*,!control.cancel:Tc,WO:/usr/lib/news/bin/overchan
reusenetfilesystemgateway:*:Tf,Wf,Freusenetfilesystemgateway:
-- no debconf information
Process 6937 attached
select(14, [3 11 13], [], NULL, {299808, 922648}) = 1 (in [3], left {299804,
958833})
accept(3, {sa_family=AF_INET, sin_port=htons(55887),
sin_addr=inet_addr("87.106.167.149")}, [16]) = 17
open("/etc/protocols", O_RDONLY|O_CLOEXEC) = 18
fstat(18, {st_mode=S_IFREG|0644, st_size=2932, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7fa3cd2ca000
read(18, "# Internet (IP) protocols\n#\n# Updated from
http://www.iana.org/assignments/protocol-numbers and
