should we avoid running multiple instances of "logger" continuously? |
|
Issue descriptionI just noticed these: localhost autotest # ps auxwww | grep logger | grep -v grep USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND syslog 1858 0.0 0.0 6496 912 ? S 11:12 0:00 /usr/bin/logger --priority daemon err --tag shill root 2976 0.0 0.0 4252 640 ? S 11:12 0:00 logger -t tlsdate I noticed them because I was about to add another one. So that's 1.5MB of RSS, versus probably just a few kilobytes of libc if we called syslog directly. Do we care? It would be nice if we could get an fd for syslog output, and redirect stderr to it... but unfortunately that's not how it works---syslog takes a format string and args, and I think it prepends stuff to each line (time stamp, etc.) so exposing an fd might require a separate thread reading from it... ouch... oh well.
,
May 15 2018
would it be good to get rid of every instance of `logger` in the system ? definitely. unfortunately, we don't have a solution for its replacement (connecting stdout/stderr directly to the /dev/logger unix socket with tags added -- it isn't just fd-to-fd), so logger remains. can we try to have a single `logger` process that handles all of these ? not with the current tooling, and i'm not sure that doing any work to implement this would be worthwhile instead of just going straight to the optimal solution. as you noted, the RSS isn't entirely unique, but you'd have to look at something like smaps to find out more. similarly for our shell replacement for a crond. we might be at the point of evaluating existing cron implementations, or writing our (minimal) one. |
|
►
Sign in to add a comment |
|
Comment 1 by semenzato@chromium.org
, May 14 2018