Re: [systemd-devel] unable to attach pid to service delegated directory in unified mode after restart
Hi, some days ago we were talking about this: > > Problem number two, there's a significant delay since when creating the > > scope, until it is ready and the pid attached into it. The only way it > > worked was to put a 'sleep' after the dbus call and make my process wait > > for the async call to dbus to be materialized. This is really > > un-elegant. > > If you want to synchronize in the cgroup creation to complete just > wait for the JobRemoved bus signal for the job returned by > StartTransientUnit(). > > StartTransientUnit returns a string to a job object path. To call JobRemoved I need the job id, so the easier way to get it is to strip the last part of the returned string from StartTransientUnit job object path. Am I right? Once I have the job id, I can then subscribe to JobRemoved bus signal for the recently created job, but what happens if during the time I am obtaining the ID or parsing the output, the job is finished? Will I lose the signal? What is the correct order of doing a StartTransientUnit and wait for the job to be finished (done, failed, whatever) ?
Re: [systemd-devel] version bump of minimal kernel version supported by systemd?
On Wed, 23 Mar 2022 22:26:15 +0100 Michael Biebl wrote: > Am Mi., 23. März 2022 um 22:11 Uhr schrieb Zbigniew Jędrzejewski-Szmek > : > > > Or in other words: I'd prefer for such people to speak up for > > themselves, rather than us trying to figure out what somebody else > > *might* be planning to do. > > That's laudable but keep in mind that users typically don't follow > systemd-devel actively. I'm pretty sure we don't even have > *maintainers* of embedded Linux following this mailing list. I'm just a user and I follow this list. That is to say, it doesn't matter what typical users or maintainers do, it's enough if just one relevant person is following. It would be nice though, if there are any such people, if they would speak up and offer their opinion or say that they are going to take it to whichever manager/committee they need to. FWIW, I think Greg was a bit too outspoken calling long maintenance attempts 'crazy'; that may have intimidated some. I'm thinking of moving distro to one that provides longer term maintenance than my present one. Although CIP is a completely different ball game; I hope they succeed. Cheers, Dave
Re: [systemd-devel] version bump of minimal kernel version supported by systemd?
Am Mi., 23. März 2022 um 22:11 Uhr schrieb Zbigniew Jędrzejewski-Szmek : > Or in other words: I'd prefer for such people to speak up for > themselves, rather than us trying to figure out what somebody else > *might* be planning to do. That's laudable but keep in mind that users typically don't follow systemd-devel actively. I'm pretty sure we don't even have *maintainers* of embedded Linux following this mailing list.
Re: [systemd-devel] version bump of minimal kernel version supported by systemd?
On Wed, Mar 23, 2022 at 03:58:22PM +, Luca Boccassi wrote: > On Wed, 2022-03-23 at 12:38 +0100, Greg KH wrote: > > On Wed, Mar 23, 2022 at 11:28:29AM +, Luca Boccassi wrote: > > > On Wed, 2022-03-23 at 11:59 +0100, Zbigniew Jędrzejewski-Szmek wrote: > > > > On Wed, Mar 23, 2022 at 09:26:05AM +0100, Greg KH wrote: > > > > > On Wed, Mar 23, 2022 at 09:17:36AM +0100, Zbigniew Jędrzejewski-Szmek > > > > > wrote: > > > > > > On Wed, Mar 23, 2022 at 08:07:48AM +0100, Greg KH wrote: > > > > > > > On Tue, Mar 22, 2022 at 05:27:07PM +0100, Zbigniew > > > > > > > Jędrzejewski-Szmek wrote: > > > > > > > > Hi all, > > > > > > > > > > > > > > > > we are considering dropping upstream support for kernel > > > > > > > > versions < 4.4. > > > > > > > > Would this be a problem for anyone? (*). > > > > > > > > > > > > > > Given that upstream (i.e. kernel.org) has dropped support for > > > > > > > kernel > > > > > > > 4.4, why not just move to not supporting kernels older than 4.9? > > > > > > > > > > > > It seems Civil Infrastructure Platform (a project under the Linux > > > > > > Foundation) still uses 4.4 [1]. > > > > > > > > > > Yes, but they are not going to be updating to a newer version of > > > > > systemd, right? > > > > > > > > > > And they are going to be "supporting" that for 20+ years. If they > > > > > want > > > > > to do something crazy like this, make them handle supporting code that > > > > > is older than 6+ years to start with. That's not the community's > > > > > issue, > > > > > that's the companies that demand such crazy requirement's issue. > > > > > > > > That's why I (we) asked the question on the list. If people are compling > > > > systemd on such old systems, or even older, we want to know about it. > > > > > > > > > > In the Debian world, Stretch which has EOL scheduled for June 2022 > > > > > > has 4.9, > > > > > > and after that Buster has 4.19. > > > > > > > > > > 4.9 is fine, and is supported by kernel.org until next year as seen > > > > > here: > > > > > https://kernel.org/category/releases.html > > > > > > > > > > I wrote "4.9" above, not "4.19" :) > > > > > > > > Yep. I'd vote for bumping to 4.9, unless some other voices pop up. > > > > > > > > Zbyszek > > > > > > Let's do 4.4 at most please - what's on kernel.org is not really that > > > important, as real usage is downstream from there anyway. > > > > And I will publically state that anyone still using 4.4.y today has an > > insecure and unsupported system. Please let's not encourage _ANYONE_ to > > do this. > > > > CIP is "special" in that they know what they are doing, and are using > > 4.4.y in a very limited set of use cases and configurations. And even > > they are going to have big problems keeping that kernel alive and > > secure. I would never expect anyone else to be able to do it, and I > > have doubts that they will either. > > > > So any "real usage" of 4.4 after today, should not matter. And if > > someone complains, send them to me please. > > > > thanks, > > > > greg k-h > > You can publically state that all day long, but you know perfectly well > that's not how the world works. In the grand scheme of things few > production scenarios build their kernel from kernel.org, most will be > getting it from a distro (best case) or a vendor (worst case), and they > couldn't care less about what kernel.org tells them to do, they use > what they get. I fully expect at some point to hear complaints from > some poor soul stuck on 3.x because of $crappy_arm_vendor with no way > to move on from there. > > Jumping forward from 3.13 to 4.4 as the baseline, allowing to take > cgroupsv2 for granted, seems like a good starting point to me. There's > very obvious and public evidence of that being used in the wild. We can > start to drop a bunch of backward-compat cruft, wait and see who > complains, and if nobody does we can re-evaluate again in a couple of > years. Yeah, but I don't think we want to go through this exercise again in a few months. If we jump, we might as well jump a bit further. CIP 4.4 is supposed to be maintained until 2027, which is awfully long. The question is: is anyone putting new systemd on those systems? If no, then they're not relevant. Or in other words: I'd prefer for such people to speak up for themselves, rather than us trying to figure out what somebody else *might* be planning to do. Zbyszek
Re: [systemd-devel] /etc/os-release but for images
Hello, Il giorno mer 23 mar 2022 alle ore 13:56 Lennart Poettering < lenn...@poettering.net> ha scritto: > > Also sadly IMAGE_VERSION doesn't allow + which is used from semver for > > build metadata (such as 1.0.0+21AF26D3 or 1.0.0+20130313144700). > > Ah, interesting. This looks like something to fix in our syntax > descriptio though. I am pretty sure we should allow all characters > that semver requires. > > Can you file an RFE issue about this on github? Or even better, submit > a PR that adds that? > I opened this PR: https://github.com/systemd/systemd/pull/22841 This doesn't enable full semver support since that would require allowing A-Z range, but I'm not sure if it is something we really want to enable (uppercase in semver looks quite uncommon by the way). That said, I'd always include some time-based counter in automatic > builds, so that the builds can be ordered. Things like sd-boot's boot > menu entry ordering relies on that. > This is indeed a good advice. > > That's pretty useful when storing a relation between the exact update > > bundle that has been used to flash a device, and the system flashed on a > > device. It turns out to be pretty useful when collecting stats about a > > device fleet or when remote managing system versions and their updates. > > So what I would do on os-release would be storing an UUID that is > generated > > every time a system image is generated, that UUID can be collected/sent > at > > runtime from a device to a remote management service. > > Why wouldn't the IMAGE_VERSION suffice for that? Why pick a UUID where > a version already works? > I would use the UUID as a further metadata in addition to IMAGE_VERSION, also for the reasons I describe later here in this mail. > > > Compared to other options an UUID here would be both reliable and easy to > > handle and generate. > > UUID is are effectively randomly generated. That sucks for build > processes I am sure, simply because they hence aren't reproducible. > Using a reliable digest, such as the one that can be generated with `casync digest`, was my first option, however if you think about an update system such such as RAUC and its bundles, you might still have the same exact filesystem digest mapping to a number of different bundles, since they can bring different hook scripts and whatever. I'm also aware of scenarios where the same filesystem tree has been used to generate different flash images in order to satisfy different flash sizes / NAND technologies. So from a practical point of view having an UUID, and forcing a different one in /etc/os-release every time a filesystem image / RAUC bundle is created allows us to have a reasonable 1:1 mapping between the update artifact and the system image that is on the device. Last but not least having it in /etc/os-release makes it pretty convenient to read it (and for sure using an UUID is easier than trying to embed the digest of the filesystem where /etc/os-release is kept ;) ) Also there is an interesting bonus: UUID is globally unique also in scenarios where users try to delete and recreate version tags without incrementing the version number (or other messy scenarios). BTW, there's now also this: > > https://systemd.io/BUILDING_IMAGES/#image-metadata > Thanks, this feature looks pretty interesting. Regards, Davide Bettio.
Re: [systemd-devel] version bump of minimal kernel version supported by systemd?
On Wed, 2022-03-23 at 12:38 +0100, Greg KH wrote: > On Wed, Mar 23, 2022 at 11:28:29AM +, Luca Boccassi wrote: > > On Wed, 2022-03-23 at 11:59 +0100, Zbigniew Jędrzejewski-Szmek wrote: > > > On Wed, Mar 23, 2022 at 09:26:05AM +0100, Greg KH wrote: > > > > On Wed, Mar 23, 2022 at 09:17:36AM +0100, Zbigniew Jędrzejewski-Szmek > > > > wrote: > > > > > On Wed, Mar 23, 2022 at 08:07:48AM +0100, Greg KH wrote: > > > > > > On Tue, Mar 22, 2022 at 05:27:07PM +0100, Zbigniew > > > > > > Jędrzejewski-Szmek wrote: > > > > > > > Hi all, > > > > > > > > > > > > > > we are considering dropping upstream support for kernel versions > > > > > > > < 4.4. > > > > > > > Would this be a problem for anyone? (*). > > > > > > > > > > > > Given that upstream (i.e. kernel.org) has dropped support for kernel > > > > > > 4.4, why not just move to not supporting kernels older than 4.9? > > > > > > > > > > It seems Civil Infrastructure Platform (a project under the Linux > > > > > Foundation) still uses 4.4 [1]. > > > > > > > > Yes, but they are not going to be updating to a newer version of > > > > systemd, right? > > > > > > > > And they are going to be "supporting" that for 20+ years. If they want > > > > to do something crazy like this, make them handle supporting code that > > > > is older than 6+ years to start with. That's not the community's issue, > > > > that's the companies that demand such crazy requirement's issue. > > > > > > That's why I (we) asked the question on the list. If people are compling > > > systemd on such old systems, or even older, we want to know about it. > > > > > > > > In the Debian world, Stretch which has EOL scheduled for June 2022 > > > > > has 4.9, > > > > > and after that Buster has 4.19. > > > > > > > > 4.9 is fine, and is supported by kernel.org until next year as seen > > > > here: > > > > https://kernel.org/category/releases.html > > > > > > > > I wrote "4.9" above, not "4.19" :) > > > > > > Yep. I'd vote for bumping to 4.9, unless some other voices pop up. > > > > > > Zbyszek > > > > Let's do 4.4 at most please - what's on kernel.org is not really that > > important, as real usage is downstream from there anyway. > > And I will publically state that anyone still using 4.4.y today has an > insecure and unsupported system. Please let's not encourage _ANYONE_ to > do this. > > CIP is "special" in that they know what they are doing, and are using > 4.4.y in a very limited set of use cases and configurations. And even > they are going to have big problems keeping that kernel alive and > secure. I would never expect anyone else to be able to do it, and I > have doubts that they will either. > > So any "real usage" of 4.4 after today, should not matter. And if > someone complains, send them to me please. > > thanks, > > greg k-h You can publically state that all day long, but you know perfectly well that's not how the world works. In the grand scheme of things few production scenarios build their kernel from kernel.org, most will be getting it from a distro (best case) or a vendor (worst case), and they couldn't care less about what kernel.org tells them to do, they use what they get. I fully expect at some point to hear complaints from some poor soul stuck on 3.x because of $crappy_arm_vendor with no way to move on from there. Jumping forward from 3.13 to 4.4 as the baseline, allowing to take cgroupsv2 for granted, seems like a good starting point to me. There's very obvious and public evidence of that being used in the wild. We can start to drop a bunch of backward-compat cruft, wait and see who complains, and if nobody does we can re-evaluate again in a couple of years. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Re: [systemd-devel] /etc/os-release but for images
On Mi, 23.03.22 13:38, Davide Bettio (davide.bet...@secomind.com) wrote: > > That's the idea: take the packages, build an image, and then append > > IMAGE_ID/IMAGE_VERSION to it? > > Sure, sounds pretty convenient, here my point was about blindly appending > those additional fields (trusting the distribution didn't already set > them). I don't know your distro. But I'd certainly view it as a bug if your distro fills in these two fields but doesn't actually work based on pre-built images, but is solely package-based. > > > I cook a new image, furthermore I plan to replace the whole operating > > > system image (that I keep read-only) in order to update it, so BUILD_ID > > > would change at every update (so it sounds slightly different from the > > > original described semantic). > > > > BUILD_ID is not for that. You are looking for IMAGE_VERSION. > > IMAGE_VERSION didn't look to me a good option for identifying nightly > builds, or any kind of build that wasn't cooked from a tagged image build > recipe. I think it should be fine for that. > Also sadly IMAGE_VERSION doesn't allow + which is used from semver for > build metadata (such as 1.0.0+21AF26D3 or 1.0.0+20130313144700). Ah, interesting. This looks like something to fix in our syntax descriptio though. I am pretty sure we should allow all characters that semver requires. Can you file an RFE issue about this on github? Or even better, submit a PR that adds that? That said, I'd always include some time-based counter in automatic builds, so that the builds can be ordered. Things like sd-boot's boot menu entry ordering relies on that. > That's pretty useful when storing a relation between the exact update > bundle that has been used to flash a device, and the system flashed on a > device. It turns out to be pretty useful when collecting stats about a > device fleet or when remote managing system versions and their updates. > So what I would do on os-release would be storing an UUID that is generated > every time a system image is generated, that UUID can be collected/sent at > runtime from a device to a remote management service. Why wouldn't the IMAGE_VERSION suffice for that? Why pick a UUID where a version already works? > Compared to other options an UUID here would be both reliable and easy to > handle and generate. UUID is are effectively randomly generated. That sucks for build processes I am sure, simply because they hence aren't reproducible. BTW, there's now also this: https://systemd.io/BUILDING_IMAGES/#image-metadata Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] /etc/os-release but for images
Hello, Il giorno mer 23 mar 2022 alle ore 11:32 Lennart Poettering < lenn...@poettering.net> ha scritto: > On Mi, 23.03.22 10:51, Davide Bettio (davide.bet...@secomind.com) wrote: > > Well, if the distribution people build both packages and disk images, > they can set IMAGE_ID/IMAGE_VERSION for the latter. But this should > always be part of building images, not of building packages. > > > Can I safely just append those fields at the end of > > the copy of the /etc/os-release file? > > That's the idea: take the packages, build an image, and then append > IMAGE_ID/IMAGE_VERSION to it? > Sure, sounds pretty convenient, here my point was about blindly appending those additional fields (trusting the distribution didn't already set them). > > Speaking of BUILD_ID, according to the spec sounds like a field > > reserved to > > BUILD_ID? That's a different thing... > > https://www.freedesktop.org/software/systemd/man/os-release.html#IMAGE_ID= > vs. > https://www.freedesktop.org/software/systemd/man/os-release.html#BUILD_ID= > > > distributions: "BUILD_ID may be used in distributions where the original > > installation image version is important", from my side what I need is to > > identify the git revision + build date of the recipe I'm using to cook > the > > image installed on the system, also my plan is to change that ID every > time > > I cook a new image, furthermore I plan to replace the whole operating > > system image (that I keep read-only) in order to update it, so BUILD_ID > > would change at every update (so it sounds slightly different from the > > original described semantic). > > BUILD_ID is not for that. You are looking for IMAGE_VERSION. > IMAGE_VERSION didn't look to me a good option for identifying nightly builds, or any kind of build that wasn't cooked from a tagged image build recipe. Also sadly IMAGE_VERSION doesn't allow + which is used from semver for build metadata (such as 1.0.0+21AF26D3 or 1.0.0+20130313144700). Here my aim was to provide a way to find which build recipe revision has been used or when an image has been built, that is also useful when debugging a device. > Last but not least, I was looking for a machine parsable unique id, so I > > plan to use BUILD_UUID if it is not kept reserved for other usages, that > > will be an UUID that is freshly generated every time I cook a new image. > > What's this for? > That's pretty useful when storing a relation between the exact update bundle that has been used to flash a device, and the system flashed on a device. It turns out to be pretty useful when collecting stats about a device fleet or when remote managing system versions and their updates. So what I would do on os-release would be storing an UUID that is generated every time a system image is generated, that UUID can be collected/sent at runtime from a device to a remote management service. Compared to other options an UUID here would be both reliable and easy to handle and generate. Thanks again for the kind and helpful conversation, regards, Davide Bettio.
Re: [systemd-devel] version bump of minimal kernel version supported by systemd?
On Wed, Mar 23, 2022 at 11:28:29AM +, Luca Boccassi wrote: > On Wed, 2022-03-23 at 11:59 +0100, Zbigniew Jędrzejewski-Szmek wrote: > > On Wed, Mar 23, 2022 at 09:26:05AM +0100, Greg KH wrote: > > > On Wed, Mar 23, 2022 at 09:17:36AM +0100, Zbigniew Jędrzejewski-Szmek > > > wrote: > > > > On Wed, Mar 23, 2022 at 08:07:48AM +0100, Greg KH wrote: > > > > > On Tue, Mar 22, 2022 at 05:27:07PM +0100, Zbigniew Jędrzejewski-Szmek > > > > > wrote: > > > > > > Hi all, > > > > > > > > > > > > we are considering dropping upstream support for kernel versions < > > > > > > 4.4. > > > > > > Would this be a problem for anyone? (*). > > > > > > > > > > Given that upstream (i.e. kernel.org) has dropped support for kernel > > > > > 4.4, why not just move to not supporting kernels older than 4.9? > > > > > > > > It seems Civil Infrastructure Platform (a project under the Linux > > > > Foundation) still uses 4.4 [1]. > > > > > > Yes, but they are not going to be updating to a newer version of > > > systemd, right? > > > > > > And they are going to be "supporting" that for 20+ years. If they want > > > to do something crazy like this, make them handle supporting code that > > > is older than 6+ years to start with. That's not the community's issue, > > > that's the companies that demand such crazy requirement's issue. > > > > That's why I (we) asked the question on the list. If people are compling > > systemd on such old systems, or even older, we want to know about it. > > > > > > In the Debian world, Stretch which has EOL scheduled for June 2022 has > > > > 4.9, > > > > and after that Buster has 4.19. > > > > > > 4.9 is fine, and is supported by kernel.org until next year as seen > > > here: > > > https://kernel.org/category/releases.html > > > > > > I wrote "4.9" above, not "4.19" :) > > > > Yep. I'd vote for bumping to 4.9, unless some other voices pop up. > > > > Zbyszek > > Let's do 4.4 at most please - what's on kernel.org is not really that > important, as real usage is downstream from there anyway. And I will publically state that anyone still using 4.4.y today has an insecure and unsupported system. Please let's not encourage _ANYONE_ to do this. CIP is "special" in that they know what they are doing, and are using 4.4.y in a very limited set of use cases and configurations. And even they are going to have big problems keeping that kernel alive and secure. I would never expect anyone else to be able to do it, and I have doubts that they will either. So any "real usage" of 4.4 after today, should not matter. And if someone complains, send them to me please. thanks, greg k-h
Re: [systemd-devel] version bump of minimal kernel version supported by systemd?
On Wed, 2022-03-23 at 11:59 +0100, Zbigniew Jędrzejewski-Szmek wrote: > On Wed, Mar 23, 2022 at 09:26:05AM +0100, Greg KH wrote: > > On Wed, Mar 23, 2022 at 09:17:36AM +0100, Zbigniew Jędrzejewski-Szmek wrote: > > > On Wed, Mar 23, 2022 at 08:07:48AM +0100, Greg KH wrote: > > > > On Tue, Mar 22, 2022 at 05:27:07PM +0100, Zbigniew Jędrzejewski-Szmek > > > > wrote: > > > > > Hi all, > > > > > > > > > > we are considering dropping upstream support for kernel versions < > > > > > 4.4. > > > > > Would this be a problem for anyone? (*). > > > > > > > > Given that upstream (i.e. kernel.org) has dropped support for kernel > > > > 4.4, why not just move to not supporting kernels older than 4.9? > > > > > > It seems Civil Infrastructure Platform (a project under the Linux > > > Foundation) still uses 4.4 [1]. > > > > Yes, but they are not going to be updating to a newer version of > > systemd, right? > > > > And they are going to be "supporting" that for 20+ years. If they want > > to do something crazy like this, make them handle supporting code that > > is older than 6+ years to start with. That's not the community's issue, > > that's the companies that demand such crazy requirement's issue. > > That's why I (we) asked the question on the list. If people are compling > systemd on such old systems, or even older, we want to know about it. > > > > In the Debian world, Stretch which has EOL scheduled for June 2022 has > > > 4.9, > > > and after that Buster has 4.19. > > > > 4.9 is fine, and is supported by kernel.org until next year as seen > > here: > > https://kernel.org/category/releases.html > > > > I wrote "4.9" above, not "4.19" :) > > Yep. I'd vote for bumping to 4.9, unless some other voices pop up. > > Zbyszek Let's do 4.4 at most please - what's on kernel.org is not really that important, as real usage is downstream from there anyway. What matters for core compatibility is what's the oldest in a reasonable environment, and we know that's at 4.4. It's already quite a bump from the current 3.13. At least according to our documentation it wouldn't save us much anyway, as the biggest leap is taking cgroupv2 for granted, which requires 4.1, so it's included regardless. Unless there's something undocumented that would make a big difference, in practical terms of maintainability? -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Re: [systemd-devel] version bump of minimal kernel version supported by systemd?
On Wed, Mar 23, 2022 at 09:26:05AM +0100, Greg KH wrote: > On Wed, Mar 23, 2022 at 09:17:36AM +0100, Zbigniew Jędrzejewski-Szmek wrote: > > On Wed, Mar 23, 2022 at 08:07:48AM +0100, Greg KH wrote: > > > On Tue, Mar 22, 2022 at 05:27:07PM +0100, Zbigniew Jędrzejewski-Szmek > > > wrote: > > > > Hi all, > > > > > > > > we are considering dropping upstream support for kernel versions < 4.4. > > > > Would this be a problem for anyone? (*). > > > > > > Given that upstream (i.e. kernel.org) has dropped support for kernel > > > 4.4, why not just move to not supporting kernels older than 4.9? > > > > It seems Civil Infrastructure Platform (a project under the Linux > > Foundation) still uses 4.4 [1]. > > Yes, but they are not going to be updating to a newer version of > systemd, right? > > And they are going to be "supporting" that for 20+ years. If they want > to do something crazy like this, make them handle supporting code that > is older than 6+ years to start with. That's not the community's issue, > that's the companies that demand such crazy requirement's issue. That's why I (we) asked the question on the list. If people are compling systemd on such old systems, or even older, we want to know about it. > > In the Debian world, Stretch which has EOL scheduled for June 2022 has 4.9, > > and after that Buster has 4.19. > > 4.9 is fine, and is supported by kernel.org until next year as seen > here: > https://kernel.org/category/releases.html > > I wrote "4.9" above, not "4.19" :) Yep. I'd vote for bumping to 4.9, unless some other voices pop up. Zbyszek
Re: [systemd-devel] /etc/os-release but for images
On Mi, 23.03.22 10:51, Davide Bettio (davide.bet...@secomind.com) wrote: > Hello, > > First of all, thanks for your answers. > > It wasn't really clear to me that the /etc/os-release file was editable > from a 3rd party other than the distribution maintainers, so thanks for the > clarifications. Well, it's not precisely supposed to be something users or admins should edit. But image builders may. > Are the distributions required to leave IMAGE_ID and > IMAGE_VERSION empty? Well, if the distribution people build both packages and disk images, they can set IMAGE_ID/IMAGE_VERSION for the latter. But this should always be part of building images, not of building packages. > Can I safely just append those fields at the end of > the copy of the /etc/os-release file? That's the idea: take the packages, build an image, and then append IMAGE_ID/IMAGE_VERSION to it? > Speaking of BUILD_ID, according to the spec sounds like a field > reserved to BUILD_ID? That's a different thing... https://www.freedesktop.org/software/systemd/man/os-release.html#IMAGE_ID= vs. https://www.freedesktop.org/software/systemd/man/os-release.html#BUILD_ID= > distributions: "BUILD_ID may be used in distributions where the original > installation image version is important", from my side what I need is to > identify the git revision + build date of the recipe I'm using to cook the > image installed on the system, also my plan is to change that ID every time > I cook a new image, furthermore I plan to replace the whole operating > system image (that I keep read-only) in order to update it, so BUILD_ID > would change at every update (so it sounds slightly different from the > original described semantic). BUILD_ID is not for that. You are looking for IMAGE_VERSION. > Last but not least, I was looking for a machine parsable unique id, so I > plan to use BUILD_UUID if it is not kept reserved for other usages, that > will be an UUID that is freshly generated every time I cook a new image. What's this for? Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] /etc/os-release but for images
Hello, First of all, thanks for your answers. It wasn't really clear to me that the /etc/os-release file was editable from a 3rd party other than the distribution maintainers, so thanks for the clarifications. Are the distributions required to leave IMAGE_ID and IMAGE_VERSION empty? Can I safely just append those fields at the end of the copy of the /etc/os-release file? Speaking of BUILD_ID, according to the spec sounds like a field reserved to distributions: "BUILD_ID may be used in distributions where the original installation image version is important", from my side what I need is to identify the git revision + build date of the recipe I'm using to cook the image installed on the system, also my plan is to change that ID every time I cook a new image, furthermore I plan to replace the whole operating system image (that I keep read-only) in order to update it, so BUILD_ID would change at every update (so it sounds slightly different from the original described semantic). Last but not least, I was looking for a machine parsable unique id, so I plan to use BUILD_UUID if it is not kept reserved for other usages, that will be an UUID that is freshly generated every time I cook a new image. Regards, Davide Bettio. Il giorno mar 22 mar 2022 alle ore 18:09 Lennart Poettering < lenn...@poettering.net> ha scritto: > On Di, 22.03.22 17:10, Davide Bettio (davide.bet...@secomind.com) wrote: > > > Hello, > > > > I would like to figure out if anyone has proposed any kind of standard > for > > storing metadata about a system image. > > The IMAGE_ID= and IMAGE_VERSION= fields from /etc/os-release are > supposed to be used for that. > > i.e. the idea was that you can take a generic distro (fedora, debian, > …) build an image off it, and it will put its own os info in > /usr/lib/os-release, and make /etc/os-release a symlink to it. Your > image build would then replace /etc/os-release with a file, that > incorporates /usr/lib/os-release and adds in IMAGE_ID=/IMAGE_VERSION=. > > Each time you rebuild the image your image building tool would repeat > that step. i.e. it would be the image builder tool's job to extend the > generic OS data from /usr/lib/ with info about the image and place the > result in /etc/. > > Lennart > > -- > Lennart Poettering, Berlin >
[systemd-devel] Q: Relying on exit code of journalctl -g ....
Hi! It's not documented, but "journalctl -g ..." seems to exit with success when the pattern was found, and with 1 when it was not. Can I rely on that? The other thing is when grepping across reboots, the "-- Reboot --" is always output, even if it does not match the pattern. Is that a bug or a feature? (systemd-246.16 of SLES15 SP3) Actually I had some "quiet grep" in mind that only sets the exit code depending whether some message was found or not. Regards, Ulrich
Re: [systemd-devel] systemd move processes to user.slice cgroup after updating service configuration file
On Mi, 23.03.22 14:25, 吾为男子 (csren...@qq.com) wrote:
> dear all experts,
>
> now we have such a problem:
>
> we need to update our systemd service configuration file,
>
> before updating, our service has already created some processes and
> make them attach to cgroup
> /system.slice/{our-service-name}.service/{our-service-sub-group},
> this is what we would expect,
>
> but, on some machine, sometimes, after we updating our service
> configuration file, these processes as mentioned above,
> will be moved to /user.slice, this is what we do NOT
> expect, there is a certain probability that this will happen
Is it possible that said service invokes sudo or su or so, or in some
other way opens a PAM session? If so, this will migrate the calling
process into a per-session cgroup below user.slice.
What's the precise cgroup slice of one such occurance?
> how to prevent this action from systemd? it will be a great honor
> for me to get your help, thanks.
Don't use sudo/su from scripts. If you need to acquire privileges from
a script, use util-linux' setpriv tool. It will change privileges for
you but without opening a PAM session, and thus without cgroup
migratory effect.
Lennart
--
Lennart Poettering, Berlin
Re: [systemd-devel] version bump of minimal kernel version supported by systemd?
On Wed, Mar 23, 2022 at 09:17:36AM +0100, Zbigniew Jędrzejewski-Szmek wrote: > On Wed, Mar 23, 2022 at 08:07:48AM +0100, Greg KH wrote: > > On Tue, Mar 22, 2022 at 05:27:07PM +0100, Zbigniew Jędrzejewski-Szmek wrote: > > > Hi all, > > > > > > we are considering dropping upstream support for kernel versions < 4.4. > > > Would this be a problem for anyone? (*). > > > > Given that upstream (i.e. kernel.org) has dropped support for kernel > > 4.4, why not just move to not supporting kernels older than 4.9? > > It seems Civil Infrastructure Platform (a project under the Linux > Foundation) still uses 4.4 [1]. Yes, but they are not going to be updating to a newer version of systemd, right? And they are going to be "supporting" that for 20+ years. If they want to do something crazy like this, make them handle supporting code that is older than 6+ years to start with. That's not the community's issue, that's the companies that demand such crazy requirement's issue. > In the Debian world, Stretch which has EOL scheduled for June 2022 has 4.9, > and after that Buster has 4.19. 4.9 is fine, and is supported by kernel.org until next year as seen here: https://kernel.org/category/releases.html I wrote "4.9" above, not "4.19" :) thanks, greg k-h
Re: [systemd-devel] version bump of minimal kernel version supported by systemd?
On Wed, Mar 23, 2022 at 08:07:48AM +0100, Greg KH wrote: > On Tue, Mar 22, 2022 at 05:27:07PM +0100, Zbigniew Jędrzejewski-Szmek wrote: > > Hi all, > > > > we are considering dropping upstream support for kernel versions < 4.4. > > Would this be a problem for anyone? (*). > > Given that upstream (i.e. kernel.org) has dropped support for kernel > 4.4, why not just move to not supporting kernels older than 4.9? It seems Civil Infrastructure Platform (a project under the Linux Foundation) still uses 4.4 [1]. In the Debian world, Stretch which has EOL scheduled for June 2022 has 4.9, and after that Buster has 4.19. Of course we'd like to move to 4.19, but we don't want to disrupt distros that use older kernels. Is ≤4.19 really unused? [1] https://wiki.linuxfoundation.org/civilinfrastructureplatform/start Zbyszek
Re: [systemd-devel] version bump of minimal kernel version supported by systemd?
On Tue, Mar 22, 2022 at 05:27:07PM +0100, Zbigniew Jędrzejewski-Szmek wrote: > Hi all, > > we are considering dropping upstream support for kernel versions < 4.4. > Would this be a problem for anyone? (*). Given that upstream (i.e. kernel.org) has dropped support for kernel 4.4, why not just move to not supporting kernels older than 4.9? thanks, greg k-h
