I've noticed sometimes that hpt is packing the same packet to multiple destinations.
Notice that the packet d0de9c03.fr0 is created for multiple
destinations in the same invocation of toss. Is this right?
M 20:04:46 packFile /fido/mailer/out.015/d0de9c03.fr0 created for [21:3/104 via 21:3/104] 7 20:04:46 Packing for 21:3/104 Ioram Sette, d0de9c05.pkt > ce84ee01.th0 6 20:04:46 cmd: arj a -+ -e -y /fido/mailer/out.015/ce84ee01.th0 /fido/mailer/out.tmp/d0de9c05.pkt
M 20:04:46 packFile /fido/mailer/out.015/d0de9c03.fr0 created for [21:3/102 via 21:3/102] 7 20:04:46 Leave non-packed mail for 21:3/102 Oliver Thuns, d0de9c04.pkt
M 20:04:46 packFile /fido/mailer/out.015/d0de9c03.fr0 created for [21:4/100 via 21:4/100] 7 20:04:46 Packing for 21:4/100 Hub,
d0de9c02.pkt > d0de9c03.fr0 6 20:04:46 cmd: zip -9 -j -q /fido/mailer/out.015/d0de9c03.fr0 /fido/mailer/out.tmp/d0de9c02.pkt
M 20:04:46 packFile /fido/mailer/out.015/d0de9c04.fr0 created for [21:3/105 via 21:3/105] 7 20:04:46 Packing for 21:3/105 Les Wade, d0de9c07.pkt > d0669506.fr0 6 20:04:46 cmd: zip -9 -j -q /fido/mailer/out.015/d0669506.fr0 /fido/mailer/out.tmp/d0de9c07.pkt
M 20:04:46 packFile /fido/mailer/out.015/d0de9c04.fr0 created for [21:2/116 via 21:2/116] 7 20:04:46 Packing for 21:2/116 Alterant, d0de9c03.pkt > d0de9c04.fr0 6 20:04:46 cmd: zip -9 -j -q /fido/mailer/out.015/d0de9c04.fr0 /fido/mailer/out.tmp/d0de9c03.pkt
Notice that the packet d0de9c03.fr0 is created for multiple
destinations in the same invocation of toss. Is this right?
M 20:04:46 packFile /fido/mailer/out.015/d0de9c04.fr0 created for [21:3/105 via 21:3/105] 7 20:04:46 Packing for 21:3/105 Les Wade, d0de9c07.pkt > d0669506.fr0 6 20:04:46 cmd: zip -9 -j -q /fido/mailer/out.015/d0669506.fr0 /fido/mailer/out.tmp/d0de9c07.pkt
M 20:04:46 packFile /fido/mailer/out.015/d0de9c04.fr0 created for [21:2/116 via 21:2/116] 7 20:04:46 Packing for 21:2/116 Alterant, d0de9c03.pkt > d0de9c04.fr0 6 20:04:46 cmd: zip -9 -j -q /fido/mailer/out.015/d0de9c04.fr0 /fido/mailer/out.tmp/d0de9c03.pkt
Did you run tparser?
Notice that the packet d0de9c03.fr0 is created for multipleThat would certainly be a problem but I have not seen that here.
destinations in the same invocation of toss. Is this right?
I just scanned out a message and I can see that each outbound bundle was created with a new filename, each incremented by 1.
Originally I never bundled packets into an archive, but turned that on because I noticed the same packet for multiple destinations. That
seemed to work OK, but I now see it happening with the archive...
I'm certain something isnt right, but its not consistently re-producable... (that I've worked out yet anyway...)
I'm certain something isnt right, but its not consistently
re-producable... (that I've worked out yet anyway...)
1 02:31:37 Start tossing...
...
M 02:31:38 pktFile /fido/mailer/out.tmp/d28ac803.pkt created for [21:2/116]
...
(This is the original test message.), then:
1 02:31:38 Start scanning...
...
M 02:31:38 pktFile /fido/mailer/out.tmp/d28ac803.pkt created for [21:2/116]
...
Notice that packet d28ac803.pkt was used twice, and went into the same archive d28ac80a.su0 for the same node 2/116. I'm assuming the second pkt file overwrote the first one.
hpt is invoked from a script that calls "hpt toss", then "hpt scan".
Why is the same packet number between two different runs?
It's all taking place within the same second. Maybe the current time is used to create the filename?
Notice that packet d28ac803.pkt was used twice, and went into the same archive d28ac80a.su0 for the same node 2/116. I'm assuming the second
pkt file overwrote the first one.
hpt is invoked from a script that calls "hpt toss", then "hpt scan".
Why is the same packet number between two different runs?
Why is the same packet number between two different runs?
That's the question. AFAIK I have seen all original posts and bot replies except one yesterday, I only saw the bot reply. Today I saw another pair, the origianl test message and the bot reply.
Why did that happen and does it happen only sometimes?
This is the question that needs to be answered. I'm going to send a test to the bot in a minute here. Can you show us the logging?
Why is the same packet number between two different runs?This is the question that needs to be answered. I'm going to send a test to the bot in a minute here. Can you show us the logging?
Also be aware, I've added a 1 second delay between hpt toss and hpt
scan - in case time is involved when deciding the packet name. (I
havent looked through the code to see if it is...)
I'm currently debugg with this:
LogLevels 0-9,A-N,P-T,V-Y
Anything else I should have?
Also be aware, I've added a 1 second delay between hpt toss and hpt
scan - in case time is involved when deciding the packet name. (I
havent looked through the code to see if it is...)
It is not in the code, it is in your configuration. If there is no "bundleNameStyle" in your configuration or it is set "bundleNameStyle timeStamp", then a bundle name is created from current time. It is better to use "bundleNameStyle addrsCRC32Always".
Monday June 01 2020, Deon George wrote to Alan Ianson:But that parameter does not affect the names of created .PKT's, or does it?
DG> Also be aware, I've added a 1 second delay between hpt toss and hpt
DG> scan - in case time is involved when deciding the packet name. (I
DG> havent looked through the code to see if it is...)
It is not in the code, it is in your configuration. If there is no "bundleNameStyle" in your configuration or it is set "bundleNameStyle timeStamp", then a bundle name is created from current time. It is
better to use "bundleNameStyle addrsCRC32Always".
DG> Also be aware, I've added a 1 second delay between hpt tossBut that parameter does not affect the names of created .PKT's, or
and hpt
DG> scan - in case time is involved when deciding the packet name.
(I
DG> havent looked through the code to see if it is...)
It is not in the code, it is in your configuration. If there is no
"bundleNameStyle" in your configuration or it is set
"bundleNameStyle timeStamp", then a bundle name is created from
current time. It is better to use "bundleNameStyle
addrsCRC32Always".
does it?
"bundleNameStyle" in your configuration or it is set "bundleNameStyle timeStamp", then a bundle name is created from current time. It is
better to use "bundleNameStyle addrsCRC32Always".
02:31:38 cmd: zip -9 -j -q /fido/mailer/out.015/d28ac803.su0
"bundleNameStyle" in your configuration or it is set
"bundleNameStyle timeStamp", then a bundle name is created from
current time. It is better to use "bundleNameStyle
addrsCRC32Always".
What is the reason for the timestamp default then?
Isn't there the next workaround to count up the extension? *.su0
bundles are going to be followed by *.su1 bundles. So timestamp should
be safe?
Since there was a suspiáion of a bug when the default bundleNameStyle is used, I proposed using a different bundleNameStyle. I useaddrsCRC32Always
therefore I suggested this style.
Re: Bad packets
By: Michael Dukelsky to Kai Richter on Tue Jun 02 2020 07:12 pm
Since there was a suspißion of a bug when the default
bundleNameStyle is used, I proposed using a different
bundleNameStyle. I use addrsCRC32Always therefore I suggested
this style.
Mmm, OK, this probably wont fix the problem I was experiencing.
We noticed that a hpt toss and hpt scan ran within the same second -
and generated the same PKT for a node. So when that packet was added
to the bundle, the first PKT was relaced with the second one.
I havent looked through the code, but what determines the PKT name
for a node? Is it time based? If so, then I just need to make sure
there is a 1s delay between invocations of hpt - I'm assuming that
should address it?
To make sure there is just one hpt running at the time, do you have something like this in your fidoconfig?
LockFile \bbs\husky\lock
AdvisoryLock 30
tests for a semafore that a previous invocation would create on start and delete at the end.To make sure there is just one hpt running at the time, do you haveI do only have 1 hpt running at a time. Its launched by a script that
something like this in your fidoconfig?
LockFile \bbs\husky\lock
AdvisoryLock 30
I had a look at my config:think?)
LockFile: /var/lock/lock
AdvisoryLock: off
I might just turn this on anyway, but it in theory should be redundant (I
..deltepssigmn
.. File not found, I'll load something *I* think is interesting.
To make sure there is just one hpt running at the time, do you
have something like this in your fidoconfig? LockFile
\bbs\husky\lock AdvisoryLock 30
I do only have 1 hpt running at a time. Its launched by a scriptIt doesnt harm if you turn it on. :)
that tests for a semafore that a previous invocation would create
on start and delete at the end. I had a look at my config:
LockFile: /var/lock/lock
AdvisoryLock: off
I might just turn this on anyway, but it in theory should be
redundant (I think?)
And to turn it on you should put there a positive integer, not "on".
LockFile \bbs\husky\lock
I had a look at my config:
LockFile: /var/lock/lock
Now back to my original reason for this thread - it seems that in some scenarios that the same PKT name is created for a node, and I have
seen it a couple of times using hpt toss and hpt scan.
I see it more prevelently when I set up downlinks without archive
bundles.
Before I create an environment to get some debugging, just wondering
if this has been seen before? Or if there is a known config issue or use-case that could cause it?
To make sure there is just one hpt running at the time, do you have something like this in your fidoconfig?
LockFile \bbs\husky\lock
AdvisoryLock 30
I do only have 1 hpt running at a time. Its launched by a script that
tests for a semafore that a previous invocation would create on start
and delete at the end.
Just one more idea... You say you run "hpt toss" and "hpt scan" at the same second. Would it make any difference if you run "hpt toss scan" instead of two separate commands?
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 368 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 53:42:21 |
| Calls: | 7,887 |
| Calls today: | 1 |
| Files: | 12,962 |
| Messages: | 5,788,817 |