Micah Anderson wrote:
> Hi,
>
> Alexander Gerasiov wrote:
>
>>>Package: util-vserver
>>>Version: 0.30.210-10
>>>Severity: normal
>>>
>>>Hi there.
>>>I want to push main host's mysqld socket inside vserver.
>>>So I think that the simplest way is to mount /var/run/mysqld from host
>>>to /var/run/mysqld on vserver. But that forces /var/run/mysqld cleaning
>>>on vserver's start.
>>>
>
>
> The reason this happens is not because of util-vserver, or anything
> related to vservers at all, but instead the Debian startup scripts which
> clean /var/run on bootup and shutdown. The only way to fix this is to
> alter your debian scripts not to do this.
Nope. As I can see, you wrong here.
I don't know how to debug vserver (cause even strace halts), but simple
test (something like adding "echo $0" in all of init scripts) gave me
the following:
====without /var/run/mysqld ro===
# vserver bigfoot start
rc
inetd
Starting internet superserver: inetd.
cron
Starting periodic command scheduler: cron.
apache2
Starting web server: Apache2.
rmnologin
stop-bootlogd
bootlogd
=================================
====with /var/run/mysqld ro===
# vserver bigfoot start
chroot-shunlink("var/run/mysqld/mysqld.pid"): Read-only file system
chroot-shunlink("var/run/mysqld/mysqld.sock"): Read-only file system
Failed to start vserver 'bigfoot'
==============================
So this isn't init scripts who fails.
>
>
>>>Then I made mount --bind -o ro (I also tried to specify that in
>>>vserver's fstab with the same behaviour), but in such situations vserver
>>>start fails with:
>>>=======
>>>#vserver bigfoot start
>>>chroot-shunlink("var/run/mysqld/mysqld.pid"): Read-only file system
>>>chroot-shunlink("var/run/mysqld/mysqld.sock"): Read-only file system
>>>
>>>
>>>Failed to start vserver 'bigfoot'
>>>======
>
>
> This fails because the Debian startup scripts need to be able to write
> to /var/run, so they fail and thus the startup of that server fails.
Sigh... No..
>
>
>>>So I see here two questions:
>>>1st May be read-only subdir in /var/run shouldn't be fatal?
>
>
> This isn't a util-vserver bug, and the maintainers of the debian startup
> scripts will also tell you that this isn't a bug. Trust me, I've checked
> this out, they will tell you that you are trying to do something
> non-standard and the cleaning of /var/run is there for a reason. If you
> want to make it fail, then you make the startup fail.
>
>
>>>2nd Am I wrong? May be there are better way to do the same thing (I'm
>>>speaking not about mysql, I know that it's possible to use network
>>>socket, but I want to use the same scheme for some other services, so
>>>I'm interested in mounting something inside vserver with bind option.).
>
>
> The way I solved this was to have mysql listen on the private network
> and then I contact it over the network, rather than through a socket. If
> you want to use a socket, then you need to be putting that socket
> somewhere other than /var/run.
Now the 1st thing I want is to get clean reply from upstream:
Is this possible to connect host and vserver via UNIX-socket as I did,
or that's working but just because of bug and wouldn't work in future.
I've attached below the mail I forgot to send here on reply to Ola.
=================================
Subject: Re: Bug#378673: problem when /var/run/service is readonly
inside vserver
Date: Tue, 18 Jul 2006 15:43:15 +0400
From: Alexander Gerasiov <[EMAIL PROTECTED]>
Organization: MSU, CMC dep. LVK
To: [EMAIL PROTECTED]
CC: [email protected]
References: <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
Ola Lundqvist wrote:
> Hi
>
> First of all this is not a bug in util-vserver. It is at most
> a bug in mysql-server, but in this case it is not that either.
No, it isn't. Mysqld works fine, the problems I have is in scripts wich
clean /var/run on vserver start.
>
> Summary of below:
> * /var can not be read-only
/var - yes, but why /var/run/mysqld should be rw?
> * you can not communicate across vservers (or to main host that is
> context id 0), using unix sockets.
See below
> * You can only communicate using plain files, but then you can
> of course not use read-only access.
Well I need ro fs, but socket there is rw for both side. Again, see below.
>
> On Tue, Jul 18, 2006 at 02:05:00PM +0400, Alexander Gerasiov wrote:
>
>>Package: util-vserver
>>Version: 0.30.210-10
>>Severity: normal
>>
>>Hi there.
>>I want to push main host's mysqld socket inside vserver.
>>So I think that the simplest way is to mount /var/run/mysqld from host
>>to /var/run/mysqld on vserver. But that forces /var/run/mysqld cleaning
>>on vserver's start.
>
>
> You can not do that. Even if you create that socket for the vserver they
> can not communicate. That is the main idéa about vservers that they
> can not communicate with each other, except for the ways normal servers
> can, like network.
>
>
>>Then I made mount --bind -o ro (I also tried to specify that in
>>vserver's fstab with the same behaviour), but in such situations vserver
>>start fails with:
>>=======
>>#vserver bigfoot start
>>chroot-shunlink("var/run/mysqld/mysqld.pid"): Read-only file system
>>chroot-shunlink("var/run/mysqld/mysqld.sock"): Read-only file system
>
>
> This is not a bug. /var is always read-write. /usr is the directory
> where you can have read-only things in.
>
>
>>Failed to start vserver 'bigfoot'
>>======
>>
>>So I see here two questions:
>>1st May be read-only subdir in /var/run shouldn't be fatal?
>
> It is not fatal, not even a bug at all.
>
>
>>2nd Am I wrong? May be there are better way to do the same thing (I'm
>>speaking not about mysql, I know that it's possible to use network
>>socket, but I want to use the same scheme for some other services, so
>>I'm interested in mounting something inside vserver with bind option.).
>
>
> You need to use network sockets. That is the only way. If you want the
> servers to communicate the way you want, then you do not want vservers,
> but rather simple chrooted environments.
Yes, chroot is fine, but it isn't so secure %) And it doesn't allow many
other vserver features.
Ok, look here:
I start vserver.
in vserver's fstab I have
====
# tail -n1 /etc/vservers/bigfoot/fstab
/var/run/mysqld /var/run/mysqld none bind,rw 0 0
====
so /var/run/mysqld on host and /var/run/mysqld on vserver are the same
then on host
/etc/init.d/mysql start
in /var/run/mysqld on vserver i see mysqld socket. And this socked works
%) Just trust me or test it yourself. For example not with mysqld but
with anything other.
Another example - I wrote
====
# tail -n1 /etc/vservers/bigfoot/fstab
/var/run/mysqld /usr/test none bind,ro 0 0
====
And
mysql -S /usr/test/mysqld.sock
works fine in vserver.
So UNIX-socket placed in fs ARE WORKING besides vserver and host, and
your words are wrong (or this is wrong behavior of vserver, unfortunetly
I see no good doc for vserver). I've cc to
[email protected] to listen for upstream point of view.
As you can see the only problem I have is that command "vserver bigfoot
start" fails if there is read-only fs mounted somewhere inside /var/run.
PS Guys from vserver maillist, please CC to me when reply, I'm not
subscribed.
--
Regards, Alexander.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
