Simon Josefsson wrote: > It seems like a better > trade-off to just have readutmp return garbage in this scenario.
I'm vehemently against readutmp returning garbage (whether that be a list of users from before the last system upgrade, or an empty list). [1] Such API behaviour leaves the users puzzled about broken functionality. A diagnostic is 100 times better. > There are several tools in GNU InetUtils that uses readutmp. There's also 'talkd'. But 'talk' has generally been replaced by IRC, Matrix, SMS, or Signal. > For example, InetUtils syslogd uses readutmp.h. Having the built binaries > always depend on the systemd ecosystem prevents using them in minimal > environments. It would be nice it syslogd wouldn't a link-time > dependency on anything systemd-related. Anyone wanting to use syslogd in a minimal environment? What are we talking about exactly? Here are the chroot environment sizes that I got using the default settings in several distros: * Debian 13: $ sudo debootstrap stable CHROOTDIR http://deb.debian.org/debian 309 MB 360 programs in usr/bin/, 149 programs in usr/sbin/ * Ubuntu 26.04: $ sudo debootstrap resolute CHROOTDIR http://archive.ubuntu.com/ubuntu 431 MB 547 programs in usr/bin/, 152 programs in usr/sbin/ * Fedora 44: $ sudo dnf --installroot=CHROOTDIR --releasever=44 --use-host-config install @core 694 MB 1076 programs in usr/bin/ = usr/sbin/ libsystemd.so.0 is 1 MB in size, that is 0.3% (or less) of that installed environment. And these environments don't have a 'syslogd'. So: * What is a "minimal environment" for you? If it is something like that, above, with 300 MB or more, we don't need to spend time squeezing out 1 MB from it, because that would be insignificant. * Why would the "minimal environment" that you are imagining contain 'syslogd' (when the not-even-minimal environments from the three distros above don't contain 'syslogd')? I really want to hear convincing arguments, before installing additional complexity into readutmp.c. Your syslogd argument is not convincing for me, so far. Bruno [1] https://lists.gnu.org/archive/html/bug-gnulib/2026-07/msg00017.html
