IRC logs for #baserock for Tuesday, 2015-09-22

*** zoli__ has joined #baserock00:07
*** benbrown_ has quit IRC00:14
*** benbrown_ has joined #baserock00:15
*** Zara has quit IRC00:15
*** Zara has joined #baserock00:17
*** fay_ has quit IRC00:24
*** fay_ has joined #baserock00:24
*** paulw has joined #baserock06:19
*** jjardon has quit IRC07:41
*** lachlanmackenzie has quit IRC07:41
*** drnic has quit IRC07:41
*** bashrc_ has joined #baserock08:06
*** mariaderidder has joined #baserock08:22
*** jonathanmaw has joined #baserock08:23
*** rdale has joined #baserock08:50
*** toscalix__ has joined #baserock08:51
*** toscalix__ has quit IRC08:55
*** inara has quit IRC08:56
*** ssam2 has joined #baserock09:02
*** ChanServ sets mode: +v ssam209:02
*** inara has joined #baserock09:02
*** franred has joined #baserock09:02
*** toscalix__ has joined #baserock09:05
*** toscalix__ has quit IRC09:23
*** jjardon has joined #baserock09:23
*** toscalix__ has joined #baserock09:25
ssam2i was wondering why Fedora didn't have resource limits in place to stop the Git fork-bomb from locking up my system...09:31
ssam2having dug a bit deeper, it has a max 'nproc' set for all users *except* root09:31
ssam2but being as I was running as root in a Baserock chroot, there were no limits09:31
ssam2more reasons to not require root !09:32
*** toscalix__ has quit IRC09:33
*** toscalix__ has joined #baserock09:35
*** toscalix__ has quit IRC09:45
*** toscalix__ has joined #baserock09:51
*** franred has quit IRC09:54
*** lachlanmackenzie has joined #baserock09:56
*** toscalix__ has quit IRC09:59
*** drnic has joined #baserock10:00
*** toscalix__ has joined #baserock10:03
*** mariaderidder has quit IRC10:03
*** franred has joined #baserock10:10
*** toscalix__ has quit IRC10:12
*** mariaderidder has joined #baserock10:15
*** paulw has quit IRC10:15
*** paulw has joined #baserock10:19
KinnisonOr to ulimit your chroot :-)10:56
* pedroalvarez waves10:56
*** ssam2 has quit IRC10:59
*** ssam2 has joined #baserock11:01
*** ChanServ sets mode: +v ssam211:01
ssam2Kinnison: how can I ulimit just the chroot ?11:01
ssam2I can't find anything in 'man schroot' about that11:01
Kinnison suggests it must be possible11:01
Kinnisonthough I'll admit that I'm just googling and looking for plausible hits11:02
* pedroalvarez will be trying today to deploy baserock to aws!!11:02
ssam2I guess I could just run 'ulimit' on chroot startup11:02
*** toscalix__ has joined #baserock11:07
*** ssam2 has quit IRC11:11
*** ssam2 has joined #baserock11:11
*** ChanServ sets mode: +v ssam211:11
ssam2clearly that didn't work.11:11
*** lachlan75 has joined #baserock11:12
tiagogomes_If it builds in one place and not in another, have you tried to set max-jobs to 1?11:12
pedroalvarezwrong keys in the wrong window?11:13
ssam2tiagogomes_ I wondered why you were repeating the same question as yesterday. but I guess you are wondering why as well :)11:13
radiofreei read it as him "asking HUG!? WELL HAVE YOU?!"11:13
radiofreeerm.. s/HUG/HUH11:14
* tiagogomes_ hates xchat11:14
De|taor hugs xchat?11:14
ZaraI tabbed into this and briefly thought radiofree was asking #baserock for a hug.11:15
ssam2so, if I run `ulimit -u 10`, then fork 20 process, I get 20 processes11:15
ssam2seems that ulimit as root doesn't actually do anything anyway, or something11:15
ssam2and if I run it as my normal user, bash breaks immediately with 'No child processes'11:16
ssam2so I guess they just don't apply to root, at least with this kernel11:16
tiagogomes_ins't cgroups the modern way to limit processes11:18
ssam2yes, cgroups might work. that's no excuse for the existing method to just not work, though11:18
ssam2I guess I could create a .slice file to define a cgroup with a process limit, then run the chroot under `systemd-run` so it's in that slice11:19
pedroalvarez"The Amazon EC2 CLI tools require Java"11:21
rjek*installs Java* "The Amazon EC2 CLI tools requires a newer version of Java than you have"11:22
* rjek sets fire to things11:22
ssam2:( there doesn't seem to be a way to limit number of subprocesses a .slice can have11:23
ssam2I can set a limit on how much CPU time it can use, but i don't really trust it, having watched Linux grind to a halt many times already this week11:24
ssam2I guess I can set 'CPUQuota=1%' and then see if it gets more than 1% CPU11:24
ssam2to test whether it works11:25
ssam2nope, I can still get something to use 100% CPU inside that slice.11:27
ssam2so we definitely need to stop being root :-)11:29
radiofreessam2: do you have /sys/fs/cgroup/cpu/cpu.cfs_quota_us ?11:33
ssam2radiofree: yes, it seems to be set to '-1'11:34
ssam2oh, inside the Baserock chroot that file doesn't exist at all11:34
ssam2 /sys/fs/cgroup is an empty dir within the chroot11:35
radiofreessam2: try mount -t tmpfs cgroup_root /sys/fs/cgroup11:38
radiofreethen mount the cgroups you need manually11:38
radiofreee,g mkdir /sys/fs/cgroup/cpuset && mount -t cgroup -ocpuset cpuset /sys/fs/cgroup/cpuset11:38
radiofreefor cpuset11:38
ssam2that works, ta11:39
ssam2so I could do this on chroot startup to manually set resource limits inside the chroot using cgroups?11:39
radiofreeprobably, i've never used cgroups in a chroot11:39
ssam2i'll try it later11:41
ssam2here's another confusing issue (that triggered the Git problem)11:41
radiofreeyou're probably want the cpu,cpuacct group as well11:42
radiofreemkdir /sys/fs/cgroup/cpu && mount -t cgroup -ocpu,cpuacct cpu,cpuacct /sys/fs/cgroup/cpu11:42
ssam2oh, the group name *contains* the comma11:42
ssam2I tried just 'cpu' and it didn't work11:42
radiofreeyes, comma should work11:42
ssam2hmm, and build-chroot.slice appears within that directory, so the cgroup has been created11:43
radiofreeappears within that directory in a sub folder or in tasks?11:44
ssam2in a sub folder11:44
radiofreewhat does `cat build-chroot.slice/tasks` contain11:44
ssam2empty file11:44
radiofreenothing launched in it then11:45
radiofreeyou can echo pids to that file though11:45
ssam2right. I did `systemd-run --slice build-chroot.slice -t enter-baserock`11:45
ssam2but I guess that didn't do what I thought it would11:46
radiofreecheck /sys/fs/cgroup/cpu/build-chroot.slice/tasks on your host11:46
radiofree(assuming you were running that command on your host)11:47
ssam2that does seem to put 'bash' and its subprocesses in the cgroup11:48
ssam2but they can still use 100% CPU11:48
ssam2you'd think that would limit it to 1% CPU :-)11:49
radiofreedoes CPUQuota set cpu.shares?11:50
ssam2not sure what it does11:50
ssam2`man systemd.resource-control` says it controls cpu.cfs_quota_us11:51
ssam2hmm, I may have put everything into the wrong cgroup11:51
ssam2ah! it works!!11:52
ssam2suddenly my chroot has become incredibly slow :-)11:52
ssam2thanks for your help. I'm not sure if this will actually save me from future fork bombs, but it's useful anyway11:52
radiofreei found a decent memory.kmem.limit_in_bytes value in your cgroup more useful for protecting against fork bombs11:54
ssam2ok, cool.11:54
radiofreei suppose without a memory limit the fork bomb can still happen, just a lot slower11:54
pedroalvarezI wonder if CONFIG_XEN would be enough for enabling xen guest drivers11:57
pedroalvarezoh, it has dependencies12:00
ssam2any reason not to enable it in the reference Baserock Linux config ?12:05
ssam2FWIW it's enabled in the Fedora Linux config on my desktop12:06
pedroalvarezno reason, I was going to :)12:08
pedroalvarezI'm confused about "depends on X86_64 || (X86_32 && X86_PAE)"12:19
ssam2PAE is an optional feature of X86 CPUs12:19
pedroalvarezI've added the former to 64b and the later to 32b bsps12:19
ssam2my home laptop actually doesn't have PAE, I quit using Ubuntu because they started requiring it in their kernels12:20
ssam2while Fedora still doesn't12:20
franredpedroalvarez, catee does not show any dependency with x86_PAE12:21
pedroalvarezfranred: it does in "arch/x86/xen/Kconfig"12:22
pedroalvarezkernel source12:22
pedroalvarezalso in that page you linked12:22
franredhehe sorry, I talked pretty fast :S12:22
pedroalvarezno worries :)12:25
ssam2Next puzzle: I have a .git directory with mode '700'. 'ls .git' works,12:28
ssam2but 'linux-user-chroot /staging-dir ls .git' fails with EPERM.12:28
ssam2this is what triggered the Git fork-bomb problem I've been having12:28
ssam2EACCES, not EPERM12:35
persiaAs which user are you running each command?12:36
ssam2all as root12:36
ssam2HOWEVER I just noticed the .git directory is not owned by root12:36
ssam2I missed that before12:36
richard_mawah, and linux-user-chroot drops CAP_DAC_OVERRIDE12:36
persiaAh, heh, so you're being clobbered by linux-user-chroot removing capabilities.  Good catch :)12:37
ssam2not quite sure how to fix this.. the build tool could warn if it detects this situation, perhaps12:37
ssam2probably better if it just forces the ownership in its copy of the .git directory, though12:37
persiaHow is the git directory created?12:38
ssam2some kind of copy operation from $cache-dir/gits/12:38
ssam2might actually be a `git clone`, I can't remember12:38
richard_mawssam2: be careful to ensure that the copy operation doesn't hardlink the .git blobs12:38
richard_mawssam2: otherwise chowning would cause someone else's git repository to break12:38
persiaThat makes it slower though, but probably worth it.  Operating on a git repo when one isn't the repo owner isn't ideal for several reasons.12:39
ssam2morphlib.git.copy_repository seems to do 'cp -a' basically12:39
ssam2so we should be grand12:39
persiaAnd if there exists a goal of being able to use a tool as non-root, the cache repo is probably owned by non-root, so the root in linux-user-chroot needs to recreate to claim safely.12:40
ssam2ybd uses 'git clone --no-hardlinks'12:40
ssam2yes, I guess it should chown to the running user, rather than hardcoding root12:40
persia`git clone --no-hardlinks` should do the chown properly (as a side effect).12:41
persia`cp -a` preserves ownership when run by root, complicating things.12:41
ssam2right. maybe I can replace it all with `git clone --no-hardlinks` instead.12:41
ssam2I think there was some speed reason for doing it the more complex way with 'cp -a'12:42
persiaIf you run that *inside* the linux-user-chroot, it safely has the right permissions.  If you run it outside, you may end up with some odd permissions for some sorts of chroot management (if we get a non-linux-user-chroot working reliably)12:42
*** paulw has quit IRC13:59
*** inara has quit IRC14:12
*** inara has joined #baserock14:18
*** ssam2 has quit IRC14:24
*** ssam2 has joined #baserock14:25
*** ChanServ sets mode: +v ssam214:25
*** franred has quit IRC14:39
pedroalvarezlooks like ec2 clients want to be too clever:14:46
pedroalvarezClient.Unsupported: No bootable partition found. (Service: AmazonEC2; Status Code: 400; Error Code: Unsupported; Request ID: de37a3df-3993-44d0-adc1-9983042694b2)14:46
pedroalvarezI'm going to try with the partitioning patches, and see what happens14:46
* richard_maw crosses fingers14:58
* richard_maw fddiujhnds it diufficulkt mto type this wsay14:58
pedroalvarezI found errors like "Client.Unsupported: Platform type Windows is incompatible with partition type Linux." on the way14:58
* richard_maw raises eye row14:59
pedroalvarezheh, definitely is not your day15:00
* richard_maw blames the early start15:03
*** zoli__ has quit IRC15:04
*** toscalix__ has quit IRC15:06
pedroalvarezI have no clue how to start the image i've uploaded :S15:06
*** Walkerdine__ has joined #baserock15:09
*** franred has joined #baserock15:24
*** zoli__ has joined #baserock16:20
*** Walkerdine__ has quit IRC16:37
*** mariaderidder has quit IRC16:46
*** jonathanmaw has quit IRC16:47
*** bashrc_ has quit IRC17:02
*** ssam2 has quit IRC17:05
*** zoli__ has quit IRC17:12
*** zoli__ has joined #baserock17:26
*** lachlan75 has quit IRC17:29
*** franred has quit IRC17:46
*** rdale has quit IRC18:04
*** zoli__ has quit IRC19:08
*** Walkerdine__ has joined #baserock19:54
*** paulw has joined #baserock20:06
*** zoli__ has joined #baserock20:22
*** paulw has quit IRC20:26
*** zoli__ has quit IRC20:30
*** zoli__ has joined #baserock20:53
*** Walkerdine__ has quit IRC21:01
*** Walkerdine__ has joined #baserock21:01
*** Walkerdine__ has quit IRC21:29
*** Walkerdine__ has joined #baserock21:51
*** inara has quit IRC22:10
*** inara has joined #baserock22:13
*** petefoth has quit IRC22:47
*** gary_perkins has quit IRC22:48
*** fay_ has quit IRC22:48
*** tiagogomes_ has quit IRC22:48
*** flatmush has quit IRC22:48
*** nowster has quit IRC22:49
*** edcragg has quit IRC22:49
*** gary_perkins has joined #baserock22:54
*** nowster has joined #baserock22:55
*** edcragg has joined #baserock22:55
*** flatmush has joined #baserock22:55
*** tiagogomes_ has joined #baserock22:56
*** fay_ has joined #baserock22:56
*** petefoth has joined #baserock22:57
*** Walkerdine__ has quit IRC23:21

Generated by 2.15.3 by Marius Gedminas - find it at!