* runit on the read-only file system
@ 2004-06-05 23:29 Milan P. Stanic
2004-06-06 2:15 ` mike
0 siblings, 1 reply; 6+ messages in thread
From: Milan P. Stanic @ 2004-06-05 23:29 UTC (permalink / raw)
Hi!
Sorry if this is discussed earlier, but can anyone explain how to
use runit on read-only filesystem or give URL where I can find info
about subject?
TIA
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: runit on the read-only file system
2004-06-05 23:29 runit on the read-only file system Milan P. Stanic
@ 2004-06-06 2:15 ` mike
2004-06-06 21:46 ` Milan P. Stanic
2004-06-07 15:05 ` Gerrit Pape
0 siblings, 2 replies; 6+ messages in thread
From: mike @ 2004-06-06 2:15 UTC (permalink / raw)
On Sun, Jun 06, 2004 at 01:29:27AM +0200, Milan P. Stanic wrote:
> Sorry if this is discussed earlier, but can anyone explain how to
> use runit on read-only filesystem or give URL where I can find info
> about subject?
runsv can be made to work on read-only mounts by putting the supervise
directories somewhere writable. tmpfs poses some problems though since
runsv won't create directories at the end of broken symlinks. You'll
probably need a script to create all the directories in runit/1 if you
want to do it that way.
As for runit itself, it has all sorts of problems with wanting to write
to the root filesystem (or more precisely, /etc). I recall Gerrit saying
that runit doesn't use a FIFO like sysv init because signals are more
elegant, but since it relies so heavily on the filesystem I'm not sure
that's really the case anymore.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: runit on the read-only file system
2004-06-06 2:15 ` mike
@ 2004-06-06 21:46 ` Milan P. Stanic
2004-06-06 23:09 ` mike
2004-06-07 15:05 ` Gerrit Pape
1 sibling, 1 reply; 6+ messages in thread
From: Milan P. Stanic @ 2004-06-06 21:46 UTC (permalink / raw)
On Sun, Jun 06, 2004 at 11:15:26AM +0900, mike@mikebell.org wrote:
> runsv can be made to work on read-only mounts by putting the supervise
> directories somewhere writable. tmpfs poses some problems though since
> runsv won't create directories at the end of broken symlinks. You'll
> probably need a script to create all the directories in runit/1 if you
> want to do it that way.
I already tried that way, but it looks to complicated. I had a hope
that there is simpler solution. :-(
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: runit on the read-only file system
2004-06-06 21:46 ` Milan P. Stanic
@ 2004-06-06 23:09 ` mike
2004-06-08 13:04 ` Milan P. Stanic
0 siblings, 1 reply; 6+ messages in thread
From: mike @ 2004-06-06 23:09 UTC (permalink / raw)
On Sun, Jun 06, 2004 at 11:46:57PM +0200, Milan P. Stanic wrote:
> I already tried that way, but it looks to complicated. I had a hope
> that there is simpler solution. :-(
Nope, not that I know of. I guess you /could/ just modify runsv to
create directories at the end of broken symlinks, then point all the
supervise symlinks to the non-existant subdirectories of a tmpfs mount.
That would be a little more difficult up-front but would make things
much easier in the long run, and since only root should have write
access to make such a symlink I don't see any particular security
implications as long as you make the directory safely.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: runit on the read-only file system
2004-06-06 2:15 ` mike
2004-06-06 21:46 ` Milan P. Stanic
@ 2004-06-07 15:05 ` Gerrit Pape
1 sibling, 0 replies; 6+ messages in thread
From: Gerrit Pape @ 2004-06-07 15:05 UTC (permalink / raw)
On Sun, Jun 06, 2004 at 11:15:26AM +0900, mike@mikebell.org wrote:
> On Sun, Jun 06, 2004 at 01:29:27AM +0200, Milan P. Stanic wrote:
> > Sorry if this is discussed earlier, but can anyone explain how to
> > use runit on read-only filesystem or give URL where I can find info
> > about subject?
>
> runsv can be made to work on read-only mounts by putting the supervise
> directories somewhere writable. tmpfs poses some problems though since
> runsv won't create directories at the end of broken symlinks. You'll
Please check again: runsv has no problems with supervise directories
being dangling symbolic links. It should also have no problems with
/etc/runit/stopit and /etc/runit/reboot being dangling symlinks. If so
I would consider it a bug.
Creating symlinks for service/supervise directories and magic files in
/etc/runit/ is the way to go if /etc/runit/ and/or the service
directories reside on a read-only filesystem.
Regards, Gerrit.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: runit on the read-only file system
2004-06-06 23:09 ` mike
@ 2004-06-08 13:04 ` Milan P. Stanic
0 siblings, 0 replies; 6+ messages in thread
From: Milan P. Stanic @ 2004-06-08 13:04 UTC (permalink / raw)
On Mon, Jun 07, 2004 at 08:09:53AM +0900, mike@mikebell.org wrote:
> Nope, not that I know of. I guess you /could/ just modify runsv to
> create directories at the end of broken symlinks, then point all the
> supervise symlinks to the non-existant subdirectories of a tmpfs mount.
> That would be a little more difficult up-front but would make things
> much easier in the long run, and since only root should have write
> access to make such a symlink I don't see any particular security
> implications as long as you make the directory safely.
I hacked runit to use /var/runit instead of /etc/runit and made script
which create /var hierarchy and symlinks during boot.
It is crude hack, but it works for now. So, I have runit on read-only
filesystem with /var mounted on tmpfs.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2004-06-08 13:04 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-06-05 23:29 runit on the read-only file system Milan P. Stanic
2004-06-06 2:15 ` mike
2004-06-06 21:46 ` Milan P. Stanic
2004-06-06 23:09 ` mike
2004-06-08 13:04 ` Milan P. Stanic
2004-06-07 15:05 ` Gerrit Pape
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).