| Summary: | sys-process/daemontools: svscan with readproctitle support | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Xuefer <Xuefer> |
| Component: | [OLD] Core system | Assignee: | Gentoo's Team for Core System packages <base-system> |
| Status: | RESOLVED NEEDINFO | ||
| Severity: | enhancement | ||
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
patch svscan to work with readproctitle
readproctitle with SIGHUP support Drop-in replacement for /usr/bin/svscan in /etc/init.d/svscan |
||
|
Description
Xuefer
2005-08-17 08:45:26 UTC
Created attachment 66143 [details, diff]
patch svscan to work with readproctitle
no idea what you're trying to do but that patch is ugly sorry, here's more description: the patch is all base on /usr/bin/svscanboot, which is default and recommended way to start svscan, as stderr output of svscan should really be put on some where. for the script gentoo currently using, it doesn't even redirect those pipes to /dev/null, results error by the following steps: 1. ssh gentoo box, su to root 2. /etc/init.d/svscan restart 3. mkdir /services/test 4. supervise: fatal: unable to start test/run: file does not exist oops, what's up? it's shown in my terminal well.. 5. rm irf /services/test 6. logout. wah? hang here, as fd 0 1 2 is still opened by svscan have to kill ssh client on my own box again. do "cat /usr/bin/svscanboot" now to see how nice this patch is. http://cr.yp.to/daemontools/readproctitle.html http://cr.yp.to/daemontools/svscanboot.html http://cr.yp.to/daemontools/svscan.html we should patch svscan then rather than hacking around it in the init.d script to close its file descriptors but svscan still should write error to stderr, and init.d/svscan or svscanboot can pipe it to readproctitle, untill you find another way to redirect those errors to logfile or so. i can live without readproctitle, as i dunno how to clear readproctitle when it looks annoying. thanks yeah, fair enough ... why do we have to pass so many dots to readproctitle ? it's all come from svscanboot. i just did the patch that works with start-stop- daemon by using subshell (). i'm not sure, but i'd guess it allocate proc title (command line buffer) as the process can't remalloc() it. if u're gonna patch script not svscan to make it work with readproctitle, could u please patch readproctitle to accept SIGHUP or something which reset proctitle to dots? i have a patch but not tested, just passed the compile Created attachment 66284 [details, diff]
readproctitle with SIGHUP support
Created attachment 71620 [details, diff]
Drop-in replacement for /usr/bin/svscan in /etc/init.d/svscan
When I realized init.d/svscan doesn't start readproctitle, I wrote (in C,
djb-style) a new command svscan-start who starts readproctitle as child, wait 2
seconds to verify if readproctitle is running, then exec svscan; so when I need
to stop svscan, "/etc/init.d/svscan stop" will kill the right process.
Attached patch modifies daemontools-0.76-r4.ebuild and add needed files to
.../files dir.
(I use it to create portage overlay on my servers:
cp -r /usr/portage/sys-process/daemontools /usr/local/portage/sys-process/. &&
cd /usr/local/portage/sys-process && patch -p0 < svscan-start.patch
)
(In reply to comment #8) > Created an attachment (id=66284) [edit] > readproctitle with SIGHUP support That patch is unnecessary. To create a "readproctitle cleaner": mkdir /service/clean-readproctitle touch /service/clean-readproctitle/down echo >/service/clean-readproctitle/run "#!/bin/sh svc -d . sleep 1 exec date 1>&2 '+.................................................%H:%M.'" chmod 555 /service/clean-readproctitle/run Then to clean readproctitle title: svc -o /service/clean-readproctitle Update the patch if you still want it, but I think we generally won't apply this. |
