app-admin/tenshi-0.7 and 0.9.1 (latest stable and ~x86) both will not stop for me with /etc/init.d/tenshi stop. The closest bug match I could find is bug #85395 (CANTFIX) from 2005, but I can find no reason to suspect an smtp timeout problem in my case. Furthermore, attempting what the author of that bug did, running in foreground, I found no problem killing tenshi with ctrl-c. On the other hand, I admit I am not an expert with all the issues involved. I checked the forums and found no relevant discussion about this problem with tenshi. Reproducible: Always Steps to Reproduce: 1. /etc/init.d/tenshi start 2. /etc/init.d/tenshi stop 3. Actual Results: 1. [ok] 2. [!!] Expected Results: 1. [ok] 2. [ok] I will attach a --debug version of the init.d/stop. Also, when I run: /usr/bin/perl /usr/sbin/tenshi -d 2 -f -c /etc/tenshi/tenshi.conf -P /var/lib/tenshi/tenshi.pid and do ctrl-c, I get simply: [MAIN] trapped INT signal! [MAIN] trapped CHLD signal! [ERROR] Child died. Bailing out Killed at /usr/sbin/tenshi line 908. (latest instable version, in the above case). No tenshi processes (tenshi or tail are left around. Adding a signal to /etc/init.d/tenshi as follows: start-stop-daemon --stop --signal SIGKILL --quiet --pidfile /var/lib/tenshi/tenshi.pid of course results in and [ok], but tenshi's child (tail) process is left running and I would assume, tenshi's buffers don't get flushed (which would be very bad). I tried killing /usr/bin/perl /usr/sbin/tenshi -c /etc/tenshi/tenshi.conf -P /var/lib/tenshi/tenshi.pid manually with TERM, INT, USR2, HUP, but nothing seems to stop it. Strange since running it in debug more and the foreground, a simple ctrl-c kills it.
Created attachment 145224 [details] /etc/init.d/tenshi stop --debug Attempt at stopping tenshi. BTW, I have checked the contents and access rights to the pid file. All that seems ok.
Created attachment 145307 [details, diff] proposed fix This trivial patch should fix it. I presume you only have a single child tail process as this bug shouldn't have affected you otherwise.
I just spoke to upstream and this will be fixed for the next release.
(In reply to comment #2) Trivial or not, I much appreciate the fix and it works for me! (see below) You are correct that I have only a single child (tail) process with tenshi. I would expect that is what most folks running Gentoo would have since the tail with Gentoo seems to not need tenshi's "tail_multiple on" option. In other words, I would expect the fix to help others than just me. I hope you can find a maintainer for tenshi. It's one of the best log analysis tools from my point of view. Also, I got the impression that Gentoo uses it internally for their servers. If I knew more about Perl (and were otherwise qualified :-), I would volunteer. Thanks! fluke Tenshi # /etc/init.d/tenshi start * Starting tenshi ... [ ok ] fluke Tenshi # ps -ef | grep tenshi tenshi 29371 1 0 10:57 ? 00:00:00 /usr/bin/perl /usr/sbin/tenshi -c /etc/tenshi/tenshi.conf -P /var/lib/tenshi/tenshi.pid tenshi 29372 29371 0 10:57 ? 00:00:00 /usr/bin/tail -q --follow=name --retry -n 0 /var/log/messages /var/log/remote.d/gannet.log /var/log/remote.d/tjasse.log /var/log/remote.d/serendipity.log root 29381 27197 0 10:57 pts/4 00:00:00 grep --colour=auto tenshi fluke Tenshi # /etc/init.d/tenshi stop * Stopping tenshi ... [ ok ] fluke Tenshi # ps -ef | grep tenshi root 29417 27197 0 10:58 pts/4 00:00:00 grep --colour=auto tenshi fluke Tenshi # /Mike PS I leave this bug open only because I don't know if you want it closed if you are looking for a maintainer. Feel free to close otherwise.
Thanks to Markus, I am now proxy maintainer for tenshi. This bug is fixed in tenshi-0.9.1-r1 which will hit the tree today.
Fixed in CVS :)
