getent: Usage, Options & Common CI Errors
getent looks up entries in system databases (hosts, passwd, group, services) via NSS.
getent is the right way to resolve a hostname or check a user/group the way the system actually does it - through NSS, honoring /etc/hosts and DNS. It is invaluable for debugging CI name-resolution failures.
What it does
getent queries the Name Service Switch (NSS) databases - hosts, passwd, group, services, networks - using the same resolution path the OS uses, which includes /etc/hosts, DNS, LDAP, etc. depending on /etc/nsswitch.conf.
Common usage
getent hosts github.com # resolve a hostname (honors /etc/hosts)
getent ahosts api.internal # all addresses, IPv4 + IPv6
getent passwd node # does this user exist?
getent group docker # group membership
getent hosts db || echo "cannot resolve db"Options
| Database | What it does |
|---|---|
| hosts <name> | Resolve a host via NSS (hosts file + DNS) |
| ahosts <name> | Resolve to all address families |
| passwd <user> | Look up a user account |
| group <name> | Look up a group |
| services <name> | Look up a port/service |
Common errors in CI
getent exits 2 when the key is not found (and 0 when it is), which makes it a clean test: getent hosts X resolving means DNS/hosts is working, failing isolates a name-resolution problem from the application. It is the better debug tool than nslookup/dig in containers because it honors /etc/hosts and nsswitch (which curl/ssh also use). "getent: command not found" on Alpine - it uses musl libc; getent exists but some databases behave differently than glibc.