Nп/п : 67 из 90
 От   : Mike Powell                         1:2320/107        27 апр 26 10:08:54
 К    : NICK BOEL                                             27 апр 26 18:12:02
 Тема : htick "issue"
----------------------------------------------------------------------------------
                                                                                 
@MSGID: 60.husky@1:2320/107 2e54b242
@REPLY: 1:154/700 69eead0c
@TZUTC: -0500
@PID: Synchronet 3.21a-Linux master/123f2d28a Jul 12
2025 GCC 12.2.0
@TID: SBBSecho 3.28-Linux master/123f2d28a Jul 12
2025 GCC 12.2.0
@BBSID: CAPCITY2
@CHRS: ASCII 1
@FORMAT: flowed
> Running your tic processor once a day (or even every 10 minutes) is exactly wh
> this happened. It doesn`t happen very often, but it happens nonetheless. htick
> (or even tickit) should run as soon as a tic file is received, if you want to
> avoid this in the future.

No it is not exactly why.  Dates that a month or more apart are > 10 minutes
apart.

> So you haven`t cleared bad packets, or bad/old tics from your inbound since at
> least September? This is probably not a binkd or tic processor issue, at this
> point.

If the issue isn`t logged (which is wasn`t until this time) how would I
know to clear them from the inbound?  Now that I am running htick and errors
actually show up, I have.

My initial question was "is there a way to tell htick to go ahead and
process the files" when it gets an error that, to me, isn`t important.

The answer is "no" so the question is answered.

The issue with not logging... or why the earlier TIC files were deleted while
the files were left unprocessed... is probably a tickit issue so I think it is
off topic here.  tickit doesn`t run here any more so it is also irrelevant.

I still maintain that the REPLACES not matching the case of the files
received is eventually going to cause a problem... whether it just be
duplicate files or something else remains to be seen.  I will worry about
it when it happens again.  I don`t think that htick is the cause of that,
either, as I doubt it changes file cases on its own, so it is probably also
off topic here.


 * SLMR 2.1a * Strip mining prevents forest fires.
--- SBBSecho 3.28-Linux
 * Origin: Capitol City Online (1:2320/107)
SEEN-BY: 19/10 50/109 104/117 119 114/10 120/616
153/757 154/10 30 50 700
SEEN-BY: 218/840 220/20 90 221/1 6 360 226/18 20
44 50 280/464 301/1 335/364
SEEN-BY: 341/66 234 452/28 166 460/58 463/68
2320/105 106 107 304 3634/12
SEEN-BY: 5000/111 5010/352 5015/46 5020/715 828 846
848 1042 4441 12000
SEEN-BY: 5030/49 1081 5053/51 5061/133 5075/128
5083/444 12320/7
@PATH: 2320/107 105 154/10 221/6 5020/1042 4441



   GoldED+ VK   │                                                 │   09:55:30    
                                                                                
В этой области больше нет сообщений.

Остаться здесь
Перейти к списку сообщений
Перейти к списку эх