'logger' sends data to the Unix socket /dev/log. (It's a socket despite being in /dev.)
On most Linux distributions, this socket is not owned by a traditional syslog daemon anymore – its other end does not actually go to rsyslog directly. Rather, the /dev/log socket is owned by the systemd-journald service, which is still running and receiving messages.
# fuser -v /dev/log
USER PID ACCESS COMMAND
/run/systemd/journal/dev-log: root 1 F.... systemd
root 304 F.... systemd-journal
(Note that init also holds the socket – if journald is stopped, but there is some activity on the socket, init will automatically start the service again… much like 'inetd' did in the past for TCP services.)
Systemd-journald stores logs in /var/log/journal, which you can read using journalctl -f instead of the usual 'tail -f' (they're in indexed binary format). Normally, messages via /dev/log will continue to be written there even when rsyslogd is down.
$ logger Hello
$ journalctl -n 1
Jul 12 18:12:26 ember root[951422]: Hello
In such systems, the rsyslogd and syslog-ng packages only receive relayed messages from systemd-journald, not directly from programs. They work either by listening at a different socket (inside /run/systemd), to which journald forwards all messages – or by directly reading the binary log files from /var/log/journal.
(Usually the direct .journal file access is preferred as it allows rsyslogd to collect additional fields included by programs, which would otherwise be lost when using the socket-based message forwarding.)
If you point 'logger' at a Unix socket which is not accepting messages, it will in fact show an error message like it should:
$ python -c "from socket import *; socket(AF_UNIX, SOCK_DGRAM).bind('/tmp/log')"
$ logger -u /tmp/log Hello
logger: socket /tmp/log: Connection refused
