Elasticsearch 5 on Jessie: NoSuchFileException /sys/fs/cgroup/cpu/cpu.cfs_period_us

Hi guys,

we recently upgraded from 2.4 to ES 5.6 on our cluster.

On our server with Debian jessie

uname -a
Linux server 3.16.0-4-amd64 #1 SMP Debian 3.16.51-3 (2017-12-13) x86_64 GNU/Linux

elasticsearch is throwing quite a few Debug-exceptions in the log:

[2019-02-25T09:43:07,469][DEBUG][o.e.m.o.OsProbe ] error reading control group stats
java.nio.file.NoSuchFileException: /sys/fs/cgroup/cpu/cpu.cfs_period_us
at sun.nio.fs.UnixException.translateToIOException(UnixException.java:86) ~[?:?]
at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102) ~[?:?]
at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107) ~[?:?]
at sun.nio.fs.UnixFileSystemProvider.newByteChannel(UnixFileSystemProvider.java:214) ~[?:?]
at java.nio.file.Files.newByteChannel(Files.java:361) ~[?:1.8.0_161]
at java.nio.file.Files.newByteChannel(Files.java:407) ~[?:1.8.0_161]
at java.nio.file.spi.FileSystemProvider.newInputStream(FileSystemProvider.java:384) ~[?:1.8.0_161]
at java.nio.file.Files.newInputStream(Files.java:152) ~[?:1.8.0_161]
at java.nio.file.Files.newBufferedReader(Files.java:2784) ~[?:1.8.0_161]
at java.nio.file.Files.readAllLines(Files.java:3202) ~[?:1.8.0_161]
at java.nio.file.Files.readAllLines(Files.java:3242) ~[?:1.8.0_161]
at org.elasticsearch.monitor.os.OsProbe.readSingleLine(OsProbe.java:185) ~[elasticsearch-5.6.14.jar:5.6.14]
at org.elasticsearch.monitor.os.OsProbe.readSysFsCgroupCpuAcctCpuCfsPeriod(OsProbe.java:300) ~[elasticsearch-5.6.14.jar:5.6.14]
at org.elasticsearch.monitor.os.OsProbe.getCgroupCpuAcctCpuCfsPeriodMicros(OsProbe.java:286) ~[elasticsearch-5.6.14.jar:5.6.14]
at org.elasticsearch.monitor.os.OsProbe.getCgroup(OsProbe.java:423) [elasticsearch-5.6.14.jar:5.6.14]
at org.elasticsearch.monitor.os.OsProbe.osStats(OsProbe.java:464) [elasticsearch-5.6.14.jar:5.6.14]
at org.elasticsearch.monitor.os.OsService$OsStatsCache.refresh(OsService.java:64) [elasticsearch-5.6.14.jar:5.6.14]
at org.elasticsearch.monitor.os.OsService$OsStatsCache.refresh(OsService.java:57) [elasticsearch-5.6.14.jar:5.6.14]
at org.elasticsearch.common.util.SingleObjectCache.getOrRefresh(SingleObjectCache.java:54) [elasticsearch-5.6.14.jar:5.6.14]
at org.elasticsearch.monitor.os.OsService.stats(OsService.java:54) [elasticsearch-5.6.14.jar:5.6.14]
at org.elasticsearch.node.NodeService.stats(NodeService.java:106) [elasticsearch-5.6.14.jar:5.6.14]
at org.elasticsearch.action.admin.cluster.node.stats.TransportNodesStatsAction.nodeOperation(TransportNodesStatsAction.java:77) [elasticsearch-5.6.14.jar:5.6.14]
at org.elasticsearch.action.admin.cluster.node.stats.TransportNodesStatsAction.nodeOperation(TransportNodesStatsAction.java:42) [elasticsearch-5.6.14.jar:5.6.14]
at org.elasticsearch.action.support.nodes.TransportNodesAction.nodeOperation(TransportNodesAction.java:140) [elasticsearch-5.6.14.jar:5.6.14]
at org.elasticsearch.action.support.nodes.TransportNodesAction$NodeTransportHandler.messageReceived(TransportNodesAction.java:262) [elasticsearch-5.6.14.jar:5.6.14]
at org.elasticsearch.action.support.nodes.TransportNodesAction$NodeTransportHandler.messageReceived(TransportNodesAction.java:258) [elasticsearch-5.6.14.jar:5.6.14]
at org.elasticsearch.transport.RequestHandlerRegistry.processMessageReceived(RequestHandlerRegistry.java:69) [elasticsearch-5.6.14.jar:5.6.14]
at org.elasticsearch.transport.TcpTransport$RequestHandler.doRun(TcpTransport.java:1556) [elasticsearch-5.6.14.jar:5.6.14]
at org.elasticsearch.common.util.concurrent.ThreadContext$ContextPreservingAbstractRunnable.doRun(ThreadContext.java:675) [elasticsearch-5.6.14.jar:5.6.14]
at org.elasticsearch.common.util.concurrent.AbstractRunnable.run(AbstractRunnable.java:37) [elasticsearch-5.6.14.jar:5.6.14]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_161]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_161]
at java.lang.Thread.run(Thread.java:748) [?:1.8.0_161]

We do not have cpu or control groups enabled on those servers and do not have plans to do so.

Is there a way to get rid of those error-messages (like disable to need for cpu-groups for ES) and do those errors actually effect the ES-instance? We actually do like to have debug-log enabled for the upgrade-time.

Thank you very much.

Regrads

Horst

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.