* runsvdir problem + patch
@ 2004-07-23 2:15 Eric Lammerts
2004-07-23 10:18 ` Gerrit Pape
2004-07-27 19:30 ` Eric Lammerts
0 siblings, 2 replies; 3+ messages in thread
From: Eric Lammerts @ 2004-07-23 2:15 UTC (permalink / raw)
Cc: supervision
Hi,
I found a problem with runsvdir: If you create two subdirectories in
/service within the same second, runsvdir doesn't always see the 2nd
one.
For example:
- create /service/foo
- runsvdir sees mtime of /service has changed, runs runsv for foo
- create /service/bar
If these three things happen within the same second, the creation of
/service/bar doesn't change the mtime of /service, and therefore
runsvdir won't rescan it.
This patch fixes the problem by forcing a check on the next iteration
after a service was started.
Eric
--- runit-1.0.3/src/runsvdir.c.orig 2004-07-22 19:36:35.000000000 -0400
+++ runit-1.0.3/src/runsvdir.c 2004-07-22 19:37:19.000000000 -0400
@@ -117,6 +117,7 @@
sv[i].isgone =0;
svnum++;
runsv(i, d->d_name);
+ check =1;
}
}
if (errno) {
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: runsvdir problem + patch
2004-07-23 2:15 runsvdir problem + patch Eric Lammerts
@ 2004-07-23 10:18 ` Gerrit Pape
2004-07-27 19:30 ` Eric Lammerts
1 sibling, 0 replies; 3+ messages in thread
From: Gerrit Pape @ 2004-07-23 10:18 UTC (permalink / raw)
On Thu, Jul 22, 2004 at 10:15:48PM -0400, Eric Lammerts wrote:
> I found a problem with runsvdir: If you create two subdirectories in
> /service within the same second, runsvdir doesn't always see the 2nd
> one.
>
> For example:
> - create /service/foo
> - runsvdir sees mtime of /service has changed, runs runsv for foo
> - create /service/bar
>
> If these three things happen within the same second, the creation of
> /service/bar doesn't change the mtime of /service, and therefore
> runsvdir won't rescan it.
Yes, I know about this for some time, but actually was hit by the
problem just once, on a system where the service directory was located
on a ramdisk, and the subdirectories were created in background after
stage 1 finished.
Did you actually run into this problem, or found it by reading the
source?
> This patch fixes the problem by forcing a check on the next iteration
> after a service was started.
The patch looks fine to me at the first glance, thanks for posting it.
Regards, Gerrit.
> --- runit-1.0.3/src/runsvdir.c.orig 2004-07-22 19:36:35.000000000 -0400
> +++ runit-1.0.3/src/runsvdir.c 2004-07-22 19:37:19.000000000 -0400
> @@ -117,6 +117,7 @@
> sv[i].isgone =0;
> svnum++;
> runsv(i, d->d_name);
> + check =1;
> }
> }
> if (errno) {
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: runsvdir problem + patch
2004-07-23 2:15 runsvdir problem + patch Eric Lammerts
2004-07-23 10:18 ` Gerrit Pape
@ 2004-07-27 19:30 ` Eric Lammerts
1 sibling, 0 replies; 3+ messages in thread
From: Eric Lammerts @ 2004-07-27 19:30 UTC (permalink / raw)
Gerrit Pape wrote:
>On Thu, Jul 22, 2004 at 10:15:48PM -0400, Eric Lammerts wrote:
>> I found a problem with runsvdir: If you create two subdirectories
>> in /service within the same second, runsvdir doesn't always see the
>> 2nd one.
> Yes, I know about this for some time, but actually was hit by the
> problem just once, on a system where the service directory was
> located on a ramdisk, and the subdirectories were created in
> background after stage 1 finished.
>
> Did you actually run into this problem, or found it by reading the
> source?
I ran into it while testing out stuff. Usually the service directories
are created during stage 1, so it's not actually a problem during
normal operation.
Eric
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2004-07-27 19:30 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-07-23 2:15 runsvdir problem + patch Eric Lammerts
2004-07-23 10:18 ` Gerrit Pape
2004-07-27 19:30 ` Eric Lammerts
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).