August 2019 - CoreOS - Fedora mailing-lists

Re: R: Re: Default Max Open File too high?
by Andrew Jeddeloh 30 Aug '19

30 Aug '19

Note: This list is for Fedora CoreOS, not Container Linux, though since it appears this is general Linux change it applies to both. The Container Linux mailing list is https://groups.google.com/forum/#!forum/coreos-user but for things like this that are possibly bugs the best place is https://github.com/coreos/bugs. The Fedora CoreOS equivalent of coreos/bugs is https://github.com/coreos/fedora-coreos-tracker. - Andrew On Fri, Aug 30, 2019 at 6:44 AM Domenico Viggiani <viggiani(a)hotmail.com> wrote: > > Very useful info! > > BTW, I fully agree with rationale behind the choice. > > Thank you > ________________________________ > Da: Kamil Paral <kparal(a)redhat.com> > Inviato: venerdì 30 agosto 2019 15:23 > A: coreos(a)lists.fedoraproject.org <coreos(a)lists.fedoraproject.org> > Oggetto: [CoreOS] Re: Default Max Open File too high? > > On Fri, Aug 30, 2019 at 3:11 PM <domenico.viggiani(a)gmail.com> wrote: > > Hi, > I'm having some issues with value of Max Open Files on CoreOS 2079.4.0: > # sudo cat /proc/sys/fs/nr_open > 1073741816 > It is "too high" compared to Linux usual value (1048576 ) and it causes some troubles ("unable to allocate file descriptor table") to some Java applications, similar to this: > https://bugs.openjdk.java.net/browse/JDK-8150460 > > Any suggestion? > > > AFAIK, this is not CoreOS specific nor Fedora specific. It is the new "Linux" default for all distributions using systemd (and not overriding the value). Here's the relevant change: > https://github.com/systemd/systemd/pull/10244 > And from the diff, this part is relevant: > > * The fs.nr_open and fs.file-max sysctls are now automatically bumped > to the highest possible values, as separate accounting of file > descriptors is no longer necessary, as memcg tracks them correctly as > part of the memory accounting anyway. Thus, from the four limits on > file descriptors currently enforced (fs.file-max, fs.nr_open, > RLIMIT_NOFILE hard, RLIMIT_NOFILE soft) we turn off the first two, > and keep only the latter two. ... > > I'm not a developer, but this looks like something that needs to get fixed in OpenJDK. Perhaps there is someone who can advise some workaround. > _______________________________________________ > CoreOS mailing list -- coreos(a)lists.fedoraproject.org > To unsubscribe send an email to coreos-leave(a)lists.fedoraproject.org > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/coreos@lists.fedoraproject.org

1 0

Default Max Open File too high?
by domenico.viggiani＠gmail.com 30 Aug '19

30 Aug '19

Hi, I'm having some issues with value of Max Open Files on CoreOS 2079.4.0: # sudo cat /proc/sys/fs/nr_open 1073741816 It is "too high" compared to Linux usual value (1048576 ) and it causes some troubles ("unable to allocate file descriptor table") to some Java applications, similar to this: https://bugs.openjdk.java.net/browse/JDK-8150460 Any suggestion?

3 2

Deep Dive Session on Ignition
by Dusty Mabe 28 Aug '19

28 Aug '19

If you're interested in ignition Andrew will be doing a session on it tomorrow at 9am US Pacific time. There is more info at the following links: - https://groups.google.com/d/msg/okd-wg/G_r_epirIG0/YVGeeOskEQAJ - https://commons.openshift.org/events.html#event|7885|995 Dusty

3 2

Re: FYI: opensuse decision regarding configuration files in /etc and /usr/etc
by Thorsten Kukuk 28 Aug '19

28 Aug '19

Hi, On Wed, Aug 28, Colin Walters wrote: > > > On Fri, Aug 16, 2019, at 1:11 PM, Thorsten Kukuk wrote: > > > More important was, that the absolut majority of people who gave > > feedback wanted /usr/etc, and the acceptance by many users wass more > > important than a few people where /etc is a symlink to /usr/etc. > > Discussion on this is scattered around a whole bunch of places; I probably would have done something like a github gist or hackmd.io doc, or just a generic web page, and linked the mail discussions to that. There was a mail several months or so ago with this github Url, which we used for the discussions: https://github.com/thkukuk/atomic-updates_and_etc/blob/master/README.md We also started to create an openSUSE specific wiki page: https://en.opensuse.org/openSUSE:Packaging_UsrEtc > The Subject line of this email is "Re: FYI: opensuse decision regarding configuration files in /etc and /usr/etc" which makes me think a decision was made, but what is it exactly? > > We have a fairly nontrivial stake in this outcome given that OSTree has been shipping /usr/etc for *years* and it's worked quite successfully. We are still in the early state of adjusting the infrastructure/checks and create PoCs. So it is still changeable if others want to join and come up with a better alternative name for /usr/etc. But this really requires a strong commitment to do the same, not that we change the paths and still nobody follows with this. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 247165, AG München)

