From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 29278 invoked from network); 19 Oct 2021 09:00:11 -0000 Received: from alyss.skarnet.org (95.142.172.232) by inbox.vuxu.org with ESMTPUTF8; 19 Oct 2021 09:00:11 -0000 Received: (qmail 13227 invoked by uid 89); 19 Oct 2021 09:00:32 -0000 Mailing-List: contact supervision-help@list.skarnet.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Received: (qmail 13220 invoked from network); 19 Oct 2021 09:00:32 -0000 X-Injected-Via-Gmane: http://gmane.org/ To: supervision@list.skarnet.org From: Ben Franksen Subject: logging services with shell interaction Date: Tue, 19 Oct 2021 10:59:58 +0200 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 X-Mozilla-News-Host: news://news.gmane.org:119 Content-Language: en-US Hi Everyone we have a fair number of services which allow (and occasionally require) user interaction via a (built-in) shell. All the shell interaction is supposed to be logged, in addition to all the messages that are issued spontaneously by the process. So we cannot directly use a logger attached to the stdout/stderr of the process. procServ is a process supervisor adapted to such situations. It allows an external process (conserver in our case) to attach to the service's shell via a TCP or UNIX domain socket. procServ supports logging everything it sees (input and output) to a file or stdout. In the past we had recurring problems with processes that spew out an extreme amount of messages, quickly filling up our local disks. Since logrotate runs via cron it is not possible to reliably guarantee that this doesn't happen. Thus, inspired by process supervision suites a la daemontools, we are now using a small shell wrapper script that pipes the output of the process into the multilog tool from the daemontools package. Here is the script, slightly simplified. Most of the parameters are passed via environment. ``` IOC=$1 /usr/bin/procServ -f -L- --logstamp --timefmt="$TIMEFMT" \ -q -n %i --ignore=^D^C^] -P "unix:$RUNDIR/$IOC" -c "$BOOTDIR" "./$STCMD" \ | /usr/bin/multilog "s$LOGSIZE" "n$LOGNUM" "$LOGDIR/$IOC" ``` So far this seems to do the job, but I have two questions: 1. Is there anything "bad" about this approach? Most supervision tools have this sort of thing as a built-in feature and I suspect there may be a reason for that other than mere convenience. 2. Do any of the existing process supervision tools support what procServ gives us wrt interactive shell access from outside? Cheers Ben -- I would rather have questions that cannot be answered, than answers that cannot be questioned. -- Richard Feynman