1413177833 J * Ghislain ~aqueos@adsl1.aqueos.com 1413179637 Q * geos_one Quit: ChatZilla 0.9.91 [Firefox 32.0/20140905224606] 1413180855 Q * Aiken Remote host closed the connection 1413180878 Q * theocrite Ping timeout: 480 seconds 1413182492 M * Bertl off to bed now ... have a good one everyone! 1413182495 N * Bertl Bertl_zZ 1413183838 Q * Ghislain Quit: Leaving. 1413183869 J * Ghislain ~aqueos@adsl1.aqueos.com 1413186798 J * Aiken ~Aiken@quarry.jbmb.net 1413189896 J * BenG ~BenG@cpc29-aztw22-2-0-cust128.18-1.cable.virginm.net 1413190334 J * theocrite ~Hubert@kim.theocrite.org 1413195373 N * ensc Guest1460 1413195382 J * ensc ~irc-ensc@p54ADF45C.dip0.t-ipconnect.de 1413195790 Q * Guest1460 Ping timeout: 480 seconds 1413197135 Q * mcp Quit: ZNC - http://znc.sourceforge.net 1413197828 Q * Aiken Remote host closed the connection 1413198158 J * nske21 ~oftc-webi@213.106.150.130 1413199346 Q * nske21 Quit: Page closed 1413199465 J * _dakkon- ~oftc-webi@213.106.150.130 1413199465 M * _dakkon- Hi, does anyone have a suggestion why some sockets that exist in some shared (with bind-mount) directories between containers disappear when a container is restarted? 1413199465 M * _dakkon- basically, I have /run/mysqld mounted across many containers 1413199576 M * _dakkon- when I do vserver restart the container, /var/mysqld becomes empty 1413199597 M * _dakkon- */run/mysld 1413199804 N * Bertl_zZ Bertl 1413199814 M * Bertl morning folks! 1413199844 M * Bertl _dakkon-: do you have the bind mount in the guest's fstab? 1413199990 M * _dakkon- yes /vservers/srv_mysql/run/mysqld /run/mysqld none bind,rw 0 0 1413200033 M * _dakkon- I just don't know where to look first, could it be some init script from the target guest that destroyes the mount on restart? 1413200073 M * _dakkon- ops meant destroyes the socket 1413200321 M * Bertl first, check if the mount happened and if it is visible in the guest's admin namespace 1413200365 M * Bertl also check if creating a new node/file (arbitrary) in the shared directory shows up in the guest 1413200490 M * _dakkon- it is working fine, the only issue is that when I stop or restart the guest vserver, the socket is being destroyed from the original filesystem as well (it exists nowhere) 1413200523 M * _dakkon- untill I do, the bind mount is working fine, and everything (current and new files) are visible 1413200734 M * Bertl ah, okay, got it, so most likely some overeager cleanup script will do that then 1413200750 M * Bertl you can probably solve that in two ways 1413200765 M * Bertl a) make that node immutable in the filesystem 1413200777 M * Bertl b) remove the script from the guest 1413200814 J * mcp ~mcp@wolk-project.de 1413200869 M * _dakkon- thanks checking it :) 1413201601 Q * fisted Remote host closed the connection 1413201618 J * fisted ~fisted@xdsl-78-35-82-188.netcologne.de 1413207987 Q * _dakkon- Quit: Page closed 1413208525 Q * BenG Quit: I Leave 1413211203 J * bananajo ~oftc-webi@213.106.150.130 1413211316 M * bananajo Hi guys, I am thinking of trying fdupes or something similar to automatically hard-link identical files of multiple jails, I was just wondering if there's some reason I'm not aware of that I shouldn't do that 1413211347 M * Bertl well, we do that since many years (more than 10 now?) with unification 1413211347 M * bananajo eh I maint containers sorry 1413211393 M * Guy- bananajo: you should make sure that such hardlinks get broken whenever someone opens such a cross-container hardlink for writing 1413211408 M * Guy- bananajo: otherwise one container could overwrite the file of another 1413211428 M * Bertl which is what unification and the automatic link breaking take care of :) 1413211488 M * bananajo ah, is this handled by vserver at the kernel level automatically? 1413211552 M * Bertl the link breaking, yes, on supported filesystems 1413211566 M * Bertl the unification (now called hashification) is done by userspace tools 1413211571 M * Bertl (i.e. util-vserver) 1413211587 M * gnarface Bertl: which are the supported filesystems, incidentally? 1413211699 M * bananajo thanks, so as long as I have enabled CONFIG_VSERVER_COWBL (Enable COW Immutable Link Breaking) I should be safe with hardlinks being broken at any file change? I'm just using ext4 1413211779 M * Bertl ext2/3/4 are well supported, depending on the patch, we also had reiserfs, xfs, jfs and btrfs 1413211808 M * Bertl (not all of them are in all patches, and they are not that well tested of course) 1413212280 M * bananajo ok so it is something well tried and realistically it's not likely to have a major break all of sudden, right? (sorry for asking again just want to make sure) 1413212325 M * Bertl on ext2/3/4 we are using it since about 10 years, and it works just fine 1413212351 M * bananajo good enough for me then, thanks 1413212387 M * Bertl you're welcome! 1413214753 A * sid3windr giggles at CONFIG_VSERVER_COWBELL 1413214780 M * Ghislain well any cow need one 1413216323 J * bonbons ~bonbons@2001:a18:20f:6001:58a8:3424:bd92:8901 1413223636 J * ntrs ~ntrs@vault08.rosehosting.com 1413224276 Q * FireEgl Remote host closed the connection 1413225274 J * FireEgl ~FireEgl@173-23-76-11.client.mchsi.com 1413226276 J * zerick ~eocrospom@190.187.21.53 1413229122 M * Bertl off for a nap ... bbl 1413229148 N * Bertl Bertl_zZ 1413229238 J * Aiken ~Aiken@d63f.h.jbmb.net 1413232084 Q * bonbons Quit: Leaving 1413235108 Q * ntrs Ping timeout: 480 seconds 1413235416 J * ntrs ~ntrs@vault08.rosehosting.com 1413239244 Q * Ghislain Quit: Leaving. 1413239907 J * dine ~dine@1E5AABVY0.tor-irc.dnsbl.oftc.net 1413239912 P * dine