indexer crashes after running for about a day

Describe the bug
Every morning I go to log in to the Wazuh dashboard and it states that my credentials are wrong.
Turns out it's because the wazuh-indexer service stopped running on the server.
After starting the service, I'm able to log in once again.
The logs have not helped me find the source of this issue.
To Reproduce
Steps to reproduce the behavior:

Fresh install of Debian 11 on a VM in the Azure cloud
2 vCPUs and 4 GiB memory (apparently it's all the company can afford)
Follow the Wazuh documentation for quickstart installation
Enable ports as needed
Log in to the dashboard and add two agents and observe
Attempt to log in the next day to see issue

Expected behavior
I expected that the wazuh-indexer would continue running indefinitely on its own.
Plugins
I currently have VirusTotal going, but it's not required for this issue to occur.
Screenshots

Host/Environment (please complete the following information):

OS: Debian 11
Version: 11.8

Additional context
This appears to be the only error logging relevant to wazuh-indexer. This shows the log just before the service stopped:

It has failed again today. This time, it shows an failed result that I can understand and potentially do something about. It appears that my little server in the cloud has run out of memory and so the indexer service was killed. So, I may have to convince the managers to let me use a more capable cloud machine at the recommended vCPU and RAM as opposed to what we're currently running.

journaltctl:
Dec 01 00:00:00 Wazuh systemd-entrypoint[187023]: 2023-12-01 00:00:00,607 opensearch[node-1][clusterManagerService#updateTask][T#1] ERROR Could not define attribute view on path "/var/log/wazuh-indexer/wazuh-cluster_server.json" got acc>
Dec 01 00:00:00 Wazuh systemd-entrypoint[187023]:         at java.base/java.security.AccessControlContext.checkPermission(AccessControlContext.java:485)
Dec 01 00:00:00 Wazuh systemd-entrypoint[187023]:         at java.base/java.security.AccessController.checkPermission(AccessController.java:1068)
Dec 01 00:00:00 Wazuh systemd-entrypoint[187023]:         at java.base/java.lang.SecurityManager.checkPermission(SecurityManager.java:416)
Dec 01 00:00:00 Wazuh systemd-entrypoint[187023]:         at java.base/sun.nio.fs.UnixFileAttributeViews$Posix.checkWriteExtended(UnixFileAttributeViews.java:195)
Dec 01 00:00:00 Wazuh systemd-entrypoint[187023]:         at java.base/sun.nio.fs.UnixFileAttributeViews$Posix.setMode(UnixFileAttributeViews.java:264)
Dec 01 00:00:00 Wazuh systemd-entrypoint[187023]:         at java.base/sun.nio.fs.UnixFileAttributeViews$Posix.setPermissions(UnixFileAttributeViews.java:299)
Dec 01 00:00:00 Wazuh systemd-entrypoint[187023]:         at org.apache.logging.log4j.core.util.FileUtils.defineFilePosixAttributeView(FileUtils.java:177)
Dec 01 00:00:00 Wazuh systemd-entrypoint[187023]:         at org.apache.logging.log4j.core.appender.FileManager.defineAttributeView(FileManager.java:215)
Dec 01 00:00:00 Wazuh systemd-entrypoint[187023]:         at org.apache.logging.log4j.core.appender.FileManager.createOutputStream(FileManager.java:202)
Dec 01 00:00:00 Wazuh systemd-entrypoint[187023]:         at org.apache.logging.log4j.core.appender.rolling.RollingFileManager.createFileAfterRollover(RollingFileManager.java:419)
Dec 01 00:00:00 Wazuh systemd-entrypoint[187023]:         at org.apache.logging.log4j.core.appender.rolling.RollingFileManager.rollover(RollingFileManager.java:396)
Dec 01 00:00:00 Wazuh systemd-entrypoint[187023]:         at org.apache.logging.log4j.core.appender.rolling.RollingFileManager.checkRollover(RollingFileManager.java:308)
Dec 01 00:00:00 Wazuh systemd-entrypoint[187023]:         at org.apache.logging.log4j.core.appender.RollingFileAppender.append(RollingFileAppender.java:311)
Dec 01 00:00:00 Wazuh systemd-entrypoint[187023]:         at org.apache.logging.log4j.core.config.AppenderControl.tryCallAppender(AppenderControl.java:161)
Dec 01 00:00:00 Wazuh systemd-entrypoint[187023]:         at org.apache.logging.log4j.core.config.AppenderControl.callAppender0(AppenderControl.java:134)
Dec 01 00:00:00 Wazuh systemd-entrypoint[187023]:         at org.apache.logging.log4j.core.config.AppenderControl.callAppenderPreventRecursion(AppenderControl.java:125)
Dec 01 00:00:00 Wazuh systemd-entrypoint[187023]:         at org.apache.logging.log4j.core.config.AppenderControl.callAppender(AppenderControl.java:89)
Dec 01 00:00:00 Wazuh systemd-entrypoint[187023]:         at org.apache.logging.log4j.core.config.LoggerConfig.callAppenders(LoggerConfig.java:542)
Dec 01 00:00:00 Wazuh systemd-entrypoint[187023]:         at org.apache.logging.log4j.core.config.LoggerConfig.processLogEvent(LoggerConfig.java:500)
Dec 01 00:00:00 Wazuh systemd-entrypoint[187023]:         at org.apache.logging.log4j.core.config.LoggerConfig.log(LoggerConfig.java:483)
Dec 01 00:00:00 Wazuh systemd-entrypoint[187023]:         at org.apache.logging.log4j.core.config.LoggerConfig.log(LoggerConfig.java:417)
Dec 01 00:00:00 Wazuh systemd-entrypoint[187023]:         at org.apache.logging.log4j.core.config.AwaitCompletionReliabilityStrategy.log(AwaitCompletionReliabilityStrategy.java:82)
Dec 01 00:00:00 Wazuh systemd-entrypoint[187023]:         at org.apache.logging.log4j.core.Logger.log(Logger.java:161)
Dec 01 00:00:00 Wazuh systemd-entrypoint[187023]:         at org.apache.logging.log4j.spi.AbstractLogger.tryLogMessage(AbstractLogger.java:2205)
Dec 01 00:00:00 Wazuh systemd-entrypoint[187023]:         at org.apache.logging.log4j.spi.AbstractLogger.logMessageTrackRecursion(AbstractLogger.java:2159)
Dec 01 00:00:00 Wazuh systemd-entrypoint[187023]:         at org.apache.logging.log4j.spi.AbstractLogger.logMessageSafely(AbstractLogger.java:2142)
Dec 01 00:00:00 Wazuh systemd-entrypoint[187023]:         at org.apache.logging.log4j.spi.AbstractLogger.logMessage(AbstractLogger.java:2040)
Dec 01 00:00:00 Wazuh systemd-entrypoint[187023]:         at org.apache.logging.log4j.spi.AbstractLogger.logIfEnabled(AbstractLogger.java:1907)
Dec 01 00:00:00 Wazuh systemd-entrypoint[187023]:         at org.apache.logging.log4j.spi.AbstractLogger.info(AbstractLogger.java:1449)
Dec 01 00:00:00 Wazuh systemd-entrypoint[187023]:         at org.opensearch.cluster.metadata.MetadataUpdateSettingsService$1.execute(MetadataUpdateSettingsService.java:247)
Dec 01 00:00:00 Wazuh systemd-entrypoint[187023]:         at org.opensearch.cluster.ClusterStateUpdateTask.execute(ClusterStateUpdateTask.java:65)
Dec 01 00:00:00 Wazuh systemd-entrypoint[187023]:         at org.opensearch.cluster.service.MasterService.executeTasks(MasterService.java:874)
Dec 01 00:00:00 Wazuh systemd-entrypoint[187023]:         at org.opensearch.cluster.service.MasterService.calculateTaskOutputs(MasterService.java:424)
Dec 01 00:00:00 Wazuh systemd-entrypoint[187023]:         at org.opensearch.cluster.service.MasterService.runTasks(MasterService.java:295)
Dec 01 00:00:00 Wazuh systemd-entrypoint[187023]:         at org.opensearch.cluster.service.MasterService$Batcher.run(MasterService.java:206)
Dec 01 00:00:00 Wazuh systemd-entrypoint[187023]:         at org.opensearch.cluster.service.TaskBatcher.runIfNotProcessed(TaskBatcher.java:204)
Dec 01 00:00:00 Wazuh systemd-entrypoint[187023]:         at org.opensearch.cluster.service.TaskBatcher$BatchedTask.run(TaskBatcher.java:242)
Dec 01 00:00:00 Wazuh systemd-entrypoint[187023]:         at org.opensearch.common.util.concurrent.ThreadContext$ContextPreservingRunnable.run(ThreadContext.java:747)
Dec 01 00:00:00 Wazuh systemd-entrypoint[187023]:         at org.opensearch.common.util.concurrent.PrioritizedOpenSearchThreadPoolExecutor$TieBreakingPrioritizedRunnable.runAndClean(PrioritizedOpenSearchThreadPoolExecutor.java:282)
Dec 01 00:00:00 Wazuh systemd-entrypoint[187023]:         at org.opensearch.common.util.concurrent.PrioritizedOpenSearchThreadPoolExecutor$TieBreakingPrioritizedRunnable.run(PrioritizedOpenSearchThreadPoolExecutor.java:245)
Dec 01 00:00:00 Wazuh systemd-entrypoint[187023]:         at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
Dec 01 00:00:00 Wazuh systemd-entrypoint[187023]:         at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
Dec 01 00:00:00 Wazuh systemd-entrypoint[187023]:         at java.base/java.lang.Thread.run(Thread.java:833)
Dec 01 00:00:00 Wazuh systemd-entrypoint[187023]: 2023-12-01 00:00:00,615 opensearch[node-1][clusterManagerService#updateTask][T#1] ERROR Could not define attribute view on path "/var/log/wazuh-indexer/wazuh-cluster.log" got access deni>
Dec 01 00:00:00 Wazuh systemd-entrypoint[187023]:         at java.base/java.security.AccessControlContext.checkPermission(AccessControlContext.java:485)
Dec 01 00:00:00 Wazuh systemd-entrypoint[187023]:         at java.base/java.security.AccessController.checkPermission(AccessController.java:1068)
Dec 01 00:00:00 Wazuh systemd-entrypoint[187023]:         at java.base/java.lang.SecurityManager.checkPermission(SecurityManager.java:416)
Dec 01 00:00:00 Wazuh systemd-entrypoint[187023]:         at java.base/sun.nio.fs.UnixFileAttributeViews$Posix.checkWriteExtended(UnixFileAttributeViews.java:195)
Dec 01 00:00:00 Wazuh systemd-entrypoint[187023]:         at java.base/sun.nio.fs.UnixFileAttributeViews$Posix.setMode(UnixFileAttributeViews.java:264)
Dec 01 00:00:00 Wazuh systemd-entrypoint[187023]:         at java.base/sun.nio.fs.UnixFileAttributeViews$Posix.setPermissions(UnixFileAttributeViews.java:299)
Dec 01 00:00:00 Wazuh systemd-entrypoint[187023]:         at org.apache.logging.log4j.core.util.FileUtils.defineFilePosixAttributeView(FileUtils.java:177)
Dec 01 00:00:00 Wazuh systemd-entrypoint[187023]:         at org.apache.logging.log4j.core.appender.FileManager.defineAttributeView(FileManager.java:215)
Dec 01 00:00:00 Wazuh systemd-entrypoint[187023]:         at org.apache.logging.log4j.core.appender.FileManager.createOutputStream(FileManager.java:202)
Dec 01 00:00:00 Wazuh systemd-entrypoint[187023]:         at org.apache.logging.log4j.core.appender.rolling.RollingFileManager.createFileAfterRollover(RollingFileManager.java:419)
Dec 01 00:00:00 Wazuh systemd-entrypoint[187023]:         at org.apache.logging.log4j.core.appender.rolling.RollingFileManager.rollover(RollingFileManager.java:396)
Dec 01 00:00:00 Wazuh systemd-entrypoint[187023]:         at org.apache.logging.log4j.core.appender.rolling.RollingFileManager.checkRollover(RollingFileManager.java:308)
Dec 01 00:00:00 Wazuh systemd-entrypoint[187023]:         at org.apache.logging.log4j.core.appender.RollingFileAppender.append(RollingFileAppender.java:311)
Dec 01 00:00:00 Wazuh systemd-entrypoint[187023]:         at org.apache.logging.log4j.core.config.AppenderControl.tryCallAppender(AppenderControl.java:161)
Dec 01 00:00:00 Wazuh systemd-entrypoint[187023]:         at org.apache.logging.log4j.core.config.AppenderControl.callAppender0(AppenderControl.java:134)
Dec 01 00:00:00 Wazuh systemd-entrypoint[187023]:         at org.apache.logging.log4j.core.config.AppenderControl.callAppenderPreventRecursion(AppenderControl.java:125)
Dec 01 00:00:00 Wazuh systemd-entrypoint[187023]:         at org.apache.logging.log4j.core.config.AppenderControl.callAppender(AppenderControl.java:89)
Dec 01 00:00:00 Wazuh systemd-entrypoint[187023]:         at org.apache.logging.log4j.core.config.LoggerConfig.callAppenders(LoggerConfig.java:542)
Dec 01 00:00:00 Wazuh systemd-entrypoint[187023]:         at org.apache.logging.log4j.core.config.LoggerConfig.processLogEvent(LoggerConfig.java:500)
Dec 01 00:00:00 Wazuh systemd-entrypoint[187023]:         at org.apache.logging.log4j.core.config.LoggerConfig.log(LoggerConfig.java:483)
Dec 01 00:00:00 Wazuh systemd-entrypoint[187023]:         at org.apache.logging.log4j.core.config.LoggerConfig.log(LoggerConfig.java:417)
Dec 01 00:00:00 Wazuh systemd-entrypoint[187023]:         at org.apache.logging.log4j.core.config.AwaitCompletionReliabilityStrategy.log(AwaitCompletionReliabilityStrategy.java:82)
Dec 01 00:00:00 Wazuh systemd-entrypoint[187023]:         at org.apache.logging.log4j.core.Logger.log(Logger.java:161)
Dec 01 00:00:00 Wazuh systemd-entrypoint[187023]:         at org.apache.logging.log4j.spi.AbstractLogger.tryLogMessage(AbstractLogger.java:2205)
Dec 01 00:00:00 Wazuh systemd-entrypoint[187023]:         at org.apache.logging.log4j.spi.AbstractLogger.logMessageTrackRecursion(AbstractLogger.java:2159)
Dec 01 00:00:00 Wazuh systemd-entrypoint[187023]:         at org.apache.logging.log4j.spi.AbstractLogger.logMessageSafely(AbstractLogger.java:2142)
Dec 01 00:00:00 Wazuh systemd-entrypoint[187023]:         at org.apache.logging.log4j.spi.AbstractLogger.logMessage(AbstractLogger.java:2040)
Dec 01 00:00:00 Wazuh systemd-entrypoint[187023]:         at org.apache.logging.log4j.spi.AbstractLogger.logIfEnabled(AbstractLogger.java:1907)
Dec 01 00:00:00 Wazuh systemd-entrypoint[187023]:         at org.apache.logging.log4j.spi.AbstractLogger.info(AbstractLogger.java:1449)
Dec 01 00:00:00 Wazuh systemd-entrypoint[187023]:         at org.opensearch.cluster.metadata.MetadataUpdateSettingsService$1.execute(MetadataUpdateSettingsService.java:247)
Dec 01 00:00:00 Wazuh systemd-entrypoint[187023]:         at org.opensearch.cluster.ClusterStateUpdateTask.execute(ClusterStateUpdateTask.java:65)
Dec 01 00:00:00 Wazuh systemd-entrypoint[187023]:         at org.opensearch.cluster.service.MasterService.executeTasks(MasterService.java:874)
Dec 01 00:00:00 Wazuh systemd-entrypoint[187023]:         at org.opensearch.cluster.service.MasterService.calculateTaskOutputs(MasterService.java:424)
Dec 01 00:00:00 Wazuh systemd-entrypoint[187023]:         at org.opensearch.cluster.service.MasterService.runTasks(MasterService.java:295)
Dec 01 00:00:00 Wazuh systemd-entrypoint[187023]:         at org.opensearch.cluster.service.MasterService$Batcher.run(MasterService.java:206)
Dec 01 00:00:00 Wazuh systemd-entrypoint[187023]:         at org.opensearch.cluster.service.TaskBatcher.runIfNotProcessed(TaskBatcher.java:204)
Dec 01 00:00:00 Wazuh systemd-entrypoint[187023]:         at org.opensearch.cluster.service.TaskBatcher$BatchedTask.run(TaskBatcher.java:242)
Dec 01 00:00:00 Wazuh systemd-entrypoint[187023]:         at org.opensearch.common.util.concurrent.ThreadContext$ContextPreservingRunnable.run(ThreadContext.java:747)
Dec 01 00:00:00 Wazuh systemd-entrypoint[187023]:         at org.opensearch.common.util.concurrent.PrioritizedOpenSearchThreadPoolExecutor$TieBreakingPrioritizedRunnable.runAndClean(PrioritizedOpenSearchThreadPoolExecutor.java:282)
Dec 01 00:00:00 Wazuh systemd-entrypoint[187023]:         at org.opensearch.common.util.concurrent.PrioritizedOpenSearchThreadPoolExecutor$TieBreakingPrioritizedRunnable.run(PrioritizedOpenSearchThreadPoolExecutor.java:245)
Dec 01 00:00:00 Wazuh systemd-entrypoint[187023]:         at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
Dec 01 00:00:00 Wazuh systemd-entrypoint[187023]:         at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
Dec 01 00:00:00 Wazuh systemd-entrypoint[187023]:         at java.base/java.lang.Thread.run(Thread.java:833)
Dec 01 04:52:24 Wazuh systemd[1]: wazuh-indexer.service: A process of this unit has been killed by the OOM killer.
░░ Subject: A process of wazuh-indexer.service unit has been killed by the OOM killer.
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░
░░ A process of unit @UNIT has been killed by the Linux kernel out-of-memory (OOM)
░░ killer logic. This usually indicates that the system is low on memory and that
░░ memory needed to be freed. A process associated with wazuh-indexer.service has been determined
░░ as the best process to terminate and has been forcibly terminated by the
░░ kernel.
░░
░░ Note that the memory pressure might or might not have been caused by wazuh-indexer.service.
Dec 01 04:52:24 Wazuh systemd[1]: wazuh-indexer.service: Main process exited, code=killed, status=9/KILL
░░ Subject: Unit process exited
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░
░░ An ExecStart= process belonging to unit wazuh-indexer.service has exited.
░░
░░ The process' exit code is 'killed' and its exit status is 9.
Dec 01 04:52:24 Wazuh systemd[1]: wazuh-indexer.service: Failed with result 'oom-kill'.
░░ Subject: Unit failed
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░
░░ The unit wazuh-indexer.service has entered the 'failed' state with result 'oom-kill'.
Dec 01 04:52:25 Wazuh systemd[1]: wazuh-indexer.service: Consumed 5min 16.644s CPU time.
░░ Subject: Resources consumed by unit runtime
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░
░░ The unit wazuh-indexer.service completed and consumed the indicated resources.
-- Boot 9ac9934147b14224aace8c6778c8c729 --
Dec 01 15:13:26 Wazuh systemd[1]: /etc/systemd/system/wazuh-indexer.service.d/startup-timeout.conf:1: Assignment outside of section. Ignoring.
Dec 01 15:13:26 Wazuh systemd[1]: /etc/systemd/system/wazuh-indexer.service.d/startup-timeout.conf:2: Assignment outside of section. Ignoring.
Dec 01 15:13:26 Wazuh systemd[1]: Starting Wazuh-indexer...
░░ Subject: A start job for unit wazuh-indexer.service has begun execution
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░
░░ A start job for unit wazuh-indexer.service has begun execution.
░░
░░ The job identifier is 111.
Dec 01 15:13:29 Wazuh systemd[1]: /etc/systemd/system/wazuh-indexer.service.d/startup-timeout.conf:1: Assignment outside of section. Ignoring.
Dec 01 15:13:29 Wazuh systemd[1]: /etc/systemd/system/wazuh-indexer.service.d/startup-timeout.conf:2: Assignment outside of section. Ignoring.
Dec 01 15:13:38 Wazuh systemd-entrypoint[722]: WARNING: A terminally deprecated method in java.lang.System has been called
Dec 01 15:13:38 Wazuh systemd-entrypoint[722]: WARNING: System::setSecurityManager has been called by org.opensearch.bootstrap.OpenSearch (file:/usr/share/wazuh-indexer/lib/opensearch-2.8.0.jar)
Dec 01 15:13:38 Wazuh systemd-entrypoint[722]: WARNING: Please consider reporting this to the maintainers of org.opensearch.bootstrap.OpenSearch
Dec 01 15:13:38 Wazuh systemd-entrypoint[722]: WARNING: System::setSecurityManager will be removed in a future release
Dec 01 15:13:41 Wazuh systemd-entrypoint[722]: WARNING: A terminally deprecated method in java.lang.System has been called
Dec 01 15:13:41 Wazuh systemd-entrypoint[722]: WARNING: System::setSecurityManager has been called by org.opensearch.bootstrap.Security (file:/usr/share/wazuh-indexer/lib/opensearch-2.8.0.jar)
Dec 01 15:13:41 Wazuh systemd-entrypoint[722]: WARNING: Please consider reporting this to the maintainers of org.opensearch.bootstrap.Security
Dec 01 15:13:41 Wazuh systemd-entrypoint[722]: WARNING: System::setSecurityManager will be removed in a future release
Dec 01 15:14:05 Wazuh systemd[1]: Started Wazuh-indexer.
░░ Subject: A start job for unit wazuh-indexer.service has finished successfully
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░
░░ A start job for unit wazuh-indexer.service has finished successfully.
░░
░░ The job identifier is 111.
Dec 01 15:14:08 Wazuh systemd[1]: /etc/systemd/system/wazuh-indexer.service.d/startup-timeout.conf:1: Assignment outside of section. Ignoring.
Dec 01 15:14:08 Wazuh systemd[1]: /etc/systemd/system/wazuh-indexer.service.d/startup-timeout.conf:2: Assignment outside of section. Ignoring.

------------------------------------------END---------------------------------------------------------------------------------------------
cat:
cat /var/log/wazuh-indexer/wazuh-cluster.log | grep -i -E "error|warn"
[2023-12-01T01:43:13,285][WARN ][o.o.m.j.JvmGcMonitorService] [node-1] [gc][33628] overhead, spent [652ms] collecting in the last [1s]
[2023-12-01T04:22:33,684][ERROR][o.o.a.a.AlertIndices     ] [node-1] info deleteOldIndices
[2023-12-01T04:22:33,684][ERROR][o.o.a.a.AlertIndices     ] [node-1] info deleteOldIndices
[2023-12-01T04:22:33,710][ERROR][o.o.s.i.DetectorIndexManagementService] [node-1] info deleteOldIndices
[2023-12-01T04:22:33,710][ERROR][o.o.s.i.DetectorIndexManagementService] [node-1] info deleteOldIndices
[2023-12-01T15:13:41,054][INFO ][o.o.n.Node               ] [node-1] JVM arguments [-Xshare:auto, -Dopensearch.networkaddress.cache.ttl=60, -Dopensearch.networkaddress.cache.negative.ttl=10, -XX:+AlwaysPreTouch, -Xss1m, -Djava.awt.headless=true, -Dfile.encoding=UTF-8, -Djna.nosys=true, -XX:-OmitStackTraceInFastThrow, -XX:+ShowCodeDetailsInExceptionMessages, -Dio.netty.noUnsafe=true, -Dio.netty.noKeySetOptimization=true, -Dio.netty.recycler.maxCapacityPerThread=0, -Dio.netty.allocator.numDirectArenas=0, -Dlog4j.shutdownHookEnabled=false, -Dlog4j2.disable.jmx=true, -Djava.locale.providers=SPI,COMPAT, -Xms1966m, -Xmx1966m, -XX:+UseG1GC, -XX:G1ReservePercent=25, -XX:InitiatingHeapOccupancyPercent=30, -Djava.io.tmpdir=/tmp/opensearch-16912302866905785159, -XX:+HeapDumpOnOutOfMemoryError, -XX:HeapDumpPath=/var/lib/wazuh-indexer, -XX:ErrorFile=/var/log/wazuh-indexer/hs_err_pid%p.log, -Xlog:gc*,gc+age=trace,safepoint:file=/var/log/wazuh-indexer/gc.log:utctime,pid,tags:filecount=32,filesize=64m, -Dclk.tck=100, -Djdk.attach.allowAttachSelf=true, -Djava.security.policy=file:///etc/wazuh-indexer/opensearch-performance-analyzer/opensearch_security.policy, --add-opens=jdk.attach/sun.tools.attach=ALL-UNNAMED, -Dclk.tck=100, -Djdk.attach.allowAttachSelf=true, -Djava.security.policy=file:///usr/share/wazuh-indexer/plugins/opendistro-performance-analyzer/pa_config/es_security.policy, -XX:MaxDirectMemorySize=1030750208, -Dopensearch.path.home=/usr/share/wazuh-indexer, -Dopensearch.path.conf=/etc/wazuh-indexer, -Dopensearch.distribution.type=rpm, -Dopensearch.bundled_jdk=true]
[2023-12-01T15:13:47,182][WARN ][o.o.s.OpenSearchSecurityPlugin] [node-1] File /etc/wazuh-indexer/opensearch-security/roles_mapping.yml has insecure file permissions (should be 0600)
[2023-12-01T15:13:47,183][WARN ][o.o.s.OpenSearchSecurityPlugin] [node-1] File /etc/wazuh-indexer/opensearch-security/internal_users.yml has insecure file permissions (should be 0600)
[2023-12-01T15:13:47,183][WARN ][o.o.s.OpenSearchSecurityPlugin] [node-1] File /etc/wazuh-indexer/opensearch-security/roles.yml has insecure file permissions (should be 0600)
[2023-12-01T15:13:59,922][WARN ][o.o.s.c.Salt             ] [node-1] If you plan to use field masking pls configure compliance salt e1ukloTsQlOgPquJ to be a random string of 16 chars length identical on all nodes
[2023-12-01T15:14:00,010][ERROR][o.o.s.a.s.SinkProvider   ] [node-1] Default endpoint could not be created, auditlog will not work properly.
[2023-12-01T15:14:00,019][WARN ][o.o.s.a.r.AuditMessageRouter] [node-1] No default storage available, audit log may not work properly. Please check configuration.
[2023-12-01T15:14:04,015][WARN ][o.o.g.DanglingIndicesState] [node-1] gateway.auto_import_dangling_indices is disabled, dangling indices will not be automatically detected or imported and must be managed manually
[2023-12-01T15:14:05,803][WARN ][o.o.p.c.s.h.ConfigOverridesClusterSettingHandler] [node-1] Config override setting update called with empty string. Ignoring.
[2023-12-01T15:14:06,184][WARN ][o.o.o.i.ObservabilityIndex] [node-1] message: index [.opensearch-observability/pMUAyfbDQuqOKlQ6CBiDzA] already exists
[2023-12-01T15:14:06,893][ERROR][o.o.s.c.ConfigurationLoaderSecurity7] [node-1] Failure No shard available for [org.opensearch.action.get.MultiGetShardRequest@5276d194] retrieving configuration for [INTERNALUSERS, ACTIONGROUPS, CONFIG, ROLES, ROLESMAPPING, TENANTS, NODESDN, WHITELIST, ALLOWLIST, AUDIT] (index=.opendistro_security)
[2023-12-01T15:14:06,893][ERROR][o.o.s.c.ConfigurationLoaderSecurity7] [node-1] Failure No shard available for [org.opensearch.action.get.MultiGetShardRequest@5276d194] retrieving configuration for [INTERNALUSERS, ACTIONGROUPS, CONFIG, ROLES, ROLESMAPPING, TENANTS, NODESDN, WHITELIST, ALLOWLIST, AUDIT] (index=.opendistro_security)
[2023-12-01T15:14:06,894][ERROR][o.o.s.c.ConfigurationLoaderSecurity7] [node-1] Failure No shard available for [org.opensearch.action.get.MultiGetShardRequest@5276d194] retrieving configuration for [INTERNALUSERS, ACTIONGROUPS, CONFIG, ROLES, ROLESMAPPING, TENANTS, NODESDN, WHITELIST, ALLOWLIST, AUDIT] (index=.opendistro_security)
[2023-12-01T15:14:06,902][ERROR][o.o.s.c.ConfigurationLoaderSecurity7] [node-1] Failure No shard available for [org.opensearch.action.get.MultiGetShardRequest@5276d194] retrieving configuration for [INTERNALUSERS, ACTIONGROUPS, CONFIG, ROLES, ROLESMAPPING, TENANTS, NODESDN, WHITELIST, ALLOWLIST, AUDIT] (index=.opendistro_security)
[2023-12-01T15:14:06,903][ERROR][o.o.s.c.ConfigurationLoaderSecurity7] [node-1] Failure No shard available for [org.opensearch.action.get.MultiGetShardRequest@5276d194] retrieving configuration for [INTERNALUSERS, ACTIONGROUPS, CONFIG, ROLES, ROLESMAPPING, TENANTS, NODESDN, WHITELIST, ALLOWLIST, AUDIT] (index=.opendistro_security)
[2023-12-01T15:14:06,903][ERROR][o.o.s.c.ConfigurationLoaderSecurity7] [node-1] Failure No shard available for [org.opensearch.action.get.MultiGetShardRequest@5276d194] retrieving configuration for [INTERNALUSERS, ACTIONGROUPS, CONFIG, ROLES, ROLESMAPPING, TENANTS, NODESDN, WHITELIST, ALLOWLIST, AUDIT] (index=.opendistro_security)
[2023-12-01T15:14:06,904][ERROR][o.o.s.c.ConfigurationLoaderSecurity7] [node-1] Failure No shard available for [org.opensearch.action.get.MultiGetShardRequest@5276d194] retrieving configuration for [INTERNALUSERS, ACTIONGROUPS, CONFIG, ROLES, ROLESMAPPING, TENANTS, NODESDN, WHITELIST, ALLOWLIST, AUDIT] (index=.opendistro_security)
[2023-12-01T15:14:06,905][ERROR][o.o.s.c.ConfigurationLoaderSecurity7] [node-1] Failure No shard available for [org.opensearch.action.get.MultiGetShardRequest@5276d194] retrieving configuration for [INTERNALUSERS, ACTIONGROUPS, CONFIG, ROLES, ROLESMAPPING, TENANTS, NODESDN, WHITELIST, ALLOWLIST, AUDIT] (index=.opendistro_security)
[2023-12-01T15:14:06,905][ERROR][o.o.s.c.ConfigurationLoaderSecurity7] [node-1] Failure No shard available for [org.opensearch.action.get.MultiGetShardRequest@5276d194] retrieving configuration for [INTERNALUSERS, ACTIONGROUPS, CONFIG, ROLES, ROLESMAPPING, TENANTS, NODESDN, WHITELIST, ALLOWLIST, AUDIT] (index=.opendistro_security)
[2023-12-01T15:14:06,905][ERROR][o.o.s.c.ConfigurationLoaderSecurity7] [node-1] Failure No shard available for [org.opensearch.action.get.MultiGetShardRequest@5276d194] retrieving configuration for [INTERNALUSERS, ACTIONGROUPS, CONFIG, ROLES, ROLESMAPPING, TENANTS, NODESDN, WHITELIST, ALLOWLIST, AUDIT] (index=.opendistro_security)
[2023-12-01T15:14:08,525][ERROR][o.o.s.a.BackendRegistry  ] [node-1] Not yet initialized (you may need to run securityadmin)
[2023-12-01T15:14:08,568][ERROR][o.o.s.a.BackendRegistry  ] [node-1] Not yet initialized (you may need to run securityadmin)
[2023-12-01T15:14:08,572][ERROR][o.o.s.a.BackendRegistry  ] [node-1] Not yet initialized (you may need to run securityadmin)
[2023-12-01T15:14:08,576][ERROR][o.o.s.a.BackendRegistry  ] [node-1] Not yet initialized (you may need to run securityadmin)
[2023-12-01T15:14:10,743][ERROR][o.o.s.a.BackendRegistry  ] [node-1] Not yet initialized (you may need to run securityadmin)
[2023-12-01T15:14:10,746][ERROR][o.o.s.a.BackendRegistry  ] [node-1] Not yet initialized (you may need to run securityadmin)
[2023-12-01T15:14:10,748][ERROR][o.o.s.a.BackendRegistry  ] [node-1] Not yet initialized (you may need to run securityadmin)
[2023-12-01T15:14:10,750][ERROR][o.o.s.a.BackendRegistry  ] [node-1] Not yet initialized (you may need to run securityadmin)
[2023-12-01T15:14:13,246][ERROR][o.o.s.a.BackendRegistry  ] [node-1] Not yet initialized (you may need to run securityadmin)
[2023-12-01T15:14:13,249][ERROR][o.o.s.a.BackendRegistry  ] [node-1] Not yet initialized (you may need to run securityadmin)
[2023-12-01T15:14:13,252][ERROR][o.o.s.a.BackendRegistry  ] [node-1] Not yet initialized (you may need to run securityadmin)
[2023-12-01T15:14:13,254][ERROR][o.o.s.a.BackendRegistry  ] [node-1] Not yet initialized (you may need to run securityadmin)
[2023-12-01T15:14:15,746][ERROR][o.o.s.a.BackendRegistry  ] [node-1] Not yet initialized (you may need to run securityadmin)
[2023-12-01T15:14:15,749][ERROR][o.o.s.a.BackendRegistry  ] [node-1] Not yet initialized (you may need to run securityadmin)
[2023-12-01T15:14:15,753][ERROR][o.o.s.a.BackendRegistry  ] [node-1] Not yet initialized (you may need to run securityadmin)
[2023-12-01T15:14:15,755][ERROR][o.o.s.a.BackendRegistry  ] [node-1] Not yet initialized (you may need to run securityadmin)
[2023-12-01T15:14:17,364][ERROR][o.o.s.a.BackendRegistry  ] [node-1] Not yet initialized (you may need to run securityadmin)
[2023-12-01T15:14:18,248][ERROR][o.o.s.a.BackendRegistry  ] [node-1] Not yet initialized (you may need to run securityadmin)
[2023-12-01T15:14:18,251][ERROR][o.o.s.a.BackendRegistry  ] [node-1] Not yet initialized (you may need to run securityadmin)
[2023-12-01T15:14:18,254][ERROR][o.o.s.a.BackendRegistry  ] [node-1] Not yet initialized (you may need to run securityadmin)
[2023-12-01T15:14:18,257][ERROR][o.o.s.a.BackendRegistry  ] [node-1] Not yet initialized (you may need to run securityadmin)
zcat /var/log/wazuh-indexer/wazuh-cluster-2023-11-30-1.log.gz | grep -i -E "error|warn"
[2023-11-30T16:21:53,027][INFO ][o.o.n.Node               ] [node-1] JVM arguments [-Xshare:auto, -Dopensearch.networkaddress.cache.ttl=60, -Dopensearch.networkaddress.cache.negative.ttl=10, -XX:+AlwaysPreTouch, -Xss1m, -Djava.awt.headless=true, -Dfile.encoding=UTF-8, -Djna.nosys=true, -XX:-OmitStackTraceInFastThrow, -XX:+ShowCodeDetailsInExceptionMessages, -Dio.netty.noUnsafe=true, -Dio.netty.noKeySetOptimization=true, -Dio.netty.recycler.maxCapacityPerThread=0, -Dio.netty.allocator.numDirectArenas=0, -Dlog4j.shutdownHookEnabled=false, -Dlog4j2.disable.jmx=true, -Djava.locale.providers=SPI,COMPAT, -Xms1966m, -Xmx1966m, -XX:+UseG1GC, -XX:G1ReservePercent=25, -XX:InitiatingHeapOccupancyPercent=30, -Djava.io.tmpdir=/tmp/opensearch-640933304721735399, -XX:+HeapDumpOnOutOfMemoryError, -XX:HeapDumpPath=/var/lib/wazuh-indexer, -XX:ErrorFile=/var/log/wazuh-indexer/hs_err_pid%p.log, -Xlog:gc*,gc+age=trace,safepoint:file=/var/log/wazuh-indexer/gc.log:utctime,pid,tags:filecount=32,filesize=64m, -Dclk.tck=100, -Djdk.attach.allowAttachSelf=true, -Djava.security.policy=file:///etc/wazuh-indexer/opensearch-performance-analyzer/opensearch_security.policy, --add-opens=jdk.attach/sun.tools.attach=ALL-UNNAMED, -Dclk.tck=100, -Djdk.attach.allowAttachSelf=true, -Djava.security.policy=file:///usr/share/wazuh-indexer/plugins/opendistro-performance-analyzer/pa_config/es_security.policy, -XX:MaxDirectMemorySize=1030750208, -Dopensearch.path.home=/usr/share/wazuh-indexer, -Dopensearch.path.conf=/etc/wazuh-indexer, -Dopensearch.distribution.type=rpm, -Dopensearch.bundled_jdk=true]
[2023-11-30T16:21:54,915][WARN ][o.o.s.OpenSearchSecurityPlugin] [node-1] File /etc/wazuh-indexer/opensearch-security/roles_mapping.yml has insecure file permissions (should be 0600)
[2023-11-30T16:21:54,915][WARN ][o.o.s.OpenSearchSecurityPlugin] [node-1] File /etc/wazuh-indexer/opensearch-security/internal_users.yml has insecure file permissions (should be 0600)
[2023-11-30T16:21:54,916][WARN ][o.o.s.OpenSearchSecurityPlugin] [node-1] File /etc/wazuh-indexer/opensearch-security/roles.yml has insecure file permissions (should be 0600)
[2023-11-30T16:22:00,193][WARN ][o.o.s.c.Salt             ] [node-1] If you plan to use field masking pls configure compliance salt e1ukloTsQlOgPquJ to be a random string of 16 chars length identical on all nodes
[2023-11-30T16:22:00,238][ERROR][o.o.s.a.s.SinkProvider   ] [node-1] Default endpoint could not be created, auditlog will not work properly.
[2023-11-30T16:22:00,239][WARN ][o.o.s.a.r.AuditMessageRouter] [node-1] No default storage available, audit log may not work properly. Please check configuration.
[2023-11-30T16:22:02,324][WARN ][o.o.g.DanglingIndicesState] [node-1] gateway.auto_import_dangling_indices is disabled, dangling indices will not be automatically detected or imported and must be managed manually
[2023-11-30T16:22:03,700][WARN ][o.o.p.c.s.h.ConfigOverridesClusterSettingHandler] [node-1] Config override setting update called with empty string. Ignoring.
[2023-11-30T16:22:03,898][WARN ][o.o.o.i.ObservabilityIndex] [node-1] message: index [.opensearch-observability/pMUAyfbDQuqOKlQ6CBiDzA] already exists
[2023-11-30T16:22:24,623][INFO ][o.o.n.Node               ] [node-1] JVM arguments [-Xshare:auto, -Dopensearch.networkaddress.cache.ttl=60, -Dopensearch.networkaddress.cache.negative.ttl=10, -XX:+AlwaysPreTouch, -Xss1m, -Djava.awt.headless=true, -Dfile.encoding=UTF-8, -Djna.nosys=true, -XX:-OmitStackTraceInFastThrow, -XX:+ShowCodeDetailsInExceptionMessages, -Dio.netty.noUnsafe=true, -Dio.netty.noKeySetOptimization=true, -Dio.netty.recycler.maxCapacityPerThread=0, -Dio.netty.allocator.numDirectArenas=0, -Dlog4j.shutdownHookEnabled=false, -Dlog4j2.disable.jmx=true, -Djava.locale.providers=SPI,COMPAT, -Xms1966m, -Xmx1966m, -XX:+UseG1GC, -XX:G1ReservePercent=25, -XX:InitiatingHeapOccupancyPercent=30, -Djava.io.tmpdir=/tmp/opensearch-1220046215123745062, -XX:+HeapDumpOnOutOfMemoryError, -XX:HeapDumpPath=/var/lib/wazuh-indexer, -XX:ErrorFile=/var/log/wazuh-indexer/hs_err_pid%p.log, -Xlog:gc*,gc+age=trace,safepoint:file=/var/log/wazuh-indexer/gc.log:utctime,pid,tags:filecount=32,filesize=64m, -Dclk.tck=100, -Djdk.attach.allowAttachSelf=true, -Djava.security.policy=file:///etc/wazuh-indexer/opensearch-performance-analyzer/opensearch_security.policy, --add-opens=jdk.attach/sun.tools.attach=ALL-UNNAMED, -Dclk.tck=100, -Djdk.attach.allowAttachSelf=true, -Djava.security.policy=file:///usr/share/wazuh-indexer/plugins/opendistro-performance-analyzer/pa_config/es_security.policy, -XX:MaxDirectMemorySize=1030750208, -Dopensearch.path.home=/usr/share/wazuh-indexer, -Dopensearch.path.conf=/etc/wazuh-indexer, -Dopensearch.distribution.type=rpm, -Dopensearch.bundled_jdk=true]
[2023-11-30T16:22:26,416][WARN ][o.o.s.OpenSearchSecurityPlugin] [node-1] File /etc/wazuh-indexer/opensearch-security/roles_mapping.yml has insecure file permissions (should be 0600)
[2023-11-30T16:22:26,416][WARN ][o.o.s.OpenSearchSecurityPlugin] [node-1] File /etc/wazuh-indexer/opensearch-security/internal_users.yml has insecure file permissions (should be 0600)
[2023-11-30T16:22:26,417][WARN ][o.o.s.OpenSearchSecurityPlugin] [node-1] File /etc/wazuh-indexer/opensearch-security/roles.yml has insecure file permissions (should be 0600)
[2023-11-30T16:22:30,595][WARN ][o.o.s.c.Salt             ] [node-1] If you plan to use field masking pls configure compliance salt e1ukloTsQlOgPquJ to be a random string of 16 chars length identical on all nodes
[2023-11-30T16:22:30,624][ERROR][o.o.s.a.s.SinkProvider   ] [node-1] Default endpoint could not be created, auditlog will not work properly.
[2023-11-30T16:22:30,625][WARN ][o.o.s.a.r.AuditMessageRouter] [node-1] No default storage available, audit log may not work properly. Please check configuration.
[2023-11-30T16:22:32,129][WARN ][o.o.p.c.ThreadPoolMetricsCollector] [node-1] Fail to read queue capacity via reflection
[2023-11-30T16:22:32,140][WARN ][o.o.p.c.ThreadPoolMetricsCollector] [node-1] Fail to read queue capacity via reflection
[2023-11-30T16:22:32,145][WARN ][o.o.p.c.ThreadPoolMetricsCollector] [node-1] Fail to read queue capacity via reflection
[2023-11-30T16:22:32,145][WARN ][o.o.p.c.ThreadPoolMetricsCollector] [node-1] Fail to read queue capacity via reflection
[2023-11-30T16:22:32,145][WARN ][o.o.p.c.ThreadPoolMetricsCollector] [node-1] Fail to read queue capacity via reflection
[2023-11-30T16:22:32,145][WARN ][o.o.p.c.ThreadPoolMetricsCollector] [node-1] Fail to read queue capacity via reflection
[2023-11-30T16:22:32,146][WARN ][o.o.p.c.ThreadPoolMetricsCollector] [node-1] Fail to read queue capacity via reflection
[2023-11-30T16:22:32,146][WARN ][o.o.p.c.ThreadPoolMetricsCollector] [node-1] Fail to read queue capacity via reflection
[2023-11-30T16:22:32,146][WARN ][o.o.p.c.ThreadPoolMetricsCollector] [node-1] Fail to read queue capacity via reflection
[2023-11-30T16:22:32,146][WARN ][o.o.p.c.ThreadPoolMetricsCollector] [node-1] Fail to read queue capacity via reflection
[2023-11-30T16:22:32,146][WARN ][o.o.p.c.ThreadPoolMetricsCollector] [node-1] Fail to read queue capacity via reflection
[2023-11-30T16:22:32,147][WARN ][o.o.p.c.ThreadPoolMetricsCollector] [node-1] Fail to read queue capacity via reflection
[2023-11-30T16:22:32,147][WARN ][o.o.p.c.ThreadPoolMetricsCollector] [node-1] Fail to read queue capacity via reflection
[2023-11-30T16:22:32,147][WARN ][o.o.p.c.ThreadPoolMetricsCollector] [node-1] Fail to read queue capacity via reflection
[2023-11-30T16:22:32,147][WARN ][o.o.p.c.ThreadPoolMetricsCollector] [node-1] Fail to read queue capacity via reflection
[2023-11-30T16:22:32,147][WARN ][o.o.p.c.ThreadPoolMetricsCollector] [node-1] Fail to read queue capacity via reflection
[2023-11-30T16:22:32,149][WARN ][o.o.p.c.ThreadPoolMetricsCollector] [node-1] Fail to read queue capacity via reflection
[2023-11-30T16:22:32,149][WARN ][o.o.p.c.ThreadPoolMetricsCollector] [node-1] Fail to read queue capacity via reflection
[2023-11-30T16:22:32,149][WARN ][o.o.p.c.ThreadPoolMetricsCollector] [node-1] Fail to read queue capacity via reflection
[2023-11-30T16:22:32,149][WARN ][o.o.p.c.ThreadPoolMetricsCollector] [node-1] Fail to read queue capacity via reflection
[2023-11-30T16:22:32,149][WARN ][o.o.p.c.ThreadPoolMetricsCollector] [node-1] Fail to read queue capacity via reflection
[2023-11-30T16:22:32,150][WARN ][o.o.p.c.ThreadPoolMetricsCollector] [node-1] Fail to read queue capacity via reflection
[2023-11-30T16:22:32,150][WARN ][o.o.p.c.ThreadPoolMetricsCollector] [node-1] Fail to read queue capacity via reflection
[2023-11-30T16:22:32,150][WARN ][o.o.p.c.ThreadPoolMetricsCollector] [node-1] Fail to read queue capacity via reflection
[2023-11-30T16:22:32,150][WARN ][o.o.p.c.ThreadPoolMetricsCollector] [node-1] Fail to read queue capacity via reflection
[2023-11-30T16:22:32,150][WARN ][o.o.p.c.ThreadPoolMetricsCollector] [node-1] Fail to read queue capacity via reflection
[2023-11-30T16:22:32,151][WARN ][o.o.p.c.ThreadPoolMetricsCollector] [node-1] Fail to read queue capacity via reflection
[2023-11-30T16:22:32,151][WARN ][o.o.p.c.ThreadPoolMetricsCollector] [node-1] Fail to read queue capacity via reflection
[2023-11-30T16:22:32,151][WARN ][o.o.p.c.ThreadPoolMetricsCollector] [node-1] Fail to read queue capacity via reflection
[2023-11-30T16:22:32,151][WARN ][o.o.p.c.ThreadPoolMetricsCollector] [node-1] Fail to read queue capacity via reflection
[2023-11-30T16:22:32,161][WARN ][o.o.p.c.ThreadPoolMetricsCollector] [node-1] Fail to read queue capacity via reflection
[2023-11-30T16:22:32,161][WARN ][o.o.p.c.ThreadPoolMetricsCollector] [node-1] Fail to read queue capacity via reflection
[2023-11-30T16:22:32,161][WARN ][o.o.p.c.ThreadPoolMetricsCollector] [node-1] Fail to read queue capacity via reflection
[2023-11-30T16:22:32,161][WARN ][o.o.p.c.ThreadPoolMetricsCollector] [node-1] Fail to read queue capacity via reflection
[2023-11-30T16:22:32,161][WARN ][o.o.p.c.ThreadPoolMetricsCollector] [node-1] Fail to read queue capacity via reflection
[2023-11-30T16:22:32,573][WARN ][o.o.g.DanglingIndicesState] [node-1] gateway.auto_import_dangling_indices is disabled, dangling indices will not be automatically detected or imported and must be managed manually
[2023-11-30T16:22:33,708][WARN ][o.o.p.c.s.h.ConfigOverridesClusterSettingHandler] [node-1] Config override setting update called with empty string. Ignoring.
[2023-11-30T16:22:33,913][WARN ][o.o.o.i.ObservabilityIndex] [node-1] message: index [.opensearch-observability/pMUAyfbDQuqOKlQ6CBiDzA] already exists
[2023-11-30T16:22:51,866][WARN ][o.o.s.a.BackendRegistry  ] [node-1] No 'Authorization' header, send 401 and 'WWW-Authenticate Basic'
[2023-11-30T18:05:59,444][WARN ][o.o.m.f.FsHealthService  ] [node-1] health check of [/var/lib/wazuh-indexer/nodes/0] took [7403ms] which is above the warn threshold of [5s]
[2023-11-30T23:37:00,112][WARN ][o.o.m.j.JvmGcMonitorService] [node-1] [gc][young][26057][47] duration [1s], collections [1]/[1.8s], total [1s]/[3.1s], memory [1.2gb]->[156mb]/[1.9gb], all_pools {[young] [1.1gb]->[0b]/[0b]}{[old] [150mb]->[150mb]/[1.9gb]}{[survivor] [6mb]->[6mb]/[0b]}
[2023-11-30T23:37:00,320][WARN ][o.o.m.j.JvmGcMonitorService] [node-1] [gc][26057] overhead, spent [1s] collecting in the last [1.8s]

Hello @coastal-energy
I've been reviewing the logs and there are plenty of errors, many of them apparently unrelated.
The reason why the wazuh-indexer went down is due to OOM (out-of-memory). This usually indicates that the system is low on memory and that memory needed to be freed.
The doesn't necessarily imply that you need more memory, even if in your case that would be really beneficial. I can't be sure if the OOM problem is the cause or the consequence of the other errors in the logs.
Here are some other errors:
ERROR Could not define attribute view on path "/var/log/wazuh-indexer/wazuh-cluster.log" got access denied

[2023-12-01T15:13:47,182][WARN ][o.o.s.OpenSearchSecurityPlugin] [node-1] File /etc/wazuh-indexer/opensearch-security/roles_mapping.yml has insecure file permissions (should be 0600)
[2023-12-01T15:13:47,183][WARN ][o.o.s.OpenSearchSecurityPlugin] [node-1] File /etc/wazuh-indexer/opensearch-security/internal_users.yml has insecure file permissions (should be 0600)
[2023-12-01T15:13:47,183][WARN ][o.o.s.OpenSearchSecurityPlugin] [node-1] File /etc/wazuh-indexer/opensearch-security/roles.yml has insecure file permissions (should be 0600)

Looks like some files have wrong permission, and some can't even be read by the wazuh-indexer process. This could be generating an endless loop and consuming the memory.
Which version of Wazuh are you using and which installation method have you used? If you manage to scale the hardware, it would be a good idea to reinstall

@AlexRuiz7 ,
Thank you for reviewing the logs and informing me of what you found.
I'll be able to fix the permission errors you found today.
There is good news. I was able to convince management to upgrade the RAM on the cloud VM and the wazuh-indexer has continued to run since Friday and it is now Monday when, before, it would crash every single day. I don't want to celebrate early, but it's currently working as expected.
Wazuh installed is version 4.6.0 and I used the Wazuh quickstart guide for installation.
found here: https://documentation.wazuh.com/current/quickstart.html
I greatly appreciate your help so far and we will consider reinstalling if it continues to give us any issues, unless you really think it needs to be reinstalled from what you've seen.

It is still running strong today and there are no errors regarding this issue anymore.
I'll say that this issue is resolved.
Thank you for your help. I appreciate it.


Add linting steps

I'm not convinced it is a good idea to add this 😰

I'm not convinced it is a good idea to add this 😰


[release-1.10] Handle the error of failing to marshal a token request

This is an automated cherry-pick of #32626

@Monkeyanator Can you review this cherrypicking PR?


Fixed design

Closes
Closes #639

Description
Updated Design which was not much good or attractive

Screenshots

Note to reviewers

Checklist:

[x ] I have linked the PR to the correct issue.
[x ] I have read the Contribution Guidelines
[ x] I have built and tested the changes, and they do not break or show any errors.

@akshathar-navada Updated as suggested


Parity with Azure Dev Ops & Travis for CI

Add Azure Devops yaml file in root.
Allows user to deploy bedrock in ADO for their own CI

This is now working via #199 at https://dev.azure.com/epicstuff/bedrock/_build?definitionId=54


audio_state_changed callback not triggering for "suspended"

In both my code, and your example code (https://github.com/pschatzmann/ESP32-A2DP/blob/2ac43830d17d3fdd73daecab5414d6882d06c7cb/examples/bt_music_receiver_status_callback/bt_music_receiver_status_callback.ino), The callback triggers for Started, but does not trigger for Suspended.  I see this log statement firing:  https://github.com/pschatzmann/ESP32-A2DP/blob/183ae4d9208f0bac370afbe57370aefdffe49eb0/src/BluetoothA2DPSink.cpp#L616 for both cases, but the callback does not trigger for the Suspended case.  Looking at the code, it makes no sense to me.  The only thing that looks different in the output is the i2s stuff:
[ 19952][I][BluetoothA2DPSink.cpp:366] app_task_handler(): app_task_handler, APP_SIG_WORK_DISPATCH sig: 1
[ 19956][I][BluetoothA2DPSink.cpp:610] handle_audio_state(): A2DP audio state: Started
ESP32:  Audio State Change.  State: 2
ESP32:  Audio Started
[ 19974][I][BluetoothA2DPSink.cpp:621] handle_audio_state(): i2s_start
[ 29125][I][BluetoothA2DPSink.cpp:366] app_task_handler(): app_task_handler, APP_SIG_WORK_DISPATCH sig: 1
[ 29125][I][BluetoothA2DPSink.cpp:610] handle_audio_state(): A2DP audio state: Suspended
[ 29131][W][BluetoothA2DPSink.cpp:626] handle_audio_state(): i2s_stop
[ 32264][I][BluetoothA2DPSink.cpp:477] app_gap_callback(): event: 13
[ 40254][I][BluetoothA2DPSink.cpp:477] app_gap_callback(): event: 13
[ 40254][I][BluetoothA2DPSink.cpp:366] app_task_handler(): app_task_handler, APP_SIG_WORK_DISPATCH sig: 1
[ 40258][I][BluetoothA2DPSink.cpp:610] handle_audio_state(): A2DP audio state: Started
ESP32:  Audio State Change.  State: 2
ESP32:  Audio Started
[ 40276][I][BluetoothA2DPSink.cpp:621] handle_audio_state(): i2s_start
[ 51781][I][BluetoothA2DPSink.cpp:366] app_task_handler(): app_task_handler, APP_SIG_WORK_DISPATCH sig: 1
[ 51782][I][BluetoothA2DPSink.cpp:610] handle_audio_state(): A2DP audio state: Suspended

The line numbers are not matching with the latest code.
I suggest that you update the a2dp library to the latest version...

Yeah, I was a few commits behind.  That fixed it.  Thanks.


Set font information for uploaded file is allowed for admin group only

Try to set font style for an uploaded font file as staff user (with manage permission) -> 403!
Try to set it as admin -> 200

The staff user should get the permission core.can_manage_logos_and fonts and the client should check this permission in mediafiles interface.

Right! With this addtional permission it works as expected.
I think we should move the permission "can_manage_logos_and_fonts" from core to mediafiles. What do you think?

Hm. The technical issue here is that the client offers changes of config variables in the mediafile app. So for this permission it is the same. The permission is checked in core app in ConfigViewSet. So it belongs to core. But from its meaning it belongs to mediafile ... I do not know, what to do.

@emanuelschuetze Is this still relevant?

The technical issue here is that the client offers changes of config variables in the mediafile app. So
for this permission it is the same. The permission is checked in core app in ConfigViewSet. So it
belongs to core.

Ok, I understand... Then let us do this quick solution: Show the logo controls (checkboxes in menu) only for users with "can_manage_logos_and_fonts" permission. Currently the controls are listen to "mediafiles.can_manage".
@tsiegleauq Can you change the permission check please?

already done in 3.0


[Bug] if "series-pie.label.overflow=break" it breaks "by character" instead of "by word"

Version
5.3.0+
Link to Minimal Reproduction
No response
Steps to Reproduce
series: [
            {
                type: 'pie',
                id: 'pie',
                radius: '40%',
                center: ['50%', '50%'],

                emphasis: {
                    focus: 'self'
                },
                label: {
                    formatter: '{b}\n{@current}%',
                    overflow: 'break'
                }
            }
        ]

Current Behavior
overflow: 'break' for pie series label breaks by character instead of by word
Expected Behavior
overflow: 'break' for pie series label should break by word.
Environment
- OS: Windows 10
- Browser: Chrome
- Framework: Javascript

Any additional comments?
No response

Please provide the data to reproduce the problem.


[Refactor #1] -  Better way to validate, imports and avoid duplicated code.

There was a little code refactor dedicated to avoid :

null or not null validation, use objets class
bad imports with overload of resources
there was code which were not being used so --> remove
duplication of code is very common
}

@tomsun28 updated!

LGTM thanks!


bgCol broken: covers up data

gs <- gsplot() %>%
   points(1:100, rnorm(100,mean=10000, sd=1000), log="y") %>%
   bgCol('lightgrey')
gs

gs2 <- gsplot() %>%
   bgCol('lightgrey') %>%
   points(1:100, rnorm(100,mean=10000, sd=1000), log="y")
gs2

both look like this:

can you provide the base code that makes this look the way you think it should behave?

Changing to something that is not generating random numbers, so I've included the gsplot code again
#gsplot
gs <- gsplot() %>%
    bgCol('lightgrey') %>%
    points(1:4,1:4)
gs

# base
plot(1:4, 1:4)
x1 <- par("usr")[1]
x2 <- par("usr")[2]
y1 <- par("usr")[3]
y2 <- par("usr")[4]
rect(x1,y1,x2,y2,col = 'lightgrey', border = NA)
points(1:4,1:4)

Should look like this:

We use to re-order the gsplot object so that the bgCol would happen first, but that logic was removed. It certainly needs to get put back in place.
We could put a default transparent rect in the object when the gsplot is initialized (like I was proposing with the plot.default default arguments). That is one way I guess to guarantee it's the first thing plotted without re-ordering the gsplot list at the end (I don't remember why that was so toxic, but it seemed to be).

part of the question here is how the calls/args in global are rendered. Right now, par is the only thing that goes into global, but our intent was bgCol, title, and I think legend(?). it would be good if we had a consistent way to handle these for rendering including order.


Bug: signing message on iOS Safari is not working if there is a delay

Describe the bug
I recently used latest wagmi version and noticed that if there is a delay before you sign a message with passkey you'll get "Pop up window failed to open" error message
Steps

Install latest Wagmi version 2.12.25 and add coinbaseWallet connector
Add a sign message button (the message can be anything)
Add a click function to the sign message button that has a 5 second timer before signing the message. You can simply create a sleep function that will act as a timer.
You'll see the "Pop up window failed to open" error in the console

Expected behavior
It shouldn't throw an error. I believe there is some browser policy in iOS Safari that prevents the window popup from being opened up if there is a delay, but not quite sure. I caught this bug when trying to implement Sign-in with ethereum which required a few asynchronous steps before signing a message.
Version
4.1.0
Additional info
No response
Desktop
No response
Smartphone

iPhone 14 - iOS 17.6.1

@magiziz Thanks for flagging. We will take a look into the issue and report back.

@magiziz Do you have any async events happening between the CTA and the call that opens the pop?

@magiziz Do you have any async events happening between the CTA and the call that opens the pop? From what I understand this is an issue with iOS and how they process window.open events.

Yes we have asynchronous events happening before opening the popup.
In our case we're fetching nonce when using Sign-in with ethereum. Is there a possible fix for this that can be done in the SDK level ? I believe this affects all users 🤔

My understanding of the issue is this happens at the system level (ios, etc..). We could potentially popup a toast from the SDK asking users to click again if a popup blocker is detected but thats not an ideal UX either. We do have this documented here https://www.smartwallet.dev/guides/tips/popup-tips#default-blocking-behavior.
Is it possible to prefetch the nonce, prior to users clicking "connect"?

@cb-jake Yeah i think it's possible to do some type of prefetching if there is no solution around it. I'll close this issue for now, thanks for the help 🙏

Thanks @magiziz We're exploring some other solutions that would resolve this, but they're still in ideation phase and we dont have a timeline on them quite yet. I'll re-visit here when we have an update.

Okay thank u


Do not show all IDPs in WAYF when using experimental caching

This commit upgrades engineblock-metadata to 3.1.2, which provides a
fix for a bug where all IDPs where shown on the WAYF, unfiltered, when
the experimental caching metadata backend was used.
See:

https://github.com/OpenConext/OpenConext-engineblock-metadata/pull/24
https://www.pivotaltracker.com/n/projects/1425900/stories/156995448
OpenConext/OpenConext-engineblock#524

Ignoring unpatched random-compat , as described earlier, the problem has been there for several years, and only happens when not using openssl. We use the pached version of random-compat starting from EB5.7.


about MLP

MLP 具体是什么样的结构呢，有图吗
What is the structure of MLP,have .jep?

We use the same MLP block as ViT and Swin. You can refer to Figure 4 of ConvNeXt.

We use the same MLP block as ViT and Swin. You can refer to Figure 4 of ConvNeXt.

是这个么？

左下角的那个结构，Swin Transformer里面的MLP, 如96 dim的输入，是96->384->96两个Linear构成的MLP.


Lift Roddy version to 3.0.0

Adapt buildinfo.txt of all plugins.

Done?

See https://github.com/eilslabs/Roddy/pull/211


Develop Initial Proof-of-Concept

💡 Description

Per discussions with team, looking at producing a POC for a few different architectures.
Some options:

Data provider stages data in their own S3 bucket, publish CNM to DAAC SNS topic
Data provider stages data in DAAC S3 bucket, publishes CNM to DAAC SNS topic
Data provider stages data in DAAC S3 bucket, DAAC ingest themselves using some crawler tool one time (for one-off collections)
Data provider stages data in DAAC S3 bucket, DAAC continuously ingest data as it comes in (new mechanism that is not yet completed)

Per discussion with the team, going to pursue an approach similar to what @collinss-jpl has proposed:

The approach I had been thinking about utilizes AWS API gateway connected to a Lambda (similar to TEA) to allow a client application on the SBN host to request an upload/sync of a local file or files. The Lambda uses information from the request to determine where in our S3 bucket hierarchy the requested files should get uploaded to (based on product type, PDS submitter node, or whatever other criteria we derive). The S3 URI(s) are then returned back through the API gateway to the client. The SBN client application then uses the returned URI(s) to perform the sync using the CLI or boto library. Eventually we could work in a job queue on the SBN client app so the uploads can be performed asynchronously from the upload requests. We would also be able to use the built-in throttling capability on API Gateway to control how much data or how many requests we’ll allow within a window of time etc…

@collinss-jpl will start to prototype next week

@collinss-jpl started doing some research a setting up an API and lambda functions to hopefully demonstrate something by end of week

@collinss-jpl started the development of the lambda/API gateway prototype and tested from internal AWS access.

@collinss-jpl will commit the code in the delivery manager repository and create tickets for next steps.

The existing prototype code has been merged into the data-delivery-manager repo with this commit.
Tickets outlining next development steps have been created:
#5 #6 #7 #8


connection: key_filename can be a list

This commit fixes 5ac7c2f and provides support for multiple identityfile,
besides paramiko.SSHClient.connect accepts list as well for key_filename,
pydoc excerpts:
key_filename:
the filename, or list of filenames, of optional private key(s) to
try for authentication
Fixes: https://tracker.ceph.com/issues/42543
Signed-off-by: Kyr Shatskyy<EMAIL_ADDRESS>

@susebot run deploy


Updated for public access to TaggedWord

you may have no use for this, but I thought I'd offer, I had need to access members in the TaggedWord struct, specifically "word" and "tag" so I upper cased them so they would be public, I also gave them some json hinting as my use case required it and was a straight forward change.

I would like to preserve these as private for my repository. Thanks for offering though, down the line I might consider it.

Can I ask why we want these to be private @EKnapik?  I also would like to access tag.  I'm working on creating a chunker.

This is purely a personal choice. As being part of the tagging process the words should not be possibly changed by outside sources. This can be resolved with a getter style function


Numpy error causes surface module to fail

Description

I have a singularity image of fsqc that I built today which uses the current state of this repository.  For all participants, surface plotting fails due to a numpy 2.0 change from np.mat to np.asmatrix.
Steps to Reproduce

singularity exec /groups/adamraikes/singularity_images/fsqc-2.1.0.sif /app/fsqc/run_fsqc --subjects_dir $PWD/fastsurfer --output_dir $PWD/fsqc --shape --screenshots-html --surfaces-html --skullstrip-html --fornix-html --hypothalamus-html --outlier --fastsurfer

-----------------------------
Creating surface plots ...

[ERROR: fsqcMain.py: 2219]: ERROR: surfaces module failed for subject sub-005_ses-02
[ERROR: fsqcMain.py: 2222]: Reason: `np.mat` was removed in the NumPy 2.0 release. Use `np.asmatrix` instead.
-----------------------------

Execution

Singularity definition file:
BootStrap: docker
From: ubuntu:22.04

%post
   # Update OS
   apt-get update && apt-get install -y --no-install-recommends \
       gcc \
       git \
       time \
       zlib1g-dev \
       libjpeg-dev \
       python3 \
       python3-dev \
       python3-pip \
       python3-setuptools \
       python3-wheel

   # Clone fsqc repository
   git clone https://github.com/Deep-MI/fsqc.git /app/fsqc

   # Install Python packages from requirements file
   pip3 install -r /app/fsqc/requirements.txt

   # Set environment variables
   export OMP_NUM_THREADS=1
   export MPLCONFIGDIR=/tmp/mplconfigdir

%environment
   # Define environment variables for runtime
   export OMP_NUM_THREADS=1
   export MPLCONFIGDIR=/tmp/mplconfigdir

%runscript
   # This is the default action when running the container
   python3 /app/fsqc/run_fsqc

Run Command:

Hello, thanks for your report. We will likely issue a fix shortly.

This issue has now been fixed in the dev branch; we will create a new release (2.1.1) and new docker images during the next days.

Closing this issue, was addressed in release v2.1.1.


Design an initial logo for GTO

(Originally posted in Studio as https://github.com/iterative/studio/issues/3621)
For MLEM models we have been using framework icons to communicate that

the framework that was used to create the ML Model
this model version is saved with MLEM

After some discussion, it might be good to have a visual indication of a GTO model in Studio to indicate

this version is registered with GTO
this version is not saved with MLEM

In Studio we can go ahead and use a very basic G sign for now, but this might be relevant for GTO from a branding perspective too.

I don't think it's relevant now.


Third party api used to generate user avatars responds with 403. Probably shouldn't be used or handled gracefully.

Following this issue: https://github.com/jMonkeyEngine/SoftwareStore/issues/6
The code in question is:
https://github.com/jMonkeyEngine/SoftwareStore/blob/master/src/main/java/com/jayfella/website/core/ImageDownloader.java#L15-L38
The api sometimes returns 403. I applied a workaround that returns an empty image in this case.
A better approach should be used instead and the issue that causes the 403 error (rate limits?) be discovered.
Alternatively this thing could be removed, since it is useless.

At a guess, since this is a new issue since you moved servers and added several layers to the traffic route, it’s probably as a result of that.
I’d also argue the “since it’s useless” case that it’s actually very useful. All modern software creates a default avatar. The knock-on effects of removing this would return all non-avatars as 404 responses unless you took the time to alleviate that issue too.
I would personally inspect why the server is returning a 403. I would speculate it’s as a result of one or more of your traffic layers putting you in a shared environment.

The layers you are talking about do not exist.
I speculate this was a temporary limitation on our ip range, or maybe an issue in their endpoints.
But anyway the point here is that a failed avatar resolution shouldn't cause the registration to fail, and a static avatar can be used for users that do not have one.

Those layers do exist. Docker, CloudFlare, and any other buzzword that's been implemented that routes the traffic through it.
Regardless, A static avatar "works", but the point of a unique avatar generator is so that even if the user does not upload an avatar, they are still uniquely identifiable by their pre-generated avatar. You may deem it un-necessary, but I find it hard to argue with every single modern piece of software that does the same. You may not realize it but you rely on this feature every time you browse through the jmonkey hub, identifying people by their avatar.

You may not realize it but you rely on this feature every time you browse through the jmonkey hub, identifying people by their avatar.

I know that very well, i still deem that unnecessary, and this "problem" is already solved by gravatar, that is the other avatar resolution service used in the code.

Those layers do exist. Docker, CloudFlare, and any other buzzword that's been implemented that routes the traffic through it.

Plase don't get sidetracked by FUD.

Cloudflare: is used to proxy only incoming http(s) requests and replies to those requests, outgoing traffic generated by the app doesn't go through cloudflare.
Docker bridge network: can't be the cause of the issue due to its nature.
Other buzzword that's been implemented: doesn't exist

When it was hosted and maintained under my provision it didn’t have this issue. Under your stack it does. It isn’t FUD. It’s reasonable cause.
Gravatar doesn’t create unique avatars. It pulls the avatar for the assigned email, or on failure, a gravatar logo. Again, the uniquety of the avatars is what is deemed important. I have no interest in pointless debates. I just ask that you don’t rip important areas of code through lack of understanding. I get that “you” don’t understand it’s significance, but “you” are not the audience. It’s there for a reason. If you lack the understanding, leave it alone.

leave it alone.

so you say "i didnt provided everything, so it dont work, but leave it alone and let site dont work correctly"
interesting. IMO Store should be rebuilded to not use 999 third parties (5 minutes to create, 1 year to fix WAY)
if you have something important to say, it should be help, not "leave BUG alone"

When it was hosted and maintained under my provision it didn’t have this issue. Under your stack it does. It isn’t FUD. It’s reasonable cause.

You are playing guessing game with random unrelated things.
This issue is about the failed avatar resolution causing the registration to fail.
The thirdparty service can be unreachable for multiple reasons, such as outages on the services, since it is used for a trivial matter (avatar resolution) this shouldn't cause the application to fail.
What was the cause of the 403 error (that seems to have been temporary) is unknown but most likely unrelated to what you have proposed, and i repeat, a failure in a third party service shouldn't prevent the application from working as expected.
The workaround i deployed fixes this problem but ,due to a time constraint, not in a graceful way.
This issue is here to remember us that the problem is not solved.

Gravatar doesn’t create unique avatars.

Gravatar does generated unique avatars based on the hashed email when the identicon option is enabled.

I just ask that you don’t rip important areas of code through lack of understanding. I get that “you” don’t understand it’s significance, but “you” are not the audience. It’s there for a reason. If you lack the understanding, leave it alone.

The issue is here to be discussed, I don't care how it will be resolved ultimately.
However my personal opinion is that what you are asking makes objectively no sense.

I’m quite sure I am helping. Rule #1 when finding a bug that wasn’t previously there: what changed. I pointed out what changed.
I am also helping in retaining features, not ripping them out because “you don’t think it’s important” despite every single online software product doing the same.
Requiring the user to sign up to gravatar is pushing the problem away. Just solve the 403 that didn’t exist. That’s the issue.

I am annoyed by this. You didn't understand or read anything of what i said.

I did and I disagree. But do what you will. I’ve spent too much time on something so simple already.
❤ to JME.


EHealth-825: show 422 for invalid employee_id on employee_request creation

Coverage increased (+0.03%) to 81.659% when pulling fc57a177ea73d17fa73bd0673b5cd249c18a955a on EHealth-825 into a8b315618970d4ac5c7a6c33c8a0be0fb314aab6 on master.

Coverage increased (+0.03%) to 81.659% when pulling fc57a177ea73d17fa73bd0673b5cd249c18a955a on EHealth-825 into a8b315618970d4ac5c7a6c33c8a0be0fb314aab6 on master.

Coverage increased (+0.03%) to 81.659% when pulling 39a88aa52734e72567e1a5d1d358e5a94daff4cc on EHealth-825 into a8b315618970d4ac5c7a6c33c8a0be0fb314aab6 on master.

Coverage increased (+0.03%) to 81.659% when pulling 39a88aa52734e72567e1a5d1d358e5a94daff4cc on EHealth-825 into a8b315618970d4ac5c7a6c33c8a0be0fb314aab6 on master.


Add 0.8.0 version

Proposal about issue #3

This version is quite old, I would recommend closing this PR.


XRDP process with high CPU

Hello.
I have Debian 11 in a virtual machine with xfce and xrdp installed, I access this machine via RDP in Windows 11. It happens that I always disconnect from the server leaving the session logged in, since I run an application there that needs to be running 24/7, but in some moment when logon to the server and disconnection happens of the process to run CPU, as it can be seen in the print.
I've tried searching the internet in every way and I've already checked the XRDP issues section here on git, but I haven't gotten any answers to solve my problem. Could anyone help me with this?
Thank you

I don't think this is something which has been reported before.
The xrdp process listening on port 3389 forks to run a process in charge of the session. It's not clear from your output above whether it's the listening process or the session process which is consuming the CPU.
It's also not clear whether this is expected behaviour - this may depend on the application you need to keep running.
Can you tell us:-

xrdp version (output of xrdp -v on the command line)

Also, when this happens:-

How the xrdp processes on the system are related? This command may be useful here:-ps -e -o pid,ppid,pcpu,command | grep xrdp`

Whether there's anything useful in /var/log/xrdp.log
Whether there are any other applications using more than 10% CPU (say)
What happens to the CPU levels when the application is (firstly) minimised and (secondly) stopped.

That should do for starters.

In addition:
I'm running two instances of MetaTrader 4.

You've got a lot of xrdp instances running there, but only one instance of Xorg.
How many users are accessing the system? Are any of them using Xvnc?

How many users are accessing the system?
Only one user.
Are any of them using Xvnc?
No, I'm logging in only via RDP using the RDP of the
Windows 11,

My only actions on this machine are basically, login, check the application, disconnect without logout and at another time the same thing, the session is always open.

After rebooting the server, login on this server and open the application, this is the outputs.
"ps -e -o pid,ppid,pcpu,command | grep xrdp" output:
    336       1  0.0 /usr/sbin/xrdp-sesman
    391       1  0.0 /usr/sbin/xrdp
    723     391  1.8 /usr/sbin/xrdp
    730     336  0.0 /usr/sbin/xrdp-sesman
    750     730  2.1 /usr/lib/xorg/Xorg :10 -auth .Xauthority -config xrdp/xorg.conf -noreset -nolisten tcp -logfile .xorgxrdp.%s.log
    757     730  0.0 /usr/sbin/xrdp-chansrv
   1361     391  0.0 /usr/sbin/xrdp
   1363     718  0.0 grep xrdp

Last output for /var/log/xrdp.log:
[20230522-14:41:04] [INFO ] Socket 12: AF_INET6 connection received from (HIDDEN IP) port 52040
[20230522-14:41:04] [DEBUG] Closed socket 12 (AF_INET6 (HIDDEN IP) port 3389)
[20230522-14:41:04] [DEBUG] Closed socket 11 (AF_INET6 :: port 3389)
[20230522-14:41:04] [INFO ] Using default X.509 certificate: /etc/xrdp/cert.pem
[20230522-14:41:04] [INFO ] Using default X.509 key file: /etc/xrdp/key.pem
[20230522-14:41:04] [DEBUG] TLSv1.3 enabled
[20230522-14:41:04] [DEBUG] TLSv1.2 enabled
[20230522-14:41:04] [DEBUG] Security layer: requested 0, selected 0
[20230522-14:41:05] [INFO ] connected client computer name: (HIDDEN NAME)
[20230522-14:41:17] [INFO ] Non-TLS connection established from (HIDDEN IP) port 52040: encrypted with standard RDP security
[20230522-14:41:19] [DEBUG] Closed socket 12 (AF_INET6 (HIDDEN IP) port 3389)
[20230522-14:41:20] [INFO ] Socket 12: AF_INET6 connection received from (HIDDEN IP) port 34369
[20230522-14:41:20] [DEBUG] Closed socket 12 (AF_INET6 (HIDDEN IP) port 3389)
[20230522-14:41:20] [DEBUG] Closed socket 11 (AF_INET6 :: port 3389)
[20230522-14:41:20] [INFO ] Using default X.509 certificate: /etc/xrdp/cert.pem
[20230522-14:41:20] [INFO ] Using default X.509 key file: /etc/xrdp/key.pem
[20230522-14:41:20] [DEBUG] TLSv1.3 enabled
[20230522-14:41:20] [DEBUG] TLSv1.2 enabled
[20230522-14:41:21] [DEBUG] Security layer: requested 0, selected 0
[20230522-14:41:21] [INFO ] connected client computer name: (HIDDEN NAME)
[20230522-14:41:26] [INFO ] Non-TLS connection established from (HIDDEN IP) port 34369: encrypted with standard RDP security

In addition, this is the output for htop:

I think we need to find why you have so many instances of xrdp running. That's unusual enough to raise some flags.
On your latest post you have the following instances of xrdp:-

PID 391. This is the listening copy
PID 723. This is the first connection to your session
PID 1361 This is another connection to your session.

I don't think the 723 PID should be there. Can you try the following?
sudo apt install gdb
sudo gdb -p 723
(gdb) where

and post the output of the where command in gdb.

The only palliative solution I have so far is to restart the server, but this is far from being a solution because it is bad for the application running on this server.

The output of the where command:
#0  0x00007fa57679bdd6 in __GI___select (nfds=21, readfds=0x7fff001d0450, writefds=0x7fff001d04d0, exceptfds=0x0, timeout=0x0)
at ../sysdeps/unix/sysv/linux/select.c:41
#1  0x00007fa5768cc977 in g_obj_wait () from /usr/lib/x86_64-linux-gnu/xrdp/libcommon.so.0
#2  0x000056243b128e4e in ?? ()
#3  0x000056243b11f1f3 in ?? ()
#4  0x000056243b116eeb in ?? ()
#5  0x00007fa5766cdd0a in __libc_start_main (main=0x56243b116c50, argc=1, argv=0x7fff001d0dc8, init=,
fini=, rtld_fini=, stack_end=0x7fff001d0db8) at ../csu/libc-start.c:308
#6  0x000056243b11734a in ?? ()

Thanks.
That's pretty much as expected for a normal xrdp process. Either I've got my processes the wrong way round, or something else is going on here.
A couple of things:-

Can you look at process 1361 also?
The xrdp processes should have a lifetime of the connection, not the session. We should be able to come up with a palliative which ends your current connection, but not your session. Try this:-

#!/bin/bash

mainpid=$(</run/xrdp.pid)

if [[ -z $mainpid ]]; then
    echo "Can't read xrdp server pid" >&2
    exit 1
fi

for pid in $(pgrep -f '/xrdp$'); do
    if [[ $pid != $mainpid ]]; then
        echo "- Killing $pid..."
        kill $pid
    fi
done

Can you look at process 1361 also?
Unfortunately not, this process changes the PID each time I run the command.

The xrdp processes should have a lifetime of the connection, not the session. We should be able to come up with a palliative which ends your current connection, but not your session. Try this:-
Sorry, but where should i create this bash?

You'll need to run the above as `sudo. The current connection will be killed but the session should remain active. It may help for now.

Should I run it manually when the problem occurs?

I don't understand what you mean by this:-

Unfortunately not, this process changes the PID each time I run the command.

That would be true for the grep command (1363 above), but not for the PID next to /usr/sbin/xrdp
That stuff I gave you above is a script. You need to put it in a file of your choice, make it executable and run it.

I believe this could be a problem related to Debian 11, I spoke a little while ago with a colleague of mine who has the same software installed, he also uses RDP but running Debian 10 and not 11, he said he had some problems with 11 and after installing the 10 had no more.

Thanks anyway for the palliative, I'll keep that script up my sleeve.

@matt335672 Moving on to thank you again for the script, for now it saved my skin and worked perfectly.
Thank you very much.

I am seeing a very similar issue, with multiple xrdp processes taking up 100% cpu indefinitely.
This happens on two different unconnected, public-facing servers in two different data centers. My investigation suggests that this is some kind of DOS attack/port scan that causes the xrdp processes to hang. This is because there is one single specific IP that connects to both servers repeatedly every few seconds, and it seems that every few hours or so, a new xrdp process will hang at 100%. As soon as I blocked that IP, no more xrdp hangs on either server. However, existing xrdp processes running at 100% cpu continues to hang.
More information:
DISTRIB_DESCRIPTION="Ubuntu 22.04.2 LTS"
xrdp 0.9.17
ls -l /proc/238881/exe
lrwxrwxrwx 1 xrdp xrdp 0 May 25 01:04 /proc/238881/exe -> /usr/sbin/xrdp

:/proc/238881/fd# ll
total 0
dr-x------ 2 xrdp xrdp  0 May 25 01:58 ./
dr-xr-xr-x 9 xrdp xrdp  0 May 25 01:04 ../
lrwx------ 1 xrdp xrdp 64 May 25 01:58 0 -> /dev/null
lrwx------ 1 xrdp xrdp 64 May 25 01:58 1 -> /dev/null
l-wx------ 1 xrdp xrdp 64 May 25 01:58 10 -> 'pipe:[4049947]'
lr-x------ 1 xrdp xrdp 64 May 25 01:58 11 -> 'pipe:[4049949]'
lrwx------ 1 xrdp xrdp 64 May 25 01:58 12 -> 'socket:[4030038]'
l-wx------ 1 xrdp xrdp 64 May 25 01:58 13 -> 'pipe:[4049949]'
lrwx------ 1 xrdp xrdp 64 May 25 01:58 2 -> /dev/null
l-wx------ 1 xrdp xrdp 64 May 25 01:58 3 -> /var/log/xrdp.log
lr-x------ 1 xrdp xrdp 64 May 25 01:58 4 -> 'pipe:[4049948]'
l-wx------ 1 xrdp xrdp 64 May 25 01:58 5 -> 'pipe:[4049948]'
lrwx------ 1 xrdp xrdp 64 May 25 01:58 6 -> 'socket:[2838122]'
lr-x------ 1 xrdp xrdp 64 May 25 01:58 7 -> 'pipe:[4049946]'
l-wx------ 1 xrdp xrdp 64 May 25 01:58 8 -> 'pipe:[4049946]'
lr-x------ 1 xrdp xrdp 64 May 25 01:58 9 -> 'pipe:[4049947]'

/proc/238881/fd# strace -fvttTyy -s 256 -p 238881
...
18:50:24.145756 pselect6(13, [12<TCPv6:[4030038]>], NULL, NULL, {tv_sec=0, tv_nsec=0}, NULL) = 1 (in [12], left {tv_sec=0, tv_nsec=0}) <0.000010>
18:50:24.146398 pselect6(13, [7<pipe:[4049946]> 11<pipe:[4049949]> 12<TCPv6:[4030038]>], [], NULL, NULL, NULL) = 1 (in [12]) <0.000010>
18:50:24.147014 pselect6(8, [7<pipe:[4049946]>], NULL, NULL, {tv_sec=0, tv_nsec=0}, NULL) = 0 (Timeout) <0.000008>
18:50:24.147040 pselect6(12, [11<pipe:[4049949]>], NULL, NULL, {tv_sec=0, tv_nsec=0}, NULL) = 0 (Timeout) <0.000005>
18:50:24.147056 pselect6(13, [12<TCPv6:[4030038]>], NULL, NULL, {tv_sec=0, tv_nsec=0}, NULL) = 1 (in [12], left {tv_sec=0, tv_nsec=0}) <0.000006>
18:50:24.147655 pselect6(13, [7<pipe:[4049946]> 11<pipe:[4049949]> 12<TCPv6:[4030038]>], [], NULL, NULL, NULL) = 1 (in [12]) <0.000007>
18:50:24.148261 pselect6(8, [7<pipe:[4049946]>], NULL, NULL, {tv_sec=0, tv_nsec=0}, NULL) = 0 (Timeout) <0.000004>
18:50:24.148277 pselect6(12, [11<pipe:[4049949]>], NULL, NULL, {tv_sec=0, tv_nsec=0}, NULL) = 0 (Timeout) <0.000004>
18:50:24.148292 pselect6(13, [12<TCPv6:[4030038]>], NULL, NULL, {tv_sec=0, tv_nsec=0}, NULL) = 1 (in [12], left {tv_sec=0, tv_nsec=0}) <0.000015>
18:50:24.148910 pselect6(13, [7<pipe:[4049946]> 11<pipe:[4049949]> 12<TCPv6:[4030038]>], [], NULL, NULL, NULL) = 1 (in [12]) <0.000005>
18:50:24.149512 pselect6(8, [7<pipe:[4049946]>], NULL, NULL, {tv_sec=0, tv_nsec=0}, NULL) = 0 (Timeout) <0.000003>
18:50:24.149527 pselect6(12, [11<pipe:[4049949]>], NULL, NULL, {tv_sec=0, tv_nsec=0}, NULL) = 0 (Timeout) <0.000003>
18:50:24.149540 pselect6(13, [12<TCPv6:[4030038]>], NULL, NULL, {tv_sec=0, tv_nsec=0}, NULL) = 1 (in [12], left {tv_sec=0, tv_nsec=0}) <0.000008>
18:50:24.150144 pselect6(13, [7<pipe:[4049946]> 11<pipe:[4049949]> 12<TCPv6:[4030038]>], [], NULL, NULL, NULL) = 1 (in [12]) <0.000005>
18:50:24.150755 pselect6(8, [7<pipe:[4049946]>], NULL, NULL, {tv_sec=0, tv_nsec=0}, NULL) = 0 (Timeout) <0.000004>
18:50:24.150770 pselect6(12, [11<pipe:[4049949]>], NULL, NULL, {tv_sec=0, tv_nsec=0}, NULL) = 0 (Timeout) <0.000004>
18:50:24.150785 pselect6(13, [12<TCPv6:[4030038]>], NULL, NULL, {tv_sec=0, tv_nsec=0}, NULL) = 1 (in [12], left {tv_sec=0, tv_nsec=0}) <0.000008>
18:50:24.151415 pselect6(13, [7<pipe:[4049946]> 11<pipe:[4049949]> 12<TCPv6:[4030038]>], [], NULL, NULL, NULL) = 1 (in [12]) <0.000008>
18:50:24.152029 pselect6(8, [7<pipe:[4049946]>], NULL, NULL, {tv_sec=0, tv_nsec=0}, NULL) = 0 (Timeout) <0.000004>
18:50:24.152045 pselect6(12, [11<pipe:[4049949]>], NULL, NULL, {tv_sec=0, tv_nsec=0}, NULL) = 0 (Timeout) <0.000004>
18:50:24.152059 pselect6(13, [12<TCPv6:[4030038]>], NULL, NULL, {tv_sec=0, tv_nsec=0}, NULL) = 1 (in [12], left {tv_sec=0, tv_nsec=0}) <0.000005>
18:50:24.152663 pselect6(13, [7<pipe:[4049946]> 11<pipe:[4049949]> 12<TCPv6:[4030038]>], [], NULL, NULL, NULL) = 1 (in [12]) <0.000006>
18:50:24.153265 pselect6(8, [7<pipe:[4049946]>], NULL, NULL, {tv_sec=0, tv_nsec=0}, NULL) = 0 (Timeout) <0.000004>
18:50:24.153283 pselect6(12, [11<pipe:[4049949]>], NULL, NULL, {tv_sec=0, tv_nsec=0}, NULL) = 0 (Timeout) <0.000004>
18:50:24.153297 pselect6(13, [12<TCPv6:[4030038]>], NULL, NULL, {tv_sec=0, tv_nsec=0}, NULL) = 1 (in [12], left {tv_sec=0, tv_nsec=0}) <0.000005>
18:50:24.153894 pselect6(13, [7<pipe:[4049946]> 11<pipe:[4049949]> 12<TCPv6:[4030038]>], [], NULL, NULL, NULL) = 1 (in [12]) <0.000007>
18:50:24.154507 pselect6(8, [7<pipe:[4049946]>], NULL, NULL, {tv_sec=0, tv_nsec=0}, NULL) = 0 (Timeout) <0.000005>
18:50:24.154525 pselect6(12, [11<pipe:[4049949]>], NULL, NULL, {tv_sec=0, tv_nsec=0}, NULL) = 0 (Timeout) <0.000004>
^C18:50:24.154539 pselect6(13, [12<TCPv6:[4030038]>], NULL, NULL, {tv_sec=0, tv_nsec=0}, NULLstrace: Process 238881 detached
 <detached ...>

gdb -p 238881
GNU gdb (Ubuntu 12.1-0ubuntu1~22.04) 12.1
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word".
Attaching to process 238881
Reading symbols from /usr/sbin/xrdp...
(No debugging symbols found in /usr/sbin/xrdp)
Reading symbols from /usr/lib/x86_64-linux-gnu/xrdp/libcommon.so.0...
(No debugging symbols found in /usr/lib/x86_64-linux-gnu/xrdp/libcommon.so.0)
Reading symbols from /usr/lib/x86_64-linux-gnu/xrdp/libxrdp.so.0...
(No debugging symbols found in /usr/lib/x86_64-linux-gnu/xrdp/libxrdp.so.0)
Reading symbols from /lib/x86_64-linux-gnu/libc.so.6...
Reading symbols from /usr/lib/debug/.build-id/69/389d485a9793dbe873f0ea2c93e02efaa9aa3d.debug...
Reading symbols from /lib/x86_64-linux-gnu/libssl.so.3...
(No debugging symbols found in /lib/x86_64-linux-gnu/libssl.so.3)
Reading symbols from /lib/x86_64-linux-gnu/libcrypto.so.3...
(No debugging symbols found in /lib/x86_64-linux-gnu/libcrypto.so.3)
Reading symbols from /lib/x86_64-linux-gnu/libjpeg.so.8...
(No debugging symbols found in /lib/x86_64-linux-gnu/libjpeg.so.8)
Reading symbols from /lib64/ld-linux-x86-64.so.2...
Reading symbols from /usr/lib/debug/.build-id/61/ef896a699bb1c2e4e231642b2e1688b2f1a61e.debug...
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
0x00007f1240f2174d in __GI___select (nfds=12, readfds=0x7ffec1871b40, writefds=0x0, exceptfds=0x0, timeout=0x7ffec1871b30) at ../sysdeps/unix/sysv/linux/select.c:69
69	../sysdeps/unix/sysv/linux/select.c: No such file or directory.
(gdb) where
#0  0x00007f1240f2174d in __GI___select (nfds=12, readfds=0x7ffec1871b40, writefds=0x0, exceptfds=0x0, timeout=0x7ffec1871b30)
    at ../sysdeps/unix/sysv/linux/select.c:69
#1  0x00007f1241078920 in ?? () from /usr/lib/x86_64-linux-gnu/xrdp/libcommon.so.0
#2  0x000055629a5dfa4a in ?? ()
#3  0x000055629a5ca3db in ?? ()
#4  0x00007f1240e2fd90 in __libc_start_call_main (main=main@entry=0x55629a5c9c10, argc=argc@entry=1, argv=argv@entry=0x7ffec1872ba8)
    at ../sysdeps/nptl/libc_start_call_main.h:58
#5  0x00007f1240e2fe40 in __libc_start_main_impl (main=0x55629a5c9c10, argc=1, argv=0x7ffec1872ba8, init=<optimized out>, fini=<optimized out>,
    rtld_fini=<optimized out>, stack_end=0x7ffec1872b98) at ../csu/libc-start.c:392
#6  0x000055629a5caa95 in ?? ()

Hi @ckpeter,
Firstly, here's a warning on this sort of configuration:-
Never expose ANY RDP server (including xrdp) to the internet in this way. The protocol isn't safe enough to support this.
These days there's no excuse not to use a VPN of some sort to protect sensitive resources. Since you've already got point-to-point connectivity, consider either OpenVPN or wireguard as these are straightforward to set up with the server end on the xrdp machine. Then configure xrdp (and maybe other services) to listen on the VPN endpoint.
As for your actual problem, the stack trace doesn't contain enough information to work out why the loop is happening. I can see where you are in the code, but it's not clear exactly what is happening at the transport level. To find the loop I think you'd need to take a coredump of the looping process using the gcore command, and then send us a link to somewhere where we can download it. Don't post a link to the coredump on the internet, as it's possible the core file will contain sensitive information.
My recommendation to you is to implement a VPN ASAP to protect your RDP connections and not to worry about the coredump.

Thank you, @matt335672. I will take your recommendation.


No key stroke for AltGr + space (and other AltGr combinations)

Hi :-)
There is a whole community in France using Bépo keyboards both for dev and writing (https://bepo.fr/wiki/Accueil) and we identified an incompatibility with the AltGr layer in Windows Terminal (and some other softwares it seems). More specifically with '_' (underscore) which is placed in <AltGr + space>. A fex other combinations don't work but are not as critical as the underscore for use in terminal.
The Bépo driver is however able to send '_' with <AltGr + space> in the command line utility, powershell and ubuntu WSL when open independently. It's also working in the VSCode terminal sub-window.

This sounds like /dup #11649, which is fixed in the coming release (should be out today!)


Allow "nopkgconfig" build tag to disable cgo pkgconfig directive

I have a specific build environment where libgtk-3-dev and dependencies are in non-standard locations and I cannot rely on pkg-config to define the compiler and linker flags. My requirement is to be able to specify those flags directly, and for that to be possible a build tag needs to be able to disable the "pkgconfig" directive.
 Though I do like pkg-config, it allows pointing to the local/custom directory (PKG_CONFIG_LIBDIR/PKG_CONFIG_PATH) where one can do all the modifications without messing directly with the code. But this is also nice to have.

Thanks for the quick merge!

Though I do like pkg-config, it allows pointing to the local/custom directory (PKG_CONFIG_LIBDIR/PKG_CONFIG_PATH) where one can do all the modifications without messing directly with the code.

That is true in some cases and I did consider it as a solution in my current problem. However without libgtk-3-dev package actually installed, it has a bunch of pc files that point to lib symlinks that aren't really in /usr. The pc files would need to be properly configured in the custom location so that they point to symlinks that point to the shared libs. It was just much easier to have the ability to specify my own known flags in my build script for the project.
Thanks!


fix(sem rel): Testing sematic release

:tada: This PR is included in version 1.0.1 :tada:
The release is available on npm package (@latest dist-tag)
Your semantic-release bot :package::rocket:


[Event Request] Codeunit 22 Item Jnl.-Post Line - OnAfterInitMfgUnitCost

Hi, would it be possible to get an event OnAfterInitMfgUnitCost in Codeunit 22 Item Jnl.-Post Line, procedure PostOutput, like this :

?
Thanks

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. We will update this issue with information about availability. Please do not reply to this, as we do not monitor closed issues. If you have follow-up questions or requests, please create a new issue where you reference this one.


Add support for AW9523 BOARD_SC05

IO expansion conflicts when used with touch drivers
I have tried with Adafruit<EMAIL_ADDRESS>drivers

Example has been added: https://github.com/smartpanle/PanelLan_esp32_arduino/blob/master/examples/peripherals/aw9523/aw9523.ino


[iOS] Cancelling authorization

Steps to reproduce

Start an authorization
Handle PlatformException (or any exception)
Handle authorization result
Place palm in-front of camera during authorization
System dialog pops-up
Select cancel
No exception and no callback called.

Expected results
When the user cancels an attempt the code should be informed somehow.
Actual results
No callback or exception.
Code sample
Code sample
    try {
        _localAuth.authenticate(
            localizedReason: "Authenticate please",
            options: const AuthenticationOptions(biometricOnly: true))
            .then(
                (bool auth) async {
                  log("Biometric response: $auth");
                });
      } on PlatformException catch (e) {
        log("Error using biometric $e");
      }

Screenshots or Video

Screenshots / Video demonstration
[Upload media here]

Logs
Logs
[Paste your logs here]

Flutter Doctor output
Doctor output
❯ flutter doctor -v
[✓] Flutter (Channel stable, 3.22.2, on macOS 14.5 23F79 darwin-x64, locale en-GB)
    • Flutter version 3.22.2 on channel stable at /Users/george/flutter_macos_3.16.1-stable/flutter
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision 761747bfc5 (3 weeks ago), 2024-06-05 22:15:13 +0200
    • Engine revision edd8546116
    • Dart version 3.4.3
    • DevTools version 2.34.3

[✓] Android toolchain - develop for Android devices (Android SDK version 34.0.0)
    • Android SDK at /Users/george/Library/Android/sdk
    • Platform android-34, build-tools 34.0.0
    • ANDROID_HOME = /Users/george/Library/Android/sdk
    • Java binary at: /Applications/Android Studio.app/Contents/jbr/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 17.0.10+0-17.0.10b1087.21-11609105)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS (Xcode 15.0.1)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Build 15A507
    • CocoaPods version 1.15.2

[✓] Chrome - develop for the web
    • Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome

[✓] Android Studio (version 2024.1)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build 17.0.10+0-17.0.10b1087.21-11609105)

[✓] IntelliJ IDEA Ultimate Edition (version 2024.1.4)
    • IntelliJ at /Applications/IntelliJ IDEA.app
    • Flutter plugin version 80.0.2
    • Dart plugin version 241.17890.8

[✓] VS Code (version 1.90.2)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension can be installed from:
      🔨 https://marketplace.visualstudio.com/items?itemName=Dart-Code.flutter

[✓] Connected device (3 available)
    • Undefined iPhone Pro Max 14 (mobile) • 00008120-00111C9001E0C01E • ios            • iOS 17.5.1 21F90
    • macOS (desktop)                      • macos                     • darwin-x64     • macOS 14.5 23F79 darwin-x64
    • Chrome (web)                         • chrome                    • web-javascript • Google Chrome 126.0.6478.127
    ! Error: Browsing on the local area network for Georgios’s Apple Watch. Ensure the device is unlocked and discoverable via Bluetooth. (code -27)

[✓] Network resources
    • All expected network resources are available.

• No issues found!

try {
        _localAuth.authenticate(
            localizedReason: "Authenticate please",
            options: const AuthenticationOptions(biometricOnly: true))
            .then(
                (bool auth) async {
                  log("Biometric response: $auth");
                });
      } on PlatformException catch (e) {
        log("Error using biometric $e");
      }

This code is incorrectly mixing asynchrony and Future constructions; the try/catch here will never catch exceptions from authenticate because authenticate is asynchronous, and there's no await in the try. If you either await the call, or use Future-based error handling instead of try/catch, do you still see the same issue?

Indeed switching to await we now get auth=false at least and can proceed.
Thank you


 returned a result with an error set

Describe the bug
Sometimes, API faile with an error " returned a result with an error set"
No additional error message or stack trace
Plz help me
Location
pinpointPy/pinpoint.py in add_trace_header at line 78
def end_trace(trace_id: int) -> int:  # -> Any:
    return _pinpointPy.end_trace(trace_id)
def add_trace_header(key: str, value: str, trace_id: int, location: int = 0):
    _pinpointPy.add_clue(key, value, trace_id, location)
def add_trace_header_v2(key: str, value: str, trace_id: int, location: int = 0):
    _pinpointPy.add_clues(key, value, trace_id, location)

To Reproduce
Steps to reproduce the behavior
No specific reproduce behavior.

API uses Python requests library(Send Post message)

Expected behavior
Successful API request
Screenshots

@HJinS
Do you know which plugin ?  requests

@HJinS
Do you know which plugin ? requests
Can you share more frames ?

I'm not 100% sure
I think that's RequestPlugin

My server sends several requests to another server in Loop

I want to know python server, run in asynchronously or synchronously ?
PS: do you use aio ?

I want to know python server, run in asynchronously or synchronously ?
PS: do you use aio ?

No, uses sync requests library
requests==2.32.3

I want to know python server, run in asynchronously or synchronously ?
PS: do you use aio ?

No, uses sync requests library
requests==2.32.3

Thanks,
Can you enable logging.DEBUG and share us the logging file.

BYW, please remove private information in logging file

        set_agent("cd.dev.test.py", "cd.dev.test.py",
                  'tcp:localhost:9999', -1, log_level=logging.DEBUG)

requests==2.32.3  it's the same in our env

Okay, I need a few days for DEBUG log

Here is another trace information

I want to know python server, run in asynchronously or synchronously ?
PS: do you use aio ?

No, uses sync requests library
requests==2.32.3

Thanks,
Can you enable logging.DEBUG and share us the logging file.

BYW, please remove private information in logging file

        set_agent("cd.dev.test.py", "cd.dev.test.py",
                  'tcp:localhost:9999', -1, log_level=logging.DEBUG)

requests==2.32.3  it's the same in our env

Okay, I need a few days for DEBUG log

Here is another trace information

Thanks  @HJinS

@HJinS  which pinpointPy you used ?
pip list | grep pinpointPy

@HJinS which pinpointPy you used ?
pip list | grep pinpointPy

pinpointPy==1.2.1
Sry for late :)

@HJinS
Sorry, I did not reproduce this bug in my env. While, I create a patch for you, try to avoiding sample and trace_id problem.

pip install -i https://test.pypi.org/simple/ pinpointPy==1.3.6

Any question, please share to me.

@HJinS
Sorry, I did not reproduce this bug in my env. While, I create a patch for you, try to avoiding sample and trace_id problem.

pip install -i https://test.pypi.org/simple/ pinpointPy==1.3.6

Any question, please share to me.

Thanks for your help😊
I'll test that patch on my env

@HJinS
Sorry, I did not reproduce this bug in my env. While, I create a patch for you, try to avoiding sample and trace_id problem.

pip install -i https://test.pypi.org/simple/ pinpointPy==1.3.6

Any question, please share to me.

Is there any plan for releasing this PR?

@HJinS
I will release 1.3.1 to pypi today.

@HJinS
I will release 1.3.1 to pypi today.

Thanks:)
BWY, I reproduced the bug at my test env.

And now I'm testing patch version at my test env.
I'll share the result soon with you

@HJinS
Can you share your test code ?
Here is an example for flask, https://github.com/pinpoint-apm/pinpoint-c-agent/tree/dev/testapps/PY

@HJinS
Can you share your test code ?
Here is an example for flask, https://github.com/pinpoint-apm/pinpoint-c-agent/tree/dev/testapps/PY

Actually, I reproduced End-To-End way. Not a unit test
I checked no more bug with your test build

@HJinS
Can you share your test code ?
Here is an example for flask, https://github.com/pinpoint-apm/pinpoint-c-agent/tree/dev/testapps/PY

Actually, I reproduced End-To-End way. Not a unit test
I checked no more bug with your test build

I'll try to write test code, give me a second

Thanks your quickly response !

Thanks your quickly response !

I couldn't reproduct the error at test env.
I think that's from the complex use of django serializer, transaction, DB query, requests
Actual flow
--> all flows run as sync

Serializer

transaction

child Serailzier(for loop iteration)

DB query

try, except
second transaction

DB query
API call(using requests)
some other DB query

Thanks your quickly response !

@eeliu where can I get change logs or release notes for pinpointPy?

@HJinS
I already released to pipy. Just re-install pinpointpy

pip install pinpointPy==1.3.1

@HJinS
Does your project use Process ?
from multiprocessing import Process

def f(name):
    print('hello', name)

if __name__ == '__main__':
    p = Process(target=f, args=('bob',))
    p.start()
    p.join()

@HJinS
Does your project use Process ?
from multiprocessing import Process

def f(name):
    print('hello', name)

if __name__ == '__main__':
    p = Process(target=f, args=('bob',))
    p.start()
    p.join()

Hmm, I added more,

I will keep watch this problem in our env. If the 1.3.1 not pass or reproduce again, please share to us.

Actually, run API server with process manager(AKA, supervisord)

@HJinS
yes, the pinpointpy is not fork safe, we will add more test.

@HJinS
yes, the pinpointpy is not fork safe, we will add more test.

I checked pinpointPy==1.3.1 does not reproduce the bug at our dev server.
Thanks for your support