http://blog.gmane.org/gmane.comp.sysutils.supervision.general hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.comp.sysutils.supervision.general/2133 <pre>Hello, I Could not figure out what "process group hack" is supposed to be utilized for ?? Is it used to supervise daemons that stubbornly fork into the background. Could anyone please explain with an example, i would be really helpful. I have to the best of my abilities RTFM'ed and searched the internet. Thank you, Harish </pre> harish badrinath 2012-04-26T15:15:28 http://comments.gmane.org/gmane.comp.sysutils.supervision.general/2130 <pre>I have an application that scans log files that is written in Ruby. It is installed as the user log_watcher but needs to be run as root so that it can have the rights to read the various log files that it needs. Essentially the service/log_watcher/run file comes down to "sudo ruby log_watcher.rb", the log_watcher user has passwordless sudo rights. We have runit / supervise installed but when we try and start the application it complains about supervise/ok or supervise/lock being unavailable which means that the process is not being restarted after a reboot. How do I get to run the process as root from the log_watcher user. I've tried various things I've seen in the wiki and got back from googling but nothing seems to work. Or perhaps there is another way around this? </pre> Peter Hickman 2012-04-25T10:20:41 http://comments.gmane.org/gmane.comp.sysutils.supervision.general/2127 <pre>Announcing the latest release of perp, a persistent process supervisor: http://b0llix.net/perp/distfiles/perp-2.05.tar.gz What's New: * a couple of bugfixes for bigfuxes! * enhanced runuid(8) utility! * bigger release number! About: perp is a service supervisor similar in purpose to the venerable daemontools package, providing a modern update with many advantages: * easy configuration: in place service activation and no symlinks! * everthing administered in /etc/perp * fully FHS compatible * scanner/supervisor/controller runs as a single process * all context switching for multiple supervisor processes is eliminated * service reset capability * pretty good troff -man documentation * colorized(!) service lister, readable timestamps... * no slashpackage, no slashcommand, no slashdoc... More: http://b0llix.net/perp/ Best regards, Wayne </pre> Wayne Marshall 2012-01-11T12:52:43 http://comments.gmane.org/gmane.comp.sysutils.supervision.general/2112 <pre>Hello, I wrote this little program that manages per-user runsv instances. For each user in the "svusers" group it starts a service manager in their ~/.sv directory. The service manager runs as that user, so as long as they can run the sv program, they can manage their own services. Per-user service managers run independently of user logins. I've released this under the BSD license, and it's available on github. https://github.com/eichlan/usersv I hope you find this program useful, I know I have. --Mike Buland </pre> Mike Buland 2011-10-20T16:26:17 http://comments.gmane.org/gmane.comp.sysutils.supervision.general/2111 <pre> s6-0.14 is out. This release fixes a bug that caused a SIGPIPE handler to not be properly reset after a call to ftrigw_notify(). (The bug was introduced by the sig_restore() semantics change in skalibs-1.0.3, which was a good thing, but ftrigw_notify() relied on the old semantics.) Sorry about that. http://www.skarnet.org/software/s6/ Enjoy. Bug-reports always welcome. </pre> Laurent Bercot 2011-08-09T08:36:45 http://comments.gmane.org/gmane.comp.sysutils.supervision.general/2110 <pre> s6-0.13 is out. No changes from s6-0.12. It's just that s6-0.12 does not compile with skalibs-1.1.x due to some interface change, and I had not noticed. s6-0.13 compiles with skalibs-1.1.0 and later. My apologies for the inconvenience. http://www.skarnet.org/software/s6/ Enjoy. Bug-reports welcome. </pre> Laurent Bercot 2011-07-27T15:41:05 http://comments.gmane.org/gmane.comp.sysutils.supervision.general/2107 <pre> s6-0.12 is out. This release fixes another building bug on OpenBSD, and other systems that define stdio's "stderr" as a macro. http://www.skarnet.org/software/s6/ Enjoy. Even more bug-reports always welcome. </pre> Laurent Bercot 2011-07-06T00:19:15 http://comments.gmane.org/gmane.comp.sysutils.supervision.general/2106 <pre> s6-0.11 is out. This release fixes a building bug on OpenBSD (and other lagging OSes that are still lacking EPROTO). No other changes, no need to upgrade if s6 is building fine for you. Thanks Frans Haarman for the report. http://www.skarnet.org/software/s6/ Enjoy. More bug-reports welcome. </pre> Laurent Bercot 2011-07-02T01:04:38 http://comments.gmane.org/gmane.comp.sysutils.supervision.general/2104 <pre>Undeclared variable in selfpipe_trap.c and selfpipe_untrap.c: script -c ./package/install ; cat typescript ==&gt; Script started on Thu 30 Jun 2011 09:41:08 PM CEST Linking ./src into ./compile... Importing ./conf-compile files into the build tree... (Remove the compile/ subdirectory if conf-compile/ has been modified since the last build.) Linking include files... Making subsystem systype... make: Nothing to be done for `it'. Subsystem systype done. Making subsystem sys... make: Nothing to be done for `it'. Subsystem sys done. Making subsystem sysdeps... make: Nothing to be done for `it'. Subsystem sysdeps done. Making subsystem headers... make: Nothing to be done for `it'. Subsystem headers done. Making subsystem libstddjb... ./gen-Makefile &gt; Makefile.real &amp;&amp; make -f Makefile.real &amp;&amp; : &gt; .done make[1]: Entering directory `/usr/local/package/prog/skalibs-1.0.0/compile/libstddjb' exec ./compile selfpipe_trap.c selfpipe_trap.c: In function ‘selfpipe_trap’: selfpipe_trap.c:44:17: error: ‘i’ undec</pre> Lorenzo Beretta 2011-06-30T19:48:21 http://comments.gmane.org/gmane.comp.sysutils.supervision.general/2103 <pre> (announced on both the skaware&lt; at &gt;list.skarnet.org and supervision&lt; at &gt;list.skarnet.org mailing-lists. Mail-Followup-To set to skaware&lt; at &gt;list.skarnet.org.) s6-0.10 is out. s6 is a supervision suite, like the well-known daemontools, runit and perp. It builds upon the accumulated knowledge we have, and tries to bring the best of all worlds. :) s6 is designed to make its directory scanner, s6-svscan, run as process 1, although it's not mandatory for it to run. The s6 documentation provides extensive instructions on how to proceed. s6 also comes with a C implementation of instant notification named libftrig, and command-line notifiers and listeners. This is the long-awaited replacement of pipe-tools. No more polling. Ever ! :) http://www.skarnet.org/software/s6/ Enjoy. Bug-reports welcome. -- Laurent </pre> Laurent Bercot 2011-06-29T18:15:24 http://comments.gmane.org/gmane.comp.sysutils.supervision.general/2093 <pre>I want to use skalibs to support some software that I'm writing, instead of the standard unix libraries. This is generally working well and resulting in smaller, more efficient binaries, but I have come across one issue that is giving me some difficulties: the integer-based *_fmt routines do not format negative numbers. It seems that this is due to the fact that this group of *_fmt routines are all built on top of uint64_fmt_base(), which only knows about unsigned positive values. This makes sense for routines like uint_fmt() and ulong_fmt(), but it is causes problems when passing perfectly valid integers and longs to int_fmt() and long_fmt(), when these valid values happen to be less than zero. Of course, I know how to work around this, but it seems like the most efficient solution to this problem would be for skalibs to handle negative values at the lowest level, perhaps through a new int64_fmt_base() routine that would underlie int_fmt(), long_fmt(), etc. Is there any reason for why such a routine shou</pre> Lloyd Zusman 2011-06-07T09:40:02 http://comments.gmane.org/gmane.comp.sysutils.supervision.general/2091 <pre>Announcing the latest release of perp, a persistent process supervisor: http://b0llix.net/perp/distfiles/perp-2.04.tar.gz What's New (yawn...): The 2.04 release adds the runchoom(8) utility: http://b0llix.net/perp/site.cgi?page=runchoom.8 The runchoom utility is now installed in the standard perpboot(8) runscript, providing linux "oom killer" abatement on perpd(8) and all its services. About (snore...): perp is a service supervisor similar in purpose to the venerable daemontools package, providing a modern update with many advantages: * easy configuration: in place service activation and no symlinks! * everthing administered in /etc/perp * fully FHS compatible * scanner/supervisor/controller runs as a single process * all context switching for multiple supervisor processes is eliminated * service reset capability * pretty good troff -man documentation * colorized(!) service lister, readable timestamps... * no slashpackage, no slashcommand, no slashdoc... And For Even More</pre> Wayne Marshall 2011-03-22T10:46:47 http://comments.gmane.org/gmane.comp.sysutils.supervision.general/2090 <pre>In response to the announcement of the latest perp-2.03 release on the supervision mailing list, there appeared some interesting comments regarding the linux "oom killer" as colorfully described here: http://lwn.net/Articles/104179/ Evidently, the linux kernel can randomly terminate arbitrary processes -- even privileged ones -- with SIGKILL. Astonishing. In any case, it would certainly be undesirable for the linux kernel to decide to hit the perpd process with SIGKILL. Accordingly, attached below is an alternative rc.perp boot script that will abate the thread of the "dreaded linux oom killer" on perpd(8). Simply copy into /etc/perp/.boot/rc.perp, restart your system, and worry no more. &lt;script&gt; #!/bin/sh -e # rc.perp: perpd startup script for perpboot # === ### --- configure --- PERP_VAR=/var/run/perp PERPD_OPTS="-a6" ## disable oom killer (linux, since kernel 2.6.11): ## (see also proc(5) manual) OOM_ADJ="-17" ### --- script --- MYPID=$$ ## note: perpboot defines PERP_BASE on startup ## note: pe</pre> Wayne Marshall 2011-03-15T14:39:57 http://comments.gmane.org/gmane.comp.sysutils.supervision.general/2076 <pre>Announcing the latest release of perp, perp-2.03, a persistent process supervisor: http://b0llix.net/perp/ Tarball: http://b0llix.net/perp/distfiles/perp-2.03.tar.gz What's New (As if You Care): The big news for the "second generation" perp-2.* series: * scanner/supervisor/controller runs as a single process * all context switching for multiple supervisor processes is eliminated * ipc for control/status clients now via single domain socket * perpd(8) creates a mere two file system objects at startup -- a lockfile and domain socket -- and otherwise generates no disk activity during runtime, perfect for read-only file systems and embedded applications! About (The Usual Outrageous Claims and Assertions): perp is a service supervisor similar in purpose to the venerable daemontools package, providing a modern update with many advantages: * easy configuration: in place service activation and no symlinks! * everthing administered in /etc/perp * fully FHS compatible * servic</pre> Wayne Marshall 2011-03-14T10:39:33 http://comments.gmane.org/gmane.comp.sysutils.supervision.general/2075 <pre>Hello, I've started testing with runit but one thing I've had to do is get SIGTERM and SIGQUIT to the /etc/runit/1 script from the console. My /etc/runit/1 has trap "echo 'Boot interrupted'; exit 1" 2 3, but it never seems to get there and signals are ignored. stdin still gets to the child processes I'm running in there, so I've been confused. I don't know how stdin can be getting there properly but the signals are getting dropped on the floor. Can anyone help out? I've tried a variety of things and adding a signal handler to runit but nothing shows up. Oren </pre> Oren Laskin 2011-03-03T22:53:05 http://comments.gmane.org/gmane.comp.sysutils.supervision.general/2073 <pre>My "customer" wants to be able to view status and start-stop processes that are managed by runit across several computers. Seems like this can be accomplished with a simple form and CGI script, but I thought I would check first to make sure I'm not re-inventing a wheel. Thanks for any advice, comments or suggestions. </pre> Philip Tait 2011-02-15T20:52:42 http://comments.gmane.org/gmane.comp.sysutils.supervision.general/2064 <pre>Hello, I just wanted to let everyone know that I've come across a strange problem compiling runit. The issue seems to be with glibc version 2.12.1, earlier versions did not exhibit this. I've also tried GCC 4.5.1, 4.5.0, and 4.4.5. The binutils version I'm using is 2.20.1. When compiling, the runit and runit-init programs link statically, and the result does not appear to be a valid executable program. The system complains that there is no valid entry point. Interestingly enough, I can't get this to happen with any programs that aren't runit and runit-init. Also, the problem is not evident when linking against dietlibc. The executables I made with dietlibc are fine. I don't think this is an issue for runit, actually, especially since there is a workaround, but it is a concern for the glibc developers, but who knows when they'll get around to fixing it. I thought the list in general could benefit from my somewhat limited research into the problem. I'm also in the process of figuring out if this i</pre> Mike Buland 2010-11-09T15:29:38 http://comments.gmane.org/gmane.comp.sysutils.supervision.general/2057 <pre>Hi, I have a problem with a service [1] which runs fine and handles HUP, TERM correctly and sends output to stderr as a good citizen. Unfortunately it (re)creates a unix socket with permissions unfit for the purpose, so I have to chmod g+w /var/run/thin-*/socket every time. cron gives me a granularity of 1 minute which still makes the application unreachable for up-to one looooong minute. The authors don't care because it works fine when daemonizing... and "one shall daemonize the daemons"... no comment on that. Is there an elegant way of solving this issue with runit? Thanks, Alejandro Mery [1] &lt;http://code.macournoyer.com/thin/&gt; </pre> Alejandro Mery 2010-11-05T11:36:29 http://comments.gmane.org/gmane.comp.sysutils.supervision.general/2056 <pre>Hi! I'm not sure is it runit issue or is it possible to fix in runit source, but, thing is, it's already second time when runit-init conflict with PAX MPROTECT. Short story: 1.5 years ago, after upgrading (Gentoo Linux) from sys-kernel/hardened-sources-2.6.28-r6 to sys-kernel/hardened-sources-2.6.28-r7 kernel hangs while boot when tried to start /sbin/runit-init. Actual reason was segfault in runit-init because of PAX MPROTECT, which can be worked around by completely switching off PAX MPROTECT in kernel or switching it off individually for /sbin/runit by paxctl -m /sbin/runit-init In some later kernel this was fixed. But yesterday it happens again after upgrading from sys-kernel/hardened-sources-2.6.32-r9 to sys-kernel/hardened-sources-2.6.32-r22 As far as I understood, this doesn't mean it's 100% bug in PAX - I think PAX protection was improved, become more strict, and so disallow some operations which was accepted by older PAX. Long story: http://www.mail-archive.com/gentoo-hard</pre> Alex Efros 2010-10-24T11:44:06 http://comments.gmane.org/gmane.comp.sysutils.supervision.general/2048 <pre>Hi - I'd like to use runit and svlogd as a user in a couple applications (eg x11 sessions and desktop widgets) and I was wondering what experiences people have had with this? It looks like both socklog and runit require a package/upgrade rewrite since they don't accept any configuration, but that should be straightforward. Garrit, it this something you would include in forthcoming releases and if so, do you have any requirements or preferred methods? --George </pre> George Georgalis 2010-10-21T21:16:36 http://comments.gmane.org/gmane.comp.sysutils.supervision.general/2056 <pre>Hi! I'm not sure is it runit issue or is it possible to fix in runit source, but, thing is, it's already second time when runit-init conflict with PAX MPROTECT. Short story: 1.5 years ago, after upgrading (Gentoo Linux) from sys-kernel/hardened-sources-2.6.28-r6 to sys-kernel/hardened-sources-2.6.28-r7 kernel hangs while boot when tried to start /sbin/runit-init. Actual reason was segfault in runit-init because of PAX MPROTECT, which can be worked around by completely switching off PAX MPROTECT in kernel or switching it off individually for /sbin/runit by paxctl -m /sbin/runit-init In some later kernel this was fixed. But yesterday it happens again after upgrading from sys-kernel/hardened-sources-2.6.32-r9 to sys-kernel/hardened-sources-2.6.32-r22 As far as I understood, this doesn't mean it's 100% bug in PAX - I think PAX protection was improved, become more strict, and so disallow some operations which was accepted by older PAX. Long story: http://www.mail-archive.com/gentoo-hard</pre> Alex Efros 2010-10-24T11:44:06 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.sysutils.supervision.general