Re: [systemd-devel] swap on zram service unit, using Conflicts=umount
On Mon, Jun 24, 2019 at 6:11 AM Lennart Poettering wrote: > That said, I don't really grok zram, and not sure why there's any need > to detach it at all. I mean, if at shutdown we lose compressed RAM > or lose uncompressed RAM shouldn't really matter. Hence from my > perspective there's no need for Conflicts= at all, but maybe I am > missing something? Huh yeah, possibly if anything there could be low memory systems just barely getting by with swap on zram, and even swapoff at reboot time would cause it to get stuck. It might just be better to clobber it at reboot time? I'd like to allow a user to 'systemctl stop zram' which does swapoff and removes the zram device. But is there something that could go into the unit file that says "don't wait for swapoff, if everything else is ready for shutdown, go ahead and reboot now?" -- Chris Murphy ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Is it possible to set a default for MemoryMax?
Thanks for the pointer, Lennart! I've done some initial review of the commit you pointed me to, and it seems like it should be pretty straightforward to use that understanding to implement the other functions. Might take a bit depending on my local management's perspective on the priority of getting this done, but I'll put together a PR as soon as I have a chance. In the meantime, can anyone tell me if there's any semblance of a 'getting started' page for systemd development? The main code changes should be easy enough, but I see that there are a number of tests included with the particular commit I was pointed to in addition to the code change itself. I'd like to make sure that I know what sort of tests are expected in a commit and how to run them (and any other things I might need to do to ensure things are in order before submitting the PR). Thanks! -Sean McKay -Original Message- From: Lennart Poettering Sent: Monday, June 17, 2019 7:55 AM To: McKay, Sean Cc: systemd-devel@lists.freedesktop.org Subject: Re: [systemd-devel] Is it possible to set a default for MemoryMax? On Do, 13.06.19 22:06, McKay, Sean (sean.mc...@hpe.com) wrote: > Hi there, > > First off, forgive me if this is documented or discussed somewhere > already. I couldn't find any reference to it in the man pages or in > the mailing list archives, and I'm relatively new to this community so > I could easily be missing something. > > Context that can be skipped if you only care about the technical part > of the question: We're building a customized linux environment using > systemd as the init system, and we've found that some of the daemons > that we're including in said environment aren't particularly good > citizens in regards to their resource consumption (admittedly most of > those are the ones that have been written in house). As a result, > while we try to track down and fix those bugs, we would like to limit > the memory that processes are allowed to consume by default (with > actual values in the .service files overriding that default). While we > understand that this is the sort of thing that's probably best set > individually per-daemon based on an understanding of how the daemon > should behave, it would at least give us a starting point and would > mean that a leaky process would be the one that crashed (when it hit > the memory limit), rather than taking down the whole system or the OOM > killer selecting a different process that's working correctly but > still happens to be using more memory at the time. > > We've been trying to encourage our developers to use memory accounting > and MemoryMax, since we're given to understand that's applied to the > entire cgroup's memory usage for a given daemon's slice. The > documentation, however, doesn't seem to indicate that a default value > for any of the memory variables can be set in the system.conf file, > and some quick experimental testing seems to indicate that's truly the > case. There does seem to be support for setting the memory resource > limit (limitas), but my understanding is that wouldn't apply to > subprocesses that are spawned off by the parent daemon - they'd > inherit the resource limit, but get their own instance of it (and I'm > actually still trying to figure out if it would apply to threads, > given the way I'm given to understand Linux treats threads. For > memory, it would probably still cap things, since they're all in the > same address space, but I'm unclear if that would be true of the other > limits that can be applied). > > Am I missing something and this is possible to set? Or is it something > that's come up and been rejected for some reason? Or has it come up > and not been important relative to other development priorities? Or > has it simply never come up because we're the first ones to want to do > something so foolish? > > Any insight that you could provide would be greatly appreciated! Thanks. See https://github.com/systemd/systemd/pull/12211 It adds this for MemoryLow=. I see no reason why we shouldn't add this for MemoryMax= too. Please consider pinging @cdown about this, and maybe prep a PR that adds this for you. It should be simple now, given that the MemoryLow= case is very very similar. Or maybe MemoryLow= is actually the knob you want to use and thus what you are asking for already exists in current git? Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Changes to dependency graph during boot
On 6/24/19 7:53 PM, Andrei Borzenkov wrote: > 24.06.2019 17:41, Conrad Hoffmann пишет: >> Hi, >> >> TL;DR: I was wondering what happens if a unit executed early during the >> boot process changes the current dependency graph by either enabling or >> even starting another unit that was previously disabled. Is this defined >> behaviour, and if so what are the rules? >> > > Enabling unit should have no impact on existing job queue as > dependencies are evaluated when job is submitted. Thanks for confirming that. > Starting unit will simply add its job and all its dependencies to > current job queue unless it results in conflict. Conflicts inside single > "transaction" (i.e. dependency closure built on job submit) are blocked, > but between different jobs I am not sure. It may be rejected or it may > cancel current jobs. What constitutes a conflict here? A dependecy re-calculation would not result in any conflict, but finishing the current queue (boot) first and then starting with "new" unit and it's dependencies would lead to incorrect dependencies. So I take it that's conflict already? >> Longer version: >> >> I am looking at an issue that seems to be with cloud-init in combination >> with Arch Linux. Arch Linux uses systemd, and cloud-init is executed >> (via units) multiple times during boot (running different cloud-init >> modules at each stage). The idea is that one of the early cloud-init >> modules writes a network config and the next stages' systemd unit >> depends on network.target, so that e.g. systemd-networkd would be >> started in between, reading the generated config and setting up the >> network accordingly. >> >> However, the Arch Linux implementation in cloud-init uses the netctl [1] >> tool, which works a bit differently: there is a dedicated unit file for >> each connection (called profile), and netctl can be used to switch >> between them (or have multiple enabled at the same time). This has the >> effect that since you don't know the network configuration in advance, >> you also don't know what profiles/units to enable for boot, since they >> will only be generated on first boot by the cloud-init service. As such, >> the cloud-init code does what would seem like a reasonable idea: in >> addition to generating the units for each connection, it also runs >> `systemctl enable` for them. However, this does not seem to working. My >> observations are that this does work on _second_ boot, however not on >> the first one. I even tested runnig `daemon-reload` after `enable`, but >> to no avail. >> >> There are multiple ways on how the code could be made to work. But the >> question of what to expect when running systemctl commands during boot >> seemed both general and important enough (also in the wider context of >> cloud-init) that I figured I should get some professional input before >> making any assumptions :) >> >> So the questions would be: a service executed by systemd during boot ... >> >> • *enables* a previously disabled unit, what happens/should happen? >> • *starts* a previously disabled unit, what happens/should happen? >> >> In both cases, the implication is that the unit to be enabled/started >> causes non-trivial changes to the dependecy graph. >> >> [1] https://wiki.archlinux.org/index.php/Netctl >> >> Thanks a lot, >> Conrad >> ___ >> systemd-devel mailing list >> systemd-devel@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/systemd-devel >> > > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/systemd-devel > ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Changes to dependency graph during boot
24.06.2019 17:41, Conrad Hoffmann пишет: > Hi, > > TL;DR: I was wondering what happens if a unit executed early during the > boot process changes the current dependency graph by either enabling or > even starting another unit that was previously disabled. Is this defined > behaviour, and if so what are the rules? > Enabling unit should have no impact on existing job queue as dependencies are evaluated when job is submitted. Starting unit will simply add its job and all its dependencies to current job queue unless it results in conflict. Conflicts inside single "transaction" (i.e. dependency closure built on job submit) are blocked, but between different jobs I am not sure. It may be rejected or it may cancel current jobs. > Longer version: > > I am looking at an issue that seems to be with cloud-init in combination > with Arch Linux. Arch Linux uses systemd, and cloud-init is executed > (via units) multiple times during boot (running different cloud-init > modules at each stage). The idea is that one of the early cloud-init > modules writes a network config and the next stages' systemd unit > depends on network.target, so that e.g. systemd-networkd would be > started in between, reading the generated config and setting up the > network accordingly. > > However, the Arch Linux implementation in cloud-init uses the netctl [1] > tool, which works a bit differently: there is a dedicated unit file for > each connection (called profile), and netctl can be used to switch > between them (or have multiple enabled at the same time). This has the > effect that since you don't know the network configuration in advance, > you also don't know what profiles/units to enable for boot, since they > will only be generated on first boot by the cloud-init service. As such, > the cloud-init code does what would seem like a reasonable idea: in > addition to generating the units for each connection, it also runs > `systemctl enable` for them. However, this does not seem to working. My > observations are that this does work on _second_ boot, however not on > the first one. I even tested runnig `daemon-reload` after `enable`, but > to no avail. > > There are multiple ways on how the code could be made to work. But the > question of what to expect when running systemctl commands during boot > seemed both general and important enough (also in the wider context of > cloud-init) that I figured I should get some professional input before > making any assumptions :) > > So the questions would be: a service executed by systemd during boot ... > > • *enables* a previously disabled unit, what happens/should happen? > • *starts* a previously disabled unit, what happens/should happen? > > In both cases, the implication is that the unit to be enabled/started > causes non-trivial changes to the dependecy graph. > > [1] https://wiki.archlinux.org/index.php/Netctl > > Thanks a lot, > Conrad > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/systemd-devel > ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Changes to dependency graph during boot
Hi, TL;DR: I was wondering what happens if a unit executed early during the boot process changes the current dependency graph by either enabling or even starting another unit that was previously disabled. Is this defined behaviour, and if so what are the rules? Longer version: I am looking at an issue that seems to be with cloud-init in combination with Arch Linux. Arch Linux uses systemd, and cloud-init is executed (via units) multiple times during boot (running different cloud-init modules at each stage). The idea is that one of the early cloud-init modules writes a network config and the next stages' systemd unit depends on network.target, so that e.g. systemd-networkd would be started in between, reading the generated config and setting up the network accordingly. However, the Arch Linux implementation in cloud-init uses the netctl [1] tool, which works a bit differently: there is a dedicated unit file for each connection (called profile), and netctl can be used to switch between them (or have multiple enabled at the same time). This has the effect that since you don't know the network configuration in advance, you also don't know what profiles/units to enable for boot, since they will only be generated on first boot by the cloud-init service. As such, the cloud-init code does what would seem like a reasonable idea: in addition to generating the units for each connection, it also runs `systemctl enable` for them. However, this does not seem to working. My observations are that this does work on _second_ boot, however not on the first one. I even tested runnig `daemon-reload` after `enable`, but to no avail. There are multiple ways on how the code could be made to work. But the question of what to expect when running systemctl commands during boot seemed both general and important enough (also in the wider context of cloud-init) that I figured I should get some professional input before making any assumptions :) So the questions would be: a service executed by systemd during boot ... • *enables* a previously disabled unit, what happens/should happen? • *starts* a previously disabled unit, what happens/should happen? In both cases, the implication is that the unit to be enabled/started causes non-trivial changes to the dependecy graph. [1] https://wiki.archlinux.org/index.php/Netctl Thanks a lot, Conrad ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] swap on zram service unit, using Conflicts=umount
On Mon, Jun 24, 2019 at 02:11:03PM +0200, Lennart Poettering wrote: > On Sa, 22.06.19 10:42, Chris Murphy (li...@colorremedies.com) wrote: > > > Hi, > > > > I've got a commit to add 'Conflicts=umount.target' to this zram > > service based on a bug comment I cited in the comment. But I'm not > > certain I understand if it's a good idea or necessary. > > > > https://src.fedoraproject.org/fork/chrismurphy/rpms/zram/c/63900c455e8a53827aed697b9f602709b7897eb2?branch=devel > > > > I figure it's plausible at shutdown time that something is swapped > > out, and a umount before swapoff could hang (briefly or indefinitely I > > don't know), and therefore it's probably better to cause swapoff to > > happen before umount. > > So for tmpfs mounts that don't turn off DefaultDependencies= we > implicit add in an After=swap.target ordering dep. The thinking was > that there's no point in swapping in all data of a tmpfs because we > want to detach the swap device when we are going to flush it all out > right after anyway. This made quite a difference to some folks. But we add Conflicts=umount.target, Before=umount.target, so we do swapoff on all swap devices, which means that swap in the data after all. Maybe that's an error, and we should remove this, at least for normal swap partitions (not files)? > That said, I don't really grok zram, and not sure why there's any need > to detach it at all. I mean, if at shutdown we lose compressed RAM > or lose uncompressed RAM shouldn't really matter. Hence from my > perspective there's no need for Conflicts= at all, but maybe I am > missing something? > > Zbigniew, any particular reason why you added the Conflicts= line? It's been a while since I wrote that comment... Most likely I did it because that's the default combination that we use for units, and I didn't think that something different should be used for a swap service. Don't read too much into it. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] swap on zram service unit, using Conflicts=umount
On Sa, 22.06.19 10:42, Chris Murphy (li...@colorremedies.com) wrote: > Hi, > > I've got a commit to add 'Conflicts=umount.target' to this zram > service based on a bug comment I cited in the comment. But I'm not > certain I understand if it's a good idea or necessary. > > https://src.fedoraproject.org/fork/chrismurphy/rpms/zram/c/63900c455e8a53827aed697b9f602709b7897eb2?branch=devel > > I figure it's plausible at shutdown time that something is swapped > out, and a umount before swapoff could hang (briefly or indefinitely I > don't know), and therefore it's probably better to cause swapoff to > happen before umount. So for tmpfs mounts that don't turn off DefaultDependencies= we implicit add in an After=swap.target ordering dep. The thinking was that there's no point in swapping in all data of a tmpfs because we want to detach the swap device when we are going to flush it all out right after anyway. This made quite a difference to some folks. That said, I don't really grok zram, and not sure why there's any need to detach it at all. I mean, if at shutdown we lose compressed RAM or lose uncompressed RAM shouldn't really matter. Hence from my perspective there's no need for Conflicts= at all, but maybe I am missing something? Zbigniew, any particular reason why you added the Conflicts= line? Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
