Re: R: Re: Default Max Open File too high?
by Andrew Jeddeloh
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
4 years, 7 months
Default Max Open File too high?
by domenico.viggiani＠gmail.com
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?
4 years, 7 months
Re: FYI: opensuse decision regarding configuration files in /etc and /usr/etc
by Thorsten Kukuk
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)
4 years, 8 months
Re: FYI: opensuse decision regarding configuration files in /etc and /usr/etc
by Thorsten Kukuk
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....
> > [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)
4 years, 8 months
Fedora CoreOS meeting canceled for 2019-08-28
by Benjamin Gilbert
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
4 years, 8 months
Running systemd based docker service - permission issues
by Shivaram Mysore
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
4 years, 8 months
CoreOS does not process ignition files on a system that has MMC as the only storage device
by Shivaram Mysore
[ 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
4 years, 8 months
automated testing on EC2
by Kamil Paral
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
4 years, 8 months
