Re: [systemd-devel] oomd wake-up frequency
Thanks for responding! Comments inline. On 8/25/23 7:54 AM, Michal Koutný wrote: Do you have any "Swap Monitored CGroups:" in output of `oomctl dump`? "Swap Monitored CGroups:" appears to be empty on the three physical machines I have at my disposal to test. (Fedora 38, Fedora 39, and GNOME OS). I think the loop's event source could be disabled when no cgroups require swap monitoring [1] (and enabled lazily when such are configured). That sounds like a great idea! Not sure whether/how much SWAP_INTERVAL_USEC could be increased to retain responsiveness. Given the empirical evidence here of all these machines not having swap monitoring to begin with, I think the interval is less of an issue compared to dynamic event sources. As it were, things like thermald are waking up every 4 seconds when the underlying hardware doesn't support async notification. It would be fantastic if we had a poll() mechanism that would coalesce the sorts of wake-ups across processes. -- Christian
Re: [systemd-devel] oomd wake-up frequency
Hello. On Tue, Aug 22, 2023 at 01:59:52PM -0700, Christian Hergert wrote: > The primary thing I see showing up when profiling an idle system is oomd. My > casual reading through the code would lead me to believe it's waking up a > CPU every .15 seconds. That coincides with swap monitoring timer. > Is there a way we could have this wake up less? My goal here is to iron out > all the little things which are causing energy drain when idle. Do you have any "Swap Monitored CGroups:" in output of `oomctl dump`? I think the loop's event source could be disabled when no cgroups require swap monitoring [1] (and enabled lazily when such are configured). Not sure whether/how much SWAP_INTERVAL_USEC could be increased to retain responsiveness. HTT, Michal [1] https://github.com/systemd/systemd/blob/1925f829ab17cee7d65cc8c350d8281f8f41588e/src/oom/oomd-manager.c#L375 signature.asc Description: PGP signature
Re: [systemd-devel] Append to logfile with year-month
On Do, 24.08.23 09:48, Cecil Westerhof (cldwester...@gmail.com) wrote: > In a service file I can use: > StandardOutput=append:/var/log/root/aptCacheUsage.log > > but I want to use something like: > StandardOutput=append:/var/log/root/aptCacheUsage_$(date +%%Y-%%m).log > > Did does not work, because this puts it in: > /var/log/root/aptCacheUsage_$(date +%Y-%m).log > > Is there a way I can put it in: > /var/log/root/aptCacheUsage_2023-08.log > > while it would automatically next month go into: >/var/log/root/aptCacheUsage_2023-09.log > > I could of-course put it into: > /var/log/root/aptCacheUsage.log > > and at the beginning of the month move it if it exists with a timed > service, but I really would not like that kind of solution. We do not support this. systemd supports evaluating some specifiers, but time/date is not one of them, in particular as we resolve specifiers at parse time of the unit only, not afterwards. or in other words: we'd resolve the specifiers early at boot, and that doesn't look like what you want. Also, for long-running services this wouldn#t work anyway, as we can't rotate files like that, because we cannot externally close the current stdout of a process and replace it with a new file. hence, what you are trying to do is not supported, and is unlikely to ever be supported for multiple reasons. sorry! Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] Why are the priorities of stdout and stderr the same
On Do, 24.08.23 16:31, Cecil Westerhof (cldwester...@gmail.com) wrote: > Normally in a script when something is send to stdout it is seen as an > error has occurred. > But in systemd both get a priority of 6 (info). > Why does stderr not get a priority of 3 (err), or at least lower as > stdout? stderr is a bit of a misnomer, it's not just for errors, it's also for progress output, informational output and so, basically everything that is not considered the primary output contents that one would want to propagate in pipelines. We should not "assume the worst", hence given that the stderr stream is typically used for all kinds of informational messages we should not always assume its an error, because quite often its just informational. Hence, we use LOG_INFO if we have no clue simply because that's the "best assumption". We generally recommend apps to use syslog() or sd-journal APIs to generate their log messages and specify the log level for each message explicitly, to avoid any doubts. Many programming language's logging frameworks natively have support for these. > Now when I want the things send to stderr I also get the things send to > stdout. I can't parse that. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] Error during SCC_DAEMON installation
On Do, 24.08.23 13:28, Maber, Paul (paul.ma...@cgi.com) wrote: > Classification: Confidential > > When installing the SAP Cloud Connector, I am getting the following errors. > The installation is being performed by the user root as instructed. > > :/opt/sap/scc # journalctl -xeu scc_daemon.service > Aug 24 13:41:35 scc_daemon[5574]: scc_Daemon start failed, see > logfile: /opt/sap/scc/scc_daemon.log systemd is just the messenger here. Please contact SAP for help on this SAP product, not the systemd project. Lennart -- Lennart Poettering, Berlin
