1595481875 M * Bertl off to bed now ... have a good one everyone! 1595481877 N * Bertl Bertl_zZ 1595482738 J * Ghislain ~ghislain@adsl2.aqueos.com 1595504134 J * fstd_ ~fstd@xdsl-78-35-86-98.nc.de 1595504598 Q * fstd Ping timeout: 480 seconds 1595504926 Q * Aiken Remote host closed the connection 1595511248 N * Bertl_zZ Bertl 1595511251 M * Bertl morning folks! 1595511293 M * gnarface morning Bertl! 1595512645 J * x1450 ~x1450@00027bbf.user.oftc.net 1595512800 M * x1450 hi, I have a quick question about /etc/vservers//rlimits - I'm running Kernel 4.9.96-vs2.3.9.7 with util-vserver 0.30.216-pre3131 and have created a file called "nofile" with the value of "1" however when inspecting limits of processes inside the guest, this seems to have no effect (I was expecting things to explode) 1595512847 M * x1450 the value is reflected in /proc/virtual//limit 1595512896 M * x1450 Am I doing something stupid/missing something here or is it not functional? 1595513099 M * gnarface x1450: did you enter the guest with vserver tools? try connecting to it with ssh and see if your test results change 1595513475 M * x1450 i did but i would've thought the limit applied to services started on vserver start, which is why i set it so low as I'd know it's functional if services won't start 1595513489 M * x1450 SSH also seems fine 1595513553 M * Bertl there are two limits, the ulimit and the rlimit 1595513583 M * Bertl the ulimit acts per process, the rlimit per guest (if implemented and enabled) 1595513770 M * x1450 Is there any other implementation/enablement required other than creating the file with the desired value in rlimit/ 1595513796 M * Ghislain you created it before starting the guest ? 1595513825 M * Bertl the 4.9.x-vs2.3.9.x patch does not implement the RLIMIT_NOFILE 1595513839 M * x1450 that would explain it then 1595513936 J * romster_ ~romster@158.140.215.184 1595513964 Q * romster Ping timeout: 480 seconds 1595514023 M * x1450 Thanks @bertl I'm guessing it won't be making a return? If so which is the last version with it 1595514064 M * Bertl I'm checking that at the moment, actually it could have the necessary code 1595514127 M * Bertl thing is, we never did a patch for 4.9.96 1595514145 M * Bertl so I presume it is based on 4.9.82 updated to 4.9.96 1595514203 M * x1450 ahh potentially 1595514243 M * Bertl and that should have the accounting in place 1595514273 M * Bertl can you check for the guest what the status of the context shows? 1595514346 M * x1450 status from proc/virtual ? 1595514418 M * Bertl /proc/virtual//cacct 1595514447 M * Bertl /proc/virtual//climit 1595514504 Q * romster_ Ping timeout: 480 seconds 1595514525 M * x1450 https://pastebin.com/kM1SihzN 1595514532 M * Bertl tx 1595514624 M * Bertl interesting, so the limit is there, accounting seems to be done as well, but the limit is not enforced 1595514989 J * romster ~romster@158.140.215.184 1595515124 M * Bertl ah, yes, checked with the source, accounting is there, but limit is not enforced 1595515207 M * x1450 ahh :| 1595515219 M * Bertl note that it should actually be pretty easy to enforce it 1595515283 M * Bertl so if you would like to test a patch, I could create one 1595515360 M * x1450 if you're happy to do so then sure :) - I was planning on doing a new kernel build with 4.9.159 soon 1595516004 M * Bertl so current patch is agains 4.9.217 1595516019 M * Bertl and I likely update that in the process to whatever is current 1595516035 M * Bertl that said, the patch should work for older kernel versions as well 1595516257 M * Bertl okay then, I'll see what I can come up with over the weekend 1595516481 M * Hurga would be cool, I'm currently kernel building as well. 1595516505 M * x1450 whatever the latest ver is - i'm good with :) 1595516513 M * x1450 i was just looking at the vserver page and saw 159 on there 1595516641 M * Bertl yeah, I haven't updated that recently, always check http://vserver.13thfloor.at/Experimental/ for patches 1595516791 M * Ghislain unless EU funding come this way i think 4.9 will be the last one ? 1595516999 M * Bertl really depends ... a lot of interest has been expressed to have a patch for newer branches 1595517057 M * Bertl so I'm very like going to do some crowd funding or similar and see how many are willing to contribute 1595517180 M * x1450 What about Patreon for on-going support? 1595517258 M * Bertl I've been thinking about that for quite some time now as well 1595517275 M * Bertl there are also patreon like alternatives in the EU 1595517297 M * x1450 it just came to mind as I had seen the creator of Dokuwiki had one recently 1595517381 M * Bertl 'Steady' for example 1595517443 M * Bertl https://steadyhq.com/en 1595517568 M * x1450 how much would you be looking at raising out of curiosity? 1595517780 M * Bertl that is an excellent questions and the one which kept me so far from actually doing it 1595517784 M * Bertl *question 1595517823 M * Bertl it really depends on the changes in more recent kernels and the number of features we want to port 1595517856 M * Bertl and I didn't look at the changes of 5.x yet (in regard of Linux-VServer that is) 1595517897 M * gnarface there's no 4.19 patch is there? 1595517903 M * gnarface debian current stable is on 4.19 1595517908 M * gnarface (and devuan) 1595517942 M * Bertl but the expected price range would be between 1000 and 3000 EUR depending on the feature set 1595518041 M * x1450 assuming current feature parity? 1595518048 M * gnarface i think you could hit that easily 1595518069 M * x1450 I'm also not an expert but that seems quite low 1595518137 M * Ghislain i think 3k€ is something people can manage to get, i will participate of course 1595518164 M * Ghislain especialy if we can put nested cgroup and make systemd work inside a guest 1595518187 M * Ghislain perhaps some should also be gathered for the utils 1595518213 M * Bertl well, systemd and nested cgroup support is outside the current feature set 1595518233 M * Bertl but we could make those stretch goals or similar 1595518253 M * Ghislain indeed 1595518282 M * Bertl anyway, thanks for the input and feedback, I'll think about it and will do some investigations on recent kernels to get a better idea 1595518286 A * gnarface doesn't need that for devuan 1595518291 M * Ghislain for me if we dont support systemd we will have a good host with allmost no guest installable on it so i think this is a must 1595518317 M * Ghislain well debian is allready outdated and devuan is even more than debian 1595518322 M * x1450 I think systemd is pretty much essential 1595518323 M * Bertl I also really like the idea of regular support via patreon/steady 1595518340 M * Ghislain would love to not have the whole systemd thing but industry is gainst me and i cannot fight it 1595518343 M * gnarface Ghislain: devuan caught up to debian now 1595518360 M * Bertl there are still many distros without systemd 1595518364 M * x1450 Have avoided it for along time but it's everywhere pretty much and not sure how long Devuan will maintain their steam 1595518407 M * Bertl question here: what are the reasons for Linux-VServer compared to LXC if you want to run a bloated systemd guest? 1595518408 M * gnarface so far people seem to still be adopting it at a steady, if slow pace, 1595518455 M * Bertl (note: this is not rethorical, I'm actually interested in good arguments :) 1595518476 M * Bertl *rhetorical 1595518489 M * Ghislain i stick with vserver mostly because of the networking 1595518503 M * Ghislain i can share ip with guests 1595518521 M * Ghislain also i love KISS and lxd do not feel KISS in any way 1595518590 M * gnarface i'd contribute money to a 4.19 patch i could use with the current debian stable kernel on devuan - no new features needed 1595518601 M * gnarface newer would be fine too 1595518633 M * gnarface matching the debian version makes it super easy for me though 1595518661 M * Ghislain for me latest 5 is the one i am interested so i can use btrfs, the older the kernel the less reliable it is 1595518686 M * Ghislain also 4.19 will be lost a lot sooner in term of LTS support 1595518699 M * gnarface meh, it'll be good for a few years at least 1595518703 M * gnarface really 1595518719 M * gnarface as long as you're tracking debian stable anyway 1595518742 M * gnarface counting the time in oldstable it should be supported for most of a decade yet 1595518751 M * Ghislain well this is not as if kernel DROP any api at all since 1972 so safe to go with newer 1595518764 M * Ghislain ;p 1595518781 M * gnarface well so far that's been my experience with most the hardware.... 1595518797 M * gnarface not all of it but luckily the regressions usually aren't in things servers need 1595518819 M * Ghislain ah yes i use recent hardware so there is a little bias from me here sorry ! 1595518903 M * AlexanderS One of the advantages of linux-vserver over lxc are the additional capabilities and flags. 1595519008 M * Ghislain for now i would prefer 5.7 but seems 5.4 is the last LTS we have 1595519100 M * x1450 yeah io_uring in 5.8 and wireguard in 5.6 would be nice 1595519108 M * x1450 so next 5.x LTS would be awesome 1595519173 M * Ghislain indeed, they did not say if they will LTS any new one but in any way if we got the leap to 5.X then it will be easier to maintain and go up to the next LTS 1595519280 M * Ghislain anyway Bertl, to make a summary i prefer vserver to lxd for now because it is easier for me to play with the network and share ips with the host for exemple. Also i really like the small footprint and KISS feel about it. But i agree that for bloated LAMP server lxd would be a way to go 1595521637 M * Hurga BTW, before I start tinkering again... does anyone have a HOWTO like recipe for cgroups inside vserver? Devuan beowulf as a vserver guest needs them for elogind 1595521692 M * Bertl cgroups inside a guest is just a question of permissions 1595521706 M * Bertl make the guest permissive enough and cgroups should work 1595521725 M * Hurga any hint which kinds of permissions I should look at? 1595521735 M * Bertl note that you need to have hierarchical cgroups and a cgroup per guest to start with 1595521763 M * Bertl (which sometimes causes problems for applications assuming to work with the root cgroup system) 1595521815 M * Hurga So far I don't see where I'm going to need cgroups except for elogind 1595521872 M * Bertl isn't elongind part of systemd? 1595521891 M * gnarface no it's a drop-in replacement for a part of it, but you don't necessarily need it either 1595521891 M * Bertl ah, that was extracted from systemd ... 1595521932 M * gnarface Hurga: if you're not using gui disk mounts, graphical login prompts or the like, you don't even need it... could it have been included in your default guest install by mistake? 1595521958 M * Bertl Hurga: try to give all capabilities to a guest with hierarchical cgroups set up properly 1595521962 M * Hurga gnarface: I tried to make it a minimal install. But let me try to remove it. 1595521979 M * Bertl and check what fails (if it fails at all) 1595521999 M * Hurga Bertl: What is "properly?" :) The root server has /sys/fs/cgroup 1595522020 M * gnarface Hurga: some stuff might pull it in during upgrades unless you add --no-install-recommends 1595522026 M * Bertl Hurga: I presume the guest will require a cgroup mount entry from the hierarchy 1595522727 M * x1450 I realize this maybe a odd question, with regards to LXC - would it be possible/an option to have more vserver like restriction and vserver style networking? 1595522858 M * x1450 with LXC being upstream, assuming they'd be willing to accept the contributions and it being practical - wouldn't you get the best of both? More hands available/activity by virtue of the existing devs on LXC, LXC being mainlined 1595523640 M * Bertl the problem here is that the Linux-VServer framework works differently (because it has been developed long before cgroups were a thing) than the mainline isolation system 1595523665 M * Bertl which in turn means that any feature tied to the Linux-VServer framework cannot be simply 'ported' to mainline 1595523736 M * Bertl I also do remember that mainline folks decided against a light-weight networking approach 1595523765 M * Bertl mainly because it has some corner cases which are probably not worth solving 1595523792 M * Bertl so yes, it would definitely be possible to make a network isolation cgroup 1595523819 M * Bertl but no, I don't think it would not be accepted upstream 1595523874 M * Bertl what would be the benefit? probably not much, you still need a pretty invasive patch, it would require a lot of testing and external maintainance anyway 1595524083 M * Hurga since someone recetly asked me... would it be possible to start a docker image on a vserver kernel? 1595524117 M * Bertl I don't see why that shouldn't work 1595524529 M * Bertl off for now ... bbl 1595524534 N * Bertl Bertl_oO 1595524659 M * x1450 Thanks for your help :) 1595524670 Q * x1450 Quit: Leaving 1595531753 Q * hijacker Remote host closed the connection 1595531918 J * hijacker ~nikolay@external.oldum.net 1595534441 J * Aiken ~Aiken@b951.h.jbmb.net 1595534922 Q * hijacker 1595534975 J * hijacker ~nikolay@external.oldum.net 1595535053 Q * hijacker 1595535238 J * hijacker ~nikolay@external.oldum.net 1595537472 Q * Ghislain Quit: Leaving. 1595537591 Q * Jb_boin Ping timeout: 480 seconds 1595537885 J * Jb_boin ~dedior@proxad.eu 1595547644 Q * guerby Read error: Connection reset by peer 1595547686 J * guerby ~guerby@ip165.tetaneutral.net