2 1

Re: FYI: opensuse decision regarding configuration files in /etc and /usr/etc
by Thorsten Kukuk 28 Aug '19

28 Aug '19

On Fri, Aug 16, Florian Weimer wrote: > * Dusty Mabe: > > > The opensuse team reached out to us before to try to collaborate on a path forward > > for configuration files. They proposed this upstream to the fhs-discuss mailing list [1]. > > Now they have made a decision [2]. > > > > Should we try to join them? > > > > [1] https://lists.linuxfoundation.org/pipermail/fhs-discuss/2019-June/000509.ht… > > [2] https://lists.opensuse.org/opensuse-packaging/2019-08/msg00002.html > > I already pointed out that /usr/etc and /etc with totally different > purposes is confusing after UsrMove. I'm not sure why this point, while > acknowledged initially, was ignored in the end. https://fedoraproject.org/wiki/Features/UsrMove => /etc is a directory, not a symlink to /usr/etc. We couldn't find any definition of UsrMove, where /etc is a symlink to /usr/etc. Could be very well that somebody did it, but not by definition. More important was, that the absolut majority of people who gave feedback wanted /usr/etc, and the acceptance by many users wass more important than a few people where /etc is a symlink to /usr/etc. If the majority does not like the path, they will not follow. So the idea would be already fail on start. And you can just remove the /etc symlink and make it an own directory again, it should just work. So we did not ignore it, but this sounded more like a theoretical problem and not a real one. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Mary Higgins, Sri Rasiah, HRB 21284 (AG Nuernberg)

3 2

Fedora CoreOS meeting canceled for 2019-08-28
by Benjamin Gilbert 27 Aug '19

27 Aug '19

Hi all, Since there are no fedora-coreos-tracker tickets with the `meeting` label, the Fedora CoreOS IRC meeting for 2019-08-28 is canceled. Sincerely, --meeting canceler shell script

1 0

[Fedocal] Reminder meeting : Fedora CoreOS Group Weekly Meeting
by dusty＠dustymabe.com 27 Aug '19

27 Aug '19

Dear all, You are kindly invited to the meeting: Fedora CoreOS Group Weekly Meeting on 2019-08-28 from 16:30:00 to 17:30:00 UTC At fedora-meeting-1(a)irc.freenode.net The meeting will be about: This is the meeting for the Fedora CoreOS Working Group. We typically go over previous meeting action items and then cover all tickets with the meeting keyword: https://github.com/coreos/fedora-coreos-tracker/labels/meeting. For how to run the meeting, see https://github.com/coreos/fedora-coreos-tracker#steps-to-run-the-meeting Source: https://apps.fedoraproject.org/calendar/meeting/9437/

1 0

Running systemd based docker service - permission issues
by Shivaram Mysore 24 Aug '19

24 Aug '19

Hello, I have a simple service definition file - nginx-test.service and located in user *core* home directory (/var/home/core) : [Unit] Description=This a basic Nginx service for a testing After=docker.service Requires=docker.service [Install] WantedBy=multi-user.target [Service] RestartSec=10 Restart=always ExecStartPre=-/usr/bin/docker kill nginx-test ExecStartPre=-/usr/bin/docker rm nginx-test ExecStart=/usr/bin/docker run \ --name=nginx-test \ --network=host \ --volume=/var/home/core/nginx/config:/etc/nginx/conf \ --volume=/var/home/core/nginx/html:/usr/share/nginx/html \ nginx:1.17.2-alpine nginx -c /etc/nginx/conf/nginx.conf -g "daemon off;" ExecStop=/usr/bin/docker stop nginx-test This file is: $ sudo cp nginx-test.service /etc/systemd/system/ $ sudo systemctl daemon-reload $ sudo systemctl start nginx-test $ pwd /var/home/core $ tree nginx nginx ├── config │ └── nginx.conf └── html └── index.html This exact configuration works on my CoreOS AMI on AWS - which we use for the last couple of years. But, it does not work with Fedora CoreOS on my bare metal hardware. I even changed directory/file permissions on nginx from core to root and still get the errors: Aug 24 02:53:36 rhino docker[28805]: nginx-test Aug 24 02:53:36 rhino systemd[1]: Started This a basic Nginx service for a testing. Aug 24 02:53:37 rhino docker[28813]: 2019/08/24 02:53:37 [emerg] 1#1: open() "/etc/nginx/conf/nginx.conf" failed (13: Permission denied) Aug 24 02:53:37 rhino docker[28813]: nginx: [emerg] open() "/etc/nginx/conf/nginx.conf" failed (13: Permission denied) Aug 24 02:53:38 rhino systemd[1]: nginx-test.service: Main process exited, code=exited, status=1/FAILURE Aug 24 02:53:38 rhino systemd[1]: nginx-test.service: Failed with result 'exit-code'. $ ls -l nginx/config/ total 4 -rw-r--r--. 1 root root 3735 Aug 24 01:08 nginx.conf Is there a new way to make this work? Thanks & Regards /Shivaram

2 2

CoreOS does not process ignition files on a system that has MMC as the only storage device
by Shivaram Mysore 23 Aug '19

23 Aug '19

[ 23.607625] rhino.road.example.org ignition[907]: INFO : files: createUsers: checking if user "core" exists: [Attention] exit status 1: Cmd: "chroot" "/sysroot" "id" "core" Stdout: id: ‘core’: no such user [ 23.624949] rhino.road.example.org ignition[907]: INFO : files: createUsers: op(1): [started] creating or modifying user "core" [ 23.624949] rhino.road.example.org ignition[907]: DEBUG : files: createUsers: op(1): executing: "useradd" "--root" "/sysroot" "--home-dir" "/home/core" "--create-home" "--password" "*" "--comment" "CoreOS Admin" "--gid" "core" "--groups" "adm,sudo,systemd-journal,wheel,docker,rkt,portage" "--shell" "/bin/bash" "core" [ 23.624949] rhino.road.example.org ignition[907]: CRITICAL : files: createUsers: op(1): [failed] creating or modifying user "core": exit status 6: Cmd: "useradd" "--root" "/sysroot" "--home-dir" "/home/core" "--create-home" "--password" "*" "--comment" "CoreOS Admin" "--gid" "core" "--groups" "adm,sudo,systemd-journal,wheel,docker,rkt,portage" "--shell" "/bin/bash" "core" Stdout: "" Stderr: "useradd: group 'core' does not exist\n" CRITICAL : Ignition failed: failed to create users/groups: failed to create users: failed to create user "core": exit status 6: Cmd: "useradd" "--root" "/sysroot" "--home-dir" "/home/core" "--create-home" "--password" "*" "--comment" "CoreOS Admin" "--gid" "core" "--groups" "adm,sudo,systemd-journal,wheel,docker,rkt,portage" "--shell" "/bin/bash" "core" Stdout: "" Stderr: "useradd: group 'core' does not exist\n" I would be happy to provide detailed logs CoreOS was PXE installed with options: KERNEL fedora-coreos-30.20190801.0-installer-kernel APPEND ip=dhcp rd.neednet=1 initrd=fedora-coreos-30.20190801.0-installer-initramfs.img console=tty0 console=ttyS0,115200n8 coreos.inst=yes coreos.inst.text=yes coreos.inst.install_dev=mmcblk0 coreos.autologin=tty1 coreos.autologin=ttyS0 coreos.inst.image_url=http://10.20.30.2:8000/fedora-coreos-30.20190801.0-metal.raw.xz coreos.inst.ignition_url=http://10.20.30.2:8000/bare_metal_ignition.json IPAPPEND 2 $ ~/bin/fcct -version Fedora CoreOS Config Transpiler v0.2.0 bare_metal_ignition.json was generated with fcct with the below YAML file variant: fcos version: 1.0.0 passwd: users: - name: core ssh_authorized_keys: - ssh-rsa AAAAB1LR7 coreos_metal home_dir: /home/core no_create_home: false primary_group: core groups: - wheel - sudo - docker - rkt - systemd-journal - portage shell: /bin/bash storage: files: - path: /etc/hosts user: name: root group: name: root contents: source: http://10.20.30.2:8000/hosts compression: null mode: 0644

2 4

automated testing on EC2
by Kamil Paral 21 Aug '19

21 Aug '19

Hey folks, it seems likely we'll have a new release criterion in Fedora QA soon, roughly "Fedora must work on Amazon EC2". In our yesterday's meeting we wondered whether your team has any automated testing that would be relevant for us. I know you have an automated test suite that gets run regularly, but do you run it just locally or in the clouds as well? Do you run it on EC2? How often? There are different instance types in EC2, which ones do you use? Can we access the test results somewhere, to have a look whether everything looks ok-ish regarding our use case? Thanks a lot. Kamil Fedora QA

2 2

2024

2023

2022

2021

2020

2019

2018

CoreOS August 2019