services(5)

💖 services(5) — the manual, but make it cute ✨

okay bestie, so this is services(5) from the File Formats Manual section, and ngl it's lowkey one of the most iconic little files on your whole system. let's get into it 🫶

---

✨ NAME ✨

services — the Internet network services list. that's it, that's the vibe. a whole list of services fr fr 📋💅

---

🌸 DESCRIPTION 🌸

so services is a plain ASCII file that does the absolute most: it maps human-friendly textual names for internet services onto their underlying assigned port numbers and protocol types. like, it's the translator between "hey what's ftp" and "that's port 21, ma'am." 🦋

every networking program should look into this file to get the port number (and protocol) for its service. and the C library routines getservent(3), getservbyname(3), getservbyport(3), setservent(3), and endservent(3) are the ones that support querying this file from programs. slay, setservent, you ate 💅

port numbers are assigned by the IANA (Internet Assigned Numbers Authority), and their current policy is to assign both TCP and UDP protocols when assigning a port number. so bestie, most entries will have two entries — even for TCP-only services. it's giving "why is this duplicated" but no, it's intentional, periodt. 💖

port numbers below 1024 (the so-called "low numbered" ports) can be bound to only by root (peep bind(2), tcp(7), and udp(7)). why? because this way clients connecting to low numbered ports can trust that the service running on the port is the standard implementation, and not a rogue service run by a user of the machine. it's a whole trust thing, iykyk 🔥 well-known port numbers specified by the IANA are normally located in this root-only space.

⚠️ okay this one matters: just because an entry for a service exists in the services file does not necessarily mean that the service is currently running on the machine. the file is a list, not a status report, bestie. 💀

see inetd.conf(5) for the configuration of Internet services offered. and note that not all networking services are started by inetd(8), and so won't appear in inetd.conf(5). in particular, news (NNTP) and mail (SMTP) servers are often initialized from the system boot scripts. so don't come for inetd when your mail server shows up out of nowhere 🙈

the location of the services file is defined by _PATH_SERVICES in <netdb.h>. this is usually set to /etc/services. cute, classic, iconic 🎀

---

🧚 each line, explained (the anatomy era) 💜

each line describes one service, and is of the form:

service-name   port/protocol   [aliases ...]

where:

• service-name — is the friendly name the service is known by and looked up under. it is case sensitive. often, the client program is named after the service-name. main character energy fr 👑
• port — is the port number (in decimal) to use for this service. just a number, love her for that. 🔢
• protocol — is the type of protocol to be used. this field should match an entry in the protocols(5) file. typical values include tcp and udp. 🌈
• aliases — is an optional space or tab separated list of other names for this service. again, the names are case sensitive. don't get cute with the capitalization bestie, she's picky. ✨

either spaces or tabs may be used to separate the fields. flexible queen. 💅

comments are started by the hash sign (#) and continue until the end of the line. blank lines are skipped. so go ahead, write little notes to yourself, no one's judging 📝

the service-name should begin in the first column of the file, since leading spaces are not stripped. yes, literally the first column. no, the leading whitespace is not your friend here 😭 service-names can be any printable characters excluding space and tab. however, a conservative choice of characters should be used to minimize compatibility problems. for example, a-z, 0-9, and hyphen (-) would seem a sensible choice. stick to the basics, babe 🍓

💀 lines not matching this format should not be present in the file. (currently, they are silently skipped by getservent(3), getservbyname(3), and getservbyport(3). however, this behavior should not be relied on.) so like… they'll ignore your chaos, but don't depend on them ignoring your chaos. that's the tea.

this file might be distributed over a network using a network-wide naming service like Yellow Pages/NIS or BIND/Hesiod. network-wide, bestie, it's everywhere 🌐

---

🦋 a sample services file, for the girlies who need to see it 🌸

a sample services file might look like this:

netstat         15/tcp
qotd            17/tcp          quote
msp             18/tcp          # message send protocol
msp             18/udp          # message send protocol
chargen         19/tcp          ttytst source
chargen         19/udp          ttytst source
ftp             21/tcp
# 22 - unassigned
telnet          23/tcp

look at that formatting. chef's kiss. see how msp has both tcp and udp? and chargen has two aliases? and # 22 is just sitting there, unassigned, minding her business 💅 also notice the columns line up and the names start at column one. iconic behavior only 💖

---

🎀 FILES 🎀

• /etc/services — The Internet network services list. the main character of this whole page, honestly 👑
• <netdb.h> — Definition of _PATH_SERVICES. the header that tells you where the file lives 🗺️

---

⭐ SEE ALSO ⭐

go read these next, bestie, they're all connected:

listen(2), endservent(3), getservbyname(3), getservbyport(3), getservent(3), setservent(3), inetd.conf(5), protocols(5), inetd(8)

Assigned Numbers RFC, most recently RFC 1700, (AKA STD0002). 📚

---

and that's the whole page, no cap. 💜 this was put out by the Linux man-pages 6.20 girlies, dated 2026-02-08, and it's the services(5) manual — go forth and configure your ports responsibly, my love 🫶✨💖