XINETD.LOG(5)

💖 XINETD.LOG(5) — the xinetd.log glow-up 💖

okay bestie, this is the File Formats Manual entry for xinetd.log, aka the receipts your xinetd drops when people come knocking. pull up a chair, we're decoding the whole thing 🎀

✨ NAME ✨

xinetd.log — the log format that xinetd uses for its services, periodt.

🌸 DESCRIPTION 🌸

so here's the vibe: a service config can ask for various degrees of logging whenever somebody tries to access that service. and when logging for a service is turned on, xinetd writes out one-line log entries, every single one of them prefixed with a timestamp. the shape is:

entry: service-id data

what shows up in data? depends on the entry, babes. the possible entry types are:

• START — fires when a server is started 🚀
• EXIT — fires when a server exits 👋
• FAIL — fires when it's literally not possible to start a server 💀
• USERID — fires if the USERID log option is used
• NOID — fires if the USERID log option is used, and the IDONLY service flag is used, and the remote end does not identify who is trying to access the service 🕵️♀️

and now, the important bit: in everything below, the stuff wrapped in brackets only shows up if the appropriate log option is used. no option, no bracket content, no cap.

A START entry has this format:

START: service-id [pid=%d] [from=%d.%d.%d.%d]

An EXIT entry has this format:

EXIT: service-id [type=%d] [pid=%d] [duration=%d(sec)]

quick lore drop: type can be either status or signal. that number is either the exit status or the signal that caused process termination. both valid, both telling a story 💅

A FAIL entry has this format:

FAIL: service-id reason [from=%d.%d.%d.%d]

and the possible reasons are:

• fork — a certain number of consecutive fork attempts failed (this number is a configurable parameter)
• time — the time check failed ⏰
• address — the address check failed 🏠
• service_limit — the allowed number of server instances for this service would be exceeded
• process_limit — a limit on the number of forked processes was specified and it would be exceeded

A DATA entry has this format:

DATA: service-id data

the data that gets logged depends on the service:

• login — remote_user=%s local_user=%s tty=%s
• exec — remote_user=%s verify=status command=%s
  • and the possible status values are:
    • ok — the password was correct ✅
    • failed — the password was incorrect ❌
    • baduser — no such user 🫥
• shell — remote_user=%s local_user=%s command=%s
• finger — received string or EMPTY-LINE

A USERID entry has this format:

USERID: service-id text

and the text is the response of the identification daemon at the remote end, excluding the port numbers (which are included in the response). yeah, they're in there, we're just not showing them here. iykyk.

A NOID entry has this format:

NOID: service-id IP-address reason

🦋 SEE ALSO 🦋

• xinetd(1L)
• xinetd.conf(5)

and that's the whole page, bestie — go forth and read your logs like the main character you are 👑💜

28 April 1993 — yeah she's an oldie but she's still iconic, mwah 🎀✨