HYLAFAX-LOG(5)

📦 version 6.0.7, in debian bookworm, debian trixie, ubuntu jammy, ubuntu noble, ubuntu questing, ubuntu resolute, ubuntu stonking

✨ HYLAFAX-LOG(5) ✨

okay bestie so this one is from the File Formats Manual and it's literally the tea on your session log files 💅

🌸 NAME 🌸

log/* — session log files 🫶

💖 DESCRIPTION 💖

So the files in the log directory inside the HylaFAX spooling area? They hold all the logging/tracing info about your transmit and receive sessions. There's one file per inbound or outbound call, and the filename looks like cXXXXXXXX where XXXXXXXX is a decimal sequence number — that's what we call a communication identifier ✨

How much and what kind of tracing gets recorded for a call is decided by the SessionTracing parameter that you set in the modem configuration file — go peek at hylafax-config(5) for that.

Heads up though: logging/tracing info that the server generates outside of a session gets sent to the syslog(3) service instead, and that is controlled by the LogFacility and ServerTracing parameters in the modem configuration file. no cap.
[NB: The remainder of this manual page is out of date.] — yeah, they said it, not me 😭

🔥 SERVER OPERATION 🔥

These are the messages that may pop up when server operation tracing (bit 1) is enabled:

  • MODEM: Unknown type "%s" ignored. — the ModemType configuration parameter was not recognized. rude, honestly.
  • MODEM %s %s/%s. — this one shows up every single time the modem is reset and made ready for use. it's giving "fresh start" energy ✨
  • %s: Can not lock device.. — the UUCP lockfile for the modem couldn't be created because another process already has a lockfile in place. 💀
  • %s: Can not open modem (%m). — open(2) on the special device file for the modem failed; the error status is shown; c.f. intro(2).
  • %s: Can not open modem (timed out).. — open(2) on the special device file blocked and then timed out. usually this is because the system doesn't support a non-blocking mechanism for opening the device, and the interface it's presenting requires that carrier be present before the open can succeed.
  • %s: setuid root failed (%m). — the server process couldn't establish root privileges. usually this means the server was improperly installed 🙈
  • %s: fcntl: %m. — the server couldn't turn off the O_NDELAY bit on the open modem file descriptor after doing a non-blocking open of the modem device special file.
  • schedctl: %m. — (only on Silicon Graphics systems.) a schedctl(2) system call to set the server process priority failed.
  • sched policy=%d, priority=%d. — (only on POSIX compliant systems.) describes a setscheduler(2) system call to enhance real-time job scheduling.
  • Unable to set %s scheduling parameters: %m. — (only on SVR4-style systems.) a priocntl system call to set the server process priority failed.
  • priocntl(%s): %m. — (only on SVR4-style systems.) a priocntl system call to get the current process scheduling information failed.
  • sched policy=%d, priority=%d. — (only on POSIX-compliant systems.) indicates a possible change in the system job scheduling due to use of PriorityScheduling.
  • %s: Can not deduce modem type.. — the server couldn't reset and initialize the modem. this can be caused by so many things: wrong device filename, improper cabling, incorrect modem type, incorrect modem configuration, etc. it's giving chaos 🌪️
  • RECV: Permission denied (unacceptable client TSI). — a receive request was denied because the client got denied access through the TSI access control list mechanism; c.f. tsi(5).
  • RECV: Unable to create file "%s" for received data. — the server couldn't create a file to write the received facsimile data into. check the permission on the recvq subdirectory. also beware: the server uses tempnam(3) to create these files, and if the TMPDIR environment variable is set, it may cause the server to try to create files in a directory that isn't the recvq directory 👀
  • RECV data in "%s". — just an info message bestie; the received facsimile is being placed in the specified filename.
  • RECV: empty file "%s" deleted. — a receive operation ended without any good pages being received, so the empty file gets deleted. bye bye 🦋
  • ACCEPT TSI "%s". — the TSI received during a receive operation was accepted and the receive will continue. slay ✨
  • REJECT TSI "%s". — the TSI received during a receive operation was rejected and the receive will be aborted at the next opportunity. not slay 💀
  • POLL: Unable to create file "%s" for received data. — the server couldn't create a file for the polled data. see also above under ``RECV: Unable...''.
  • POLL: empty file "%s" deleted. — a poll operation ended without any good pages being received, so the empty file gets deleted.
  • internal muckup, lost polling request. — this message should not appear; it means the server went to do a poll but didn't find the user-specified poll request in its job description; c.f. sendq(5).
  • SEND FAILED: %s. — a transmission failed for the reason shown.
  • SEND: Can not open document file "%s", dirnum %d. — the server couldn't open the TIFF document file that was supposed to be transmitted.
  • SEND: Can not set directory in document file "%s", dirnum %d. — the server couldn't access the TIFF directory associated with the next page to transmit. the document file and directory number for the page are shown.
  • SEND: %s "%s", dirnum %d. — a transmission failed because three attempts were made to transmit the same page. the full reason for the failure is displayed along with the document filename and directory number of the page that failed. three strikes fr fr 😭
  • SEND: Document is not in a Group 3-compatible format (file %s, compression %d). — the TIFF document submitted for transmission was not compressed with CCITT T.4 compression; the TIFF compression code number is shown. this is treated as a fatal error and the job is aborted. periodt.
  • REJECT: Document was encoded with 2DMR, but client does not support this data format. — the document to be transmitted was encoded using the optional 2DMR form of the CCITT T.4 standard, but the client capabilities say this data format isn't supported. this is not a fatal error; the server will disconnect and reimage the document using 1DMH encoding.
  • REJECT: Client does not support document page width, max remote page width %u, image width %lu. — the document to be transmitted was imaged using a page width the client doesn't support. this is not a fatal error; the server will disconnect and reimage the document using the newly discovered client capabilities.
  • REJECT: High resolution document is not supported by client, image resolution %g line/mm. — the document to be transmitted was imaged using 7 line/mm, but the client only supports 3.85 line/mm. this is not a fatal error; the server will disconnect and reimage the document using the newly discovered client capabilities.
  • REJECT: Client does not support document page length, max remote page length %d mm, image length %lu rows (%.2f mm). — the document to be transmitted was imaged using a page length the client doesn't support. this is not a fatal error; the server will disconnect and reimage the document using the newly discovered client capabilities.
  • ABORT: job abort requested. — the server received a request on a command FIFO file to abort the current send/receive job. ✋
  • ANSWER: Can not lock modem device. — the server went to answer an incoming call, but found the device locked for use by another process. this is the usual scenario that happens when an outbound call is made through the modem: the echo from data written to the modem causes the fax server to wake up, only to discover the UUCP lockfile for the outgoing call. the fax server will discard its handle on the modem and wait for the lockfile to be removed. the way that it just waits... iconic patience 💅
  • ANSWER: FAX CONNECTION. — the server is initiating service for an incoming facsimile call.
  • ANSWER: DATA CONNECTION. — the server is initiating service for an incoming data call.
  • ANSWER: Data connections are not permitted. — the server rejected an incoming data call because the configured GettyArgs parameter is null.
  • ANSWER: Could not switch modem to data service. — the server couldn't initiate service for an incoming data call because of some problem setting up the modem for data use.
  • ANSWER: VOICE CONNECTION. — the server is initiating service for an incoming voice call.
  • ANSWER: Could not switch modem to voice service. — the server couldn't initiate service for an incoming voice call because of some problem setting up the modem for voice use.
  • ANSWER: %s. — an error was detected by the modem layer while setting up an incoming call.
  • GETTY: could not create. — the server couldn't create an internal data structure used to track a getty process.
  • GETTY: can not fork. — the server couldn't fork(2) a new process in order to start up the getty program.
  • runGetty::setregid: %m. and runGetty::setreuid: %m. — the server couldn't change the process identity before starting up the getty program.
  • GETTY: start pid %u, "%s". — the server has started up a getty program to service the incoming data call. the getty process identifier is displayed along with the arguments passed to the program.
  • GETTY: terminated, exit status %#o. — the server has reaped a getty process which it started up.
  • Parse error in dial string rules "%s". — the dial string rules in the specified file contain a syntax error. the dialtest(8) program should be used to debug the problem 🔍
  • Unknown answer type "%s". — the AnswerRotary configuration parameter has an invalid answer type string; consult hylafax-config(5).
  • Syntax error, missing ':' in "%s".
  • Syntax error, missing quote mark in "%s".
  • Unknown configuration parameter "%s" ignored. — a syntax error was encountered in the server configuration file or in a message received through the FIFO special file. 💀

✨ FAX PROTOCOL ✨

Okay bestie, so when you turn on the facsimile protocol tracing — that's bit 2, iykyk — these messages can pop up. They're like the group chat receipts of your fax session. Let's decode every single one, no skips, periodt. 💅

  • %s: %s (Phase B). — Something went sideways in Phase B of the Group 3 protocol processing. Not the vibe. 😭
  • Bad HDLC terminating flag received.. — During Class 1 ECM, a terminating flag for an HDLC frame was corrupt. The double dot is in the original, bestie, don't come for me. 💀
  • DELAY %u ms. — The host took a lil nap for %u milliseconds. A whole host-side pause. ✨
  • DIAL %s. — The phone number %s was dialed. ⚠️ Note: this is the number passed as an argument to the ModemDialCmd parameter, so it might not include any extra dialing prefixes that get sent to the modem. Just so you know. 🫶
  • Error sending T.30 prologue frames. — Tried to send the T.30 DCS frames and it errored out. The prologue frames said no. 🙈
  • HDLC frame length invalid. — An ECM HDLC protocol message was way too long. It's giving overachiever but in a bad way. 😭
  • HDLC frame not byte-oriented. Trailing byte: %#x. — Got an ECM HDLC message with a bit count that just doesn't fit byte-orientation. Trailing byte was %#x. Messy. 💅
  • HDLC frame too short (%u bytes). — An HDLC protocol message was too short — it needs to be at least 3 bytes outside ECM, or at least 5 bytes inside ECM. It was only %u bytes. Not enough. 🚫
  • HDLC frame with bad address field %#x. — An HDLC message had an address field that wasn't 0xff. It was %#x. Wrong address, no cap. 🏠
  • HDLC frame with bad control field %#x. — An HDLC message had an invalid control field: %#x. Control issues, literally. 😅
  • MODEM ERROR: %s. — While waiting for a modem response/result, an error popped off — like an ERROR result code. %s is the tea. ☕
  • MODEM protocol botch ("%s"), cannot parse PPR. — The Class 2 modem driver couldn't parse the post-page response code inside a +FPTS: status message. It said %s and just gave up. 💀
  • MODEM protocol botch, can not parse "%s". — Class 2 modem driver couldn't parse the session capabilities string: %s. Usually this means host-modem communication is acting up, but sometimes it's just bogus modem firmware. 🙃
  • MODEM protocol botch: OK without +FPTS:. — Class 2 modem driver hit an error in the host-modem protocol for receiving fax. While waiting for the post-page status (+FPTS:), it got an OK first. This should never happen. 🚨
  • MODEM protocol botch: +FET: without +FPTS:. — Class 2 modem driver error again. Waiting for post-page status (+FPTS:), but got a +FET: status message first. Should never happen. Periodt. 🛑
  • POLL with CIG "%s". — A poll operation is starting! The Calling Subscriber Identification string sent to the peer is %s. 📞
  • POLL: begin. — Server is starting a polled receive operation. Let's go. ✨
  • POLL: end. — Server just wrapped a polled receive operation. Done and dusted. 💅
  • POLL: %s (begin). — This error happened when kicking off the poll: %s. (begin) 🙈
  • POLL: %s (end). — This error happened while ending the poll: %s. (end) 😭
  • Problem receiving post-page HDLC frame. — Error while receiving the HDLC frame that should hold the post-page message. The post-page HDLC frame is not cooperating. 🫠
  • Problem sending TCF data. — Error while sending TCF data during training. Training arc, but make it messy. 😩
  • RECV PPM: %s. — Received this post-page message during a receive: %s. 📥
  • RECV PPR: %s. — Transmitted this post-page response during a receive: %s. 📤
  • RECV training at %s %s. — During receive, training starts at modulation %s and signalling rate %s. Lock in. 🔒
  • RECV: begin. — Server is starting a receive operation. Incoming! 📨
  • RECV: end. — Server just finished a receive operation. That's a wrap. 🎬
  • RECV: %d bytes of data. — During receive, got %d bytes of fax data for the current page. Data received, slay. 💾
  • RECV: %lu bytes, %lu total rows. — Received %lu bytes of fax data, and the running total of rows in the current page is %lu. Keeping count, bestie. 🔢
  • RECV: %s (begin). — This error hit when starting the receive: %s. (begin) 🚧
  • RECV: %s (end). — This error hit while ending the receive: %s. (end) 🛑
  • RECV: TCF %u bytes, %u%% non-zero, %u zero-run. — During training receive, the TCF had %u bytes, %u%% were non-zero, and the longest zero-run was %u. Stats check. 📊
  • RECV: reject TCF (too many non-zero, max %u%%). — TCF rejected: too many non-zero bytes, max allowed is %u%%. The Class1TCFMaxNonZero config parameter makes this call. 🚫
  • RECV: reject TCF (zero run too short, min %u). — TCF rejected: zero run too short, minimum is %u. The Class1TCFMinZero config parameter decides this. 👎
  • RECV: bad code word 0x%x, len %d, row %lu.
  • RECV: begin page. — During receive, a new page of data is about to be received on the high speed message carrier. New page, who dis? 📄
  • RECV: end page. — During receive, the page of data on the high speed message carrier just finished coming in. Page complete. ✅
  • RECV frame FCS check failed. — During ECM, an HDLC frame failed the CRC check and got marked corrupt. FCS said no. 💀
  • RECV: premature EOF. — Server didn't get <DLE><ETX> to signal the end of a page during receive. Premature EOF, awkward. 😬
  • REMOTE supports POSTSCRIPT transfer. / REMOTE does not support POSTSCRIPT transfer. — The peer either does or doesn't support Adobe POSTSCRIPT transfer extensions to T.30. These two messages tell you which. 🖨️
  • RECV: Missing EOL after 5 seconds. — Server timed out waiting for EOL after 5 seconds while receiving page data. Usually a flow control config issue is stopping data from modem to host. Fix your flow, bestie. 🌊
  • RECV: %u bytes of data, %lu total lines. — While receiving page data, got %u bytes of raw data, and the current total rows in the page is %lu. Raw data go brrr. 📈
  • RECV: %lu bad lines %lu consecutive bad lines. — After a page receive, this shows %lu bad lines and %lu consecutive bad lines. These should always be zero unless copy quality checking runs on the host. Red flag if not. 🚩
  • RECV received %u frames of block %u of page %u. — When server does Class 1 ECM, a complete block was received: %u frames in block %u of page %u. Block party. 🎉
  • RECV received assumed RCP frame with block end. — Class 1 ECM: got the block-end indicator without a proper RCP frame, so an RCP frame was assumed (or feigned). Fake it till you make it. 💅
  • RECV received frame number %u. — Class 1 ECM: received image frame number %u. Got it. 📸
  • RECV received RCP frame. — Class 1 ECM: first RCP frame received — that means the image block is done. End of an era. 🏁
  • RECV: REJECT page quality, %u%% good lines (%u%% required). — Copy quality check says no: only %u%% good lines, but %u%% required. The PercentGoodLines config parameter controls this. Page quality is not giving. 📉
  • RECV: REJECT page quality, %u-line run (max %u). — Copy quality check rejects the page: bad line run is %u lines, max allowed is %u. The MaxBadLines config parameter sets that threshold. Too many bad lines, bestie. 😭
  • RECV sent fourth PPR. — Class 1 ECM: server rejected the same image block four times in a row. Now the sender can either keep retransmitting or just end it. Fourth time's the charm? Or not. 🔁
  • REMOTE HANGUP: %s (code %s). — Modem sent a hangup status code (+FHNG: or +FHS:) to the host: %s (code %s). This means a protocol problem was found inside the modem, and usually the server can't work around it. It's giving internal drama. ☎️
  • REMOTE TSI "%s". — During receive, got this TSI: %s. It gets checked against the TSI access control list in tsi(5). Security vibes. 🔒
  • REMOTE best format %s. — Peer's "best" data format from the DIS frame: %s. And "best" here means they think 2DMMR > 2DMR with optional uncompressed data > 2DMR > 1DMH. Ranking tea. 🏆
  • REMOTE best rate %s. — Peer's best signalling rate from the DIS frame: %s. Speed check. ⚡
  • REMOTE best vres %s. — Peer's best vertical resolution from the DIS frame: %s. Vertical? More like vertical slay. 📐
  • REMOTE has document to POLL. — Peer says it has a document ready for retrieval. Polling time. 📄
  • REMOTE max %s. — Peer's max page width/length from the DIS frame: %s. Size matters. 📏
  • REMOTE supports error correction. — Peer supports the optional Error Correct Mode (ECM) according to the DIS frame. Error correction? We love to see it. ✅
  • REMOTE wants %s. — The DCS frame says the peer wants this capability: %s. Give the people what they want. 🙌
  • SEND file "%s". — About to transmit this file: %s. Sending it. 📤
  • SEND 1D RTC. / SEND 2D RTC. — Sent a 1D or 2D encoded Return To Control (RTC) packet to end the page transmission. RTC said bye. 👋
  • SEND begin page. — A page of fax data is about to be sent on the high speed message carrier. Page start, let's go. 🚀
  • SEND end page. — Page transmission on the high speed message carrier is done. Page out. 🏁
  • SEND training at %s %s. — About to send training to the peer using modulation %s and signalling rate %s. Training arc begins. 💪
  • SENT %u bytes of data. — Sent %u bytes of raw fax page data on the high speed message carrier. Data delivered. 📦
  • TRAINING failed. / TRAINING succeeded. — Peer training either failed or succeeded. When sending, it's based on a message from the peer. When receiving, it's based on analysis of the received TCF data. Training era: success or flop. 🎓
  • USE %s. — Use this session capability during send or receive: %s. It's based on the peer's best capabilities, the modem's capabilities, and — when transmitting — the document's characteristics. Capability check. ✨

📞 MODEM OPERATIONS

okay bestie so these messages show up when you turn on modem operation tracing (that's bit 3) 💅

  • MODEM set baud rate: %d baud, input flow %s, output flow %s. — the DTE-DCE communication rate got set to %d bits/sec on the host, and the flow control method you specified got set up for data coming in from the modem (input) and data going out to the modem (output) ✨
  • MODEM set baud rate: %d baud (flow control unchanged). — the DTE-DCE communication rate changed but the current flow control setup was left exactly as it was, no touchy 🙈
  • MODEM set XON/XOFF/NOW: input %s, output %s.
  • MODEM set XON/XOFF/DRAIN: input %s, output %s.
  • MODEM set XON/XOFF/FLUSH: input %s, output %s. — the software flow control setup for data moving between host and modem got changed. The NOW, DRAIN, and FLUSH actions tell you when it happened: immediately, after any pending data is transmitted to the modem, or after pending data is discarded. On input, XON/XOFF characters are either ignored (passed straight through to the server, uninterpreted) or interpreted (by the system's terminal driver, to control the flow of data). Same energy on output: XON/XOFF characters are either disabled (not generated by the terminal driver) or generated (by the terminal driver, to effect flow control of data from the modem to the host). it's giving very particular 🎀
  • MODEM input buffering enabled.
  • MODEM input buffering disabled. — on systems that buffer input data in the operating system before delivering it to applications, the server will enable and disable buffering as best it can in those cases where low input latency is critical. main character behavior fr
  • TIMEOUT: %s. — a timeout happened while doing a modem-related operation, typically reading or writing data 😭
  • Error #%u reading from modem. — a read(2) system call returned an error. This usually happens when the modem prematurely drops the DCD signal. not the DCD signal bailing early 💀

🦋 MODEM COMMUNICATION

these ones pop up when modem communication tracing (bit 4) is enabled:

  • --> [%d:%s]. — a %d-byte line of data was received from the modem. Printable data are displayed ✨
  • <-- data [%d]. — %d bytes of unprintable data were sent to the modem, typically facsimile data 🙈
  • <-- [%d:%s]. — %d bytes of printable data were sent to the modem. The data are displayed.

⏰ TIMEOUTS

these show up when timeout tracing (bit 5) is enabled:

  • start %d second timer,
  • stop timer — stop the current timeout before it expires
  • stop timer - timer expired — the current timeout expired

periodt ⏳

🔥 HDLC FRAMES

when tracing of raw HDLC frames (bit 6) is on, every frame sent and received gets logged:

  • <-- HDLC<%u:%.*s> for sent frames
  • --> HDLC<%u:%.*s> for received frames

These messages mean a %u-byte long HDLC frame was sent or received. The first byte should always be 0xff, the address field specified for dialup communication. The second byte should be a frame control field. The contents of the frame is displayed as a sequence of bytes in hexadecimal. lowkey iconic honestly 👑

💀 BINARY I/O

when binary input/output (bit 7) is traced, two types of messages get logged:

  • <-- <%u:%.*s> for data sent to the modem
  • --> <%u:%.*s> for data received from the modem

Each message means %u bytes of data were transferred. The data is displayed as a sequence of bytes in hexadecimal. hex girl summer fr 🧚

👑 SERVER STATE TRANSITIONS

bit 8 controls the tracing of state transitions in the facsimile server. There are currently eight states:

  • BASE — during startup and initialization
  • RUNNING — normal operation
  • MODEMWAIT — waiting for the modem to come ready after a reset
  • LOCKWAIT — waiting for a UUCP lockfile to be removed
  • GETTYWAIT — waiting for a getty process to terminate
  • SENDING — transmitting a facsimile
  • ANSWERING — answering an incoming telephone call
  • RECEIVING — receiving a facsimile

and the messages themselves:

  • STATE CHANGE: %s -> %s (timeout %ld). — the server is changing its internal state. The timeout (in seconds) is used when polling for asynchronous events such as a modem becoming ready.
  • STATE CHANGE: %s -> %s. — the server is changing its internal state without starting a timeout.

glow up moment ✨

🎀 QUEUE MANAGEMENT

bit 9 controls the tracing of the management of the job queue.

  • SEND NOT READY: "%s" in %s. — it was not time to send the specified job; it will be requeued for the indicated time interval.
  • SEND BLOCKED BY CONCURRENT CALL: "%s" in %s. — the specified job is blocked by another call to the same phone number; it will be requeued for the indicated time interval.
  • SEND BLOCKED BY CONCURRENT JOB: "%s" by "%s". — the specified job is blocked by another job to the same phone number; it will be requeued for the indicated time interval.
  • JOB "%s". — the specified job is about to be processed. go bestie go 🫶
  • CONVERT POSTSCRIPT: "%s". — the server is about to invoke the POSTSCRIPT interpreter to image a document; the shell command used is displayed.
  • JOB TIMER START %s. — the timer used to control scanning of the job queue is started with the displayed value.
  • JOB TIMER STOP (Q head %s tts %s). — the timer used to control scanning of the job queue is stopped. The job at the head of the queue and that job's time-to-send are displayed.
  • JOB TIMER STOP (Q empty). — the timer used to control scanning of the job queue is stopped. The job queue was found to be empty. no thoughts, queue empty 🍓

🌈 COPY QUALITY

when doing copy quality checking during a receive operation, these messages may get logged if bit 10 is set:

  • RECV/CQ: adjusting for trailing noise (%lu run). — the total number of rows of data in the received page is adjusted (downward) by %lu. This is done to handle the case where garbage data are received after the RTC, resulting in some number of consecutive bad rows after the page data.
  • RECV/CQ: Invalid %s code word, row %lu, x %d. — an invalid 1D- or 2D- T.4 code word was encountered on the specified row and horizontal offset within the row. When this occurs the server will scan for an EOL code and then regenerate the bad row with the last good row of data.
  • RECV/CQ: Premature EOL (%s), row %lu, x %d. — an EOL code was encountered before a complete row of pixels was received. When this occurs the server will discard the bad row and replace it with the last good row that was received.
  • RECV/CQ: Bad %s pixel count, row %lu, x %d. — a row of data was received with pixel count greater than the negotiated page width. When this occurs the server will discard the bad row and replace it with the last good row that was received.
  • RECV/CQ: Panic, bad %s decoding state, row %lu, x %d. — the decoder state machine was found in a bad internal state. When this occurs the server will scan for an EOL code and regenerate the row using the last good received row. bestie PANIC?? no it's fine it self-heals 💖

👀 SEE ALSO

and that's the whole page, bestie!! 🎀 this beauty is from May 12, 1996 and it's the HYLAFAX-LOG(5) manual page — yes she's an elder but she ATE and left no crumbs, we stan a vintage queen 👑💖 mwah, go read your logs ✨

📦 where this page comes from