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.
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:
> I'm having some issues with value of Max Open Files on CoreOS 2079.4.0:
> # sudo cat /proc/sys/fs/nr_open
> 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:
> 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:
> 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://email@example.com
I'm having some issues with value of Max Open Files on CoreOS 2079.4.0:
# sudo cat /proc/sys/fs/nr_open
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:
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:
We also started to create an openSUSE specific wiki page:
> 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 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)
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 .
> > Now they have made a decision .
> > Should we try to join them?
> >  https://lists.linuxfoundation.org/pipermail/fhs-discuss/2019-June/000509....
> >  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.
=> /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
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 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)
I have a simple service definition file - nginx-test.service and located in
user *core* home directory (/var/home/core) :
Description=This a basic Nginx service for a testing
ExecStartPre=-/usr/bin/docker kill nginx-test
ExecStartPre=-/usr/bin/docker rm nginx-test
ExecStart=/usr/bin/docker run \
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
$ tree nginx
│ └── nginx.conf
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: nginx-test
Aug 24 02:53:36 rhino systemd: Started This a basic Nginx service for a
Aug 24 02:53:37 rhino docker: 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: nginx: [emerg] open()
"/etc/nginx/conf/nginx.conf" failed (13: Permission denied)
Aug 24 02:53:38 rhino systemd: nginx-test.service: Main process exited,
Aug 24 02:53:38 rhino systemd: nginx-test.service: Failed with result
$ ls -l nginx/config/
-rw-r--r--. 1 root root 3735 Aug 24 01:08 nginx.conf
Is there a new way to make this work?
Thanks & Regards
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.