Re: [systemd-devel] Restart SystemD service when Memory Usage in More than a threshold
Here is the bug https://github.com/linuxmint/nemo/issues/3306 . Unfortunately nemo-desktop is a very important dependency for my regular work. Currently I manually restart it. Restarting this is not as bad as it sounds like. Just the desktop icons go away and come back. Here is the service file I am currently at: [Unit] Description=Nemo Desktop Bug Workaround Wants=xdg-desktop-autostart.target PartOf=graphical-session.target BindsTo=graphical-session.target [Service] Type=forking StartLimitIntervalSec=3 ExecStart=/usr/bin/nemo-desktop # MemoryHigh=5K MemoryMax=10K Restart=always KillMode=process KillSignal=SIGKILL [Install] WantedBy=graphical-session.target xsession.target gnome-session.target END I have run: > systemctl --user list-dependencies xdg-desktop-autostart.target > xdg-desktop-autostart.target > ○ ├─app-geoclue\x2ddemo\x2dagent@autostart.service > ○ ├─app-gnome\x2dinitial\x2dsetup\x2dfirst\x2dlogin@autostart.service > ○ ├─app-gnome\x2dshell\x2doverrides\x2dmigration@autostart.service > ○ ├─app-im\x2dlaunch@autostart.service > ○ ├─app-nemo\x2ddesktop@autostart.service > ○ ├─app-nm\x2dapplet@autostart.service > ○ ├─app-orca\x2dautostart@autostart.service > ○ ├─app-org.gnome.Evolution\x2dalarm\x2dnotify@autostart.service > ○ ├─app-org.gnome.SettingsDaemon.DiskUtilityNotify@autostart.service > ○ ├─app-org.gnome.Software@autostart.service > ○ ├─app-user\x2ddirs\x2dupdate\x2dgtk@autostart.service > ○ ├─app-xdg\x2duser\x2ddirs\x2dkde@autostart.service > ○ └─app-yandex\x2ddisk@autostart.service Here app-nemo\x2ddesktop@autostart.service is most probably generated by systemd-xdg-autostart-generator using: [Desktop Entry] > Type=Application > Name=Nemo > Comment=Start Nemo desktop at log in > Exec=nemo-desktop > X-GNOME-AutoRestart=true > NoDisplay=true How can I view app-nemo\x2ddesktop@autostart.service ? If I can view this file then would like to copy the contents and edit it then remove app-nemo\x2ddesktop@autostart.service and install the custom service. On that note, would be glad to know how to remove these auto-generated files when i have a new one. On Mon, Sep 18, 2023 at 11:12 PM Michal Koutný wrote: > Hello Ahmad. > > On Sat, Sep 16, 2023 at 09:29:07PM +0600, Ahmad Ismail < > ismail...@gmail.com> wrote: > > The file in ~/.config/autostart which autostart the service is: > ^^^ > > > So, I came up with a systemd service which will restart nemo-desktop when > > memory usage is 100MB. > > Is the bug you mention a memory leak? (A restart at arbitrary moment > doesn't sound like the best user experience.) > > Or is it another cause? Nevertheless, you may want to report it to > the respective upstream or upgrade to its latest version. > > > sudo tee /etc/systemd/system/nemo-desktop-bug-workaround.service << END > ^^ > > > [Service] > > User=ismail > > Group=ismail > ... > > ExecStart=/usr/bin/nemo-desktop > ... > > What am I doing wrong here? > > Maybe you conflate a system service (running with changed User=/Group=) > and a user instance service (spawned under user@$UID.service) and some > necessary settings are missing in the nemo-dektop's environment (I'm not > familiar with that particular program, hence a guess only). > > HTH, > Michal >
Re: [systemd-devel] Is systemd-cryptsetup binary internal?
/usr/lib/systemd/ is indeed the place for internal binaries with unstable interfaces. But it's also the place where we put binaries that we don't typically expect users to call, because they are generally called via some well define .service unit or so only. […] Thanks, that made the situation clear.
Re: [systemd-devel] Restart SystemD service when Memory Usage in More than a threshold
Hello Ahmad. On Sat, Sep 16, 2023 at 09:29:07PM +0600, Ahmad Ismail wrote: > The file in ~/.config/autostart which autostart the service is: ^^^ > So, I came up with a systemd service which will restart nemo-desktop when > memory usage is 100MB. Is the bug you mention a memory leak? (A restart at arbitrary moment doesn't sound like the best user experience.) Or is it another cause? Nevertheless, you may want to report it to the respective upstream or upgrade to its latest version. > sudo tee /etc/systemd/system/nemo-desktop-bug-workaround.service << END ^^ > [Service] > User=ismail > Group=ismail ... > ExecStart=/usr/bin/nemo-desktop ... > What am I doing wrong here? Maybe you conflate a system service (running with changed User=/Group=) and a user instance service (spawned under user@$UID.service) and some necessary settings are missing in the nemo-dektop's environment (I'm not familiar with that particular program, hence a guess only). HTH, Michal signature.asc Description: PGP signature
Re: [systemd-devel] Is systemd-cryptsetup binary internal?
On Mon, 18 Sept 2023, 17:43 Nils Kattenbeck, wrote: > > Why was the decision taken to put these into /usr/lib/systemd instead of >> > /usr/libexec/systemd/? >> >> That's a Fedoraism. Why would one put something there? >> >> /usr/lib/ is where private arch-dependent package stuff goes. What's >> the rationale for /usr/libexec/ though? >> > > I am not aware of it being a Fedoraism. It is at least also used/populated > on an Ubuntu server I use and documented as part of the filesystem > hierarchy (hier(7)): > https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s07.html#ftn.idm236091914528 > On Ubuntu we mostly use multiarch locations for shared libraries i.e. /usr/lib/(arch triplet) and /usr/libexec/(native only binaries). To allow us to have additional places for native only and cross only tools. But it is not set in stone. Many gnome, KDE, dbus things ship their binaries or daemons or plugins under /usr/libexec. It sort of makes sense as /usr/lib is confusing when it mixes public libraries, with private libraries and binaries. We can move things around in systemd as well, but on grand scheme of things it is fairly minor tidy up, as neither locations are in default executable paths. /usr/lib is in library search path, which was recently abused to attack remote hosts to load unintended libraries at runtime and clear nx (the recent ssh attack is hallarious and did use systemd to show really fun stuff). So keeping only public libraries in /usr/lib going forward might be a good idea. >
Re: [systemd-devel] Is systemd-cryptsetup binary internal?
> > > Why was the decision taken to put these into /usr/lib/systemd instead of > > /usr/libexec/systemd/? > > That's a Fedoraism. Why would one put something there? > > /usr/lib/ is where private arch-dependent package stuff goes. What's > the rationale for /usr/libexec/ though? > I am not aware of it being a Fedoraism. It is at least also used/populated on an Ubuntu server I use and documented as part of the filesystem hierarchy (hier(7)): https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s07.html#ftn.idm236091914528 >
Re: [systemd-devel] Is systemd-cryptsetup binary internal?
On Mo, 18.09.23 17:47, Nils Kattenbeck (nilskem...@gmail.com) wrote: > Hi, > > /usr/lib/systemd/ is indeed the place for internal binaries with > > unstable interfaces. But it's also the place where we put binaries > > that we don't typically expect users to call, because they are > > generally called via some well define .service unit or so only. > > > > systemd-cryptsetup is one of the latter, we'd expect people to use > > this via crypttab mostly. However, the interface is nonetheless > > stable, it is a long-time part of systemd and so far we never broke > > interface and I see no reason we ever would. In fact it might be a > > candidate to move over to /usr/bin to make official, if there's > > sufficient request for that. (such a request should be made via github > > issue tracker) > > > > Why was the decision taken to put these into /usr/lib/systemd instead of > /usr/libexec/systemd/? That's a Fedoraism. Why would one put something there? /usr/lib/ is where private arch-dependent package stuff goes. What's the rationale for /usr/libexec/ though? Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] Is systemd-cryptsetup binary internal?
Hi, /usr/lib/systemd/ is indeed the place for internal binaries with > unstable interfaces. But it's also the place where we put binaries > that we don't typically expect users to call, because they are > generally called via some well define .service unit or so only. > > systemd-cryptsetup is one of the latter, we'd expect people to use > this via crypttab mostly. However, the interface is nonetheless > stable, it is a long-time part of systemd and so far we never broke > interface and I see no reason we ever would. In fact it might be a > candidate to move over to /usr/bin to make official, if there's > sufficient request for that. (such a request should be made via github > issue tracker) > Why was the decision taken to put these into /usr/lib/systemd instead of /usr/libexec/systemd/? > Thanks in advance for indicating, if systemd-cryptsetup (the binary) is > a > > tool users may rely on. > > Yes, absolutely. > > The only reason when we might break things for you is when we one day > move it from /usr/lib to /usr/bin, ;-) > > Hence: the call interface is certainly stable, the location in that > sense maybe not yet. > > Lennart > > -- > Lennart Poettering, Berlin > Greetings, Nils >
Re: [systemd-devel] [PATCH 0/1] x86/kexec: UKI support
On Tue, 12 Sept 2023 at 11:38, Jarkko Sakkinen wrote: > > On Tue Sep 12, 2023 at 2:20 AM EEST, Neal Gompa wrote: > On Mon, Sep 11, 2023 > at 7:15 PM Jarkko Sakkinen wrote: > > > On Sat Sep 9, 2023 at 7:18 PM EEST, Jan Hendrik Farr wrote: > > > > Hello, > > > > > > > > this patch implements UKI support for kexec_file_load. It will require > > > > support > > > > in the kexec-tools userspace utility. For testing purposes the > > > > following can be used: > > > > https://github.com/Cydox/kexec-test/ > > > > > > > > There has been discussion on this topic in an issue on GitHub that is > > > > linked below > > > > for reference. > > > > > > > > > > > > Some links: > > > > - Related discussion: https://github.com/systemd/systemd/issues/28538 > > > > - Documentation of UKIs: > > > > https://uapi-group.org/specifications/specs/unified_kernel_image/ > > > > > > > > Jan Hendrik Farr (1): > > > > x86/kexec: UKI support > > > > > > > > arch/x86/include/asm/kexec-uki.h | 7 ++ > > > > arch/x86/include/asm/parse_pefile.h| 32 +++ > > > > arch/x86/kernel/Makefile | 2 + > > > > arch/x86/kernel/kexec-uki.c| 113 + > > > > arch/x86/kernel/machine_kexec_64.c | 2 + > > > > arch/x86/kernel/parse_pefile.c | 110 > > > > crypto/asymmetric_keys/mscode_parser.c | 2 +- > > > > crypto/asymmetric_keys/verify_pefile.c | 110 +++- > > > > crypto/asymmetric_keys/verify_pefile.h | 16 > > > > 9 files changed, 278 insertions(+), 116 deletions(-) > > > > create mode 100644 arch/x86/include/asm/kexec-uki.h > > > > create mode 100644 arch/x86/include/asm/parse_pefile.h > > > > create mode 100644 arch/x86/kernel/kexec-uki.c > > > > create mode 100644 arch/x86/kernel/parse_pefile.c > > > > > > > > -- > > > > 2.40.1 > > > > > > What the heck is UKI? > > > > Unified Kernel Images. More details available here: > > https://uapi-group.org/specifications/specs/unified_kernel_image/ > > > > It's a way of creating initramfs-style images as fully generic, > > reproducible images that can be built server-side. > > You can build today a kernel with these compiled in: > > 1. EFI stub > 2. initeramfs > 3. cmdline > > Why another way (and label 'UKI') for a pre-existing feature? > In Ubuntu, we have considered to use the existing kernel features before going off to use UKI. Here are some of the reasons why we didn't opt to use the kernel builtin things: 1) we wanted to have ability to have TPM measured kernel commandline performed before kernel is being executed, which is what sd-stub provides us 2) we wanted to have ability to update / regenerate initrd, without rebuilding kernel. Thus whenever userspace in the initrd needs updating, we can generate new initrd for existing kernel build, create new kernel.efi, whilst using existing .linux / vmlinuz build. I don't believe it is currently trivial to relink vmlinuz with builtin initrd. 3) licensing wise it was not clear if initrd has to be GPLv2 compatible when linked inside vmlinuz, or if it can contain GPLv3 / LGPLv3 userspace code - with UKI it is believed unambigiously true, because vmlinuz boots by itself standalone and is compiled separately of the UKI. 4) we wanted to have ability to override cmdline via kernel args without secureboot, and use stock cmdline args under secureboot, to allow debugging & production behaviour from a single signed kernel.efi (that was custom development, and could be done in the stock vmlinuz too). 5) obvious mention, the intention here is to have TPM PCR measurements and Secureboot signature for vmlinuz and initrd and cmdline and dtb. There is otherwise no support for standalone signed initrd, cmdline, dtb today. Nor does vendoring it into vmlinuz achieves this to the same extent (and ease of predicting for sealing / resealing purposes). 6) in Ubuntu kernel.efi also has sbat section for targeted revocations (discussed separately elsewhere) Overall, it is mostly about flexibility to be able to reuse the same initrd against multiple kernel builds, or update use multiple initrd against the same kernel build. This is imho the biggest issue with using initrd built-into the vmlinuz itself. Resource wise, the initrd passed in via kernel.efi can be freed, as far as I understand. I don't know if the one built-into the vmlinuz is freeable. Improving design to do something else instead of UKI would be welcomed. Or for example improving the zimg linus upstream format to be a partial or a valid UKI would help as well. For example, building the kernel built-in initrd as a .initrd section that is replacable would be nice, or allowing to preload zimg with .dtb or .cmdline sections would help, and appropriately improve the linux efi stab to do measurements and loading of .dtb / .initrd from itself would be nice. Because then all the benefits / requirements described above could be made available out of the box and be trivially
Re: [systemd-devel] Is systemd-cryptsetup binary internal?
On Mo, 18.09.23 15:22, mpan (systemdml-bfok4...@mpan.pl) wrote: > Hello, > > I got redirected to here from #systemd on Libera. While responding to a > query from another person (not on #systemd), I came across an ambiguity. Any > answer I give, its validity would be uncertain. I wish to receive an > authoritative clarification. > > There is systemd-cryptsetup binary in “/usr/lib/systemd/”. Its location > suggests it’s internal to systemd and not intended for user invocation. > However, it is also listed in manual as if it was something the user might > be concerned with. The manual even has a specific, separate, explicit > reference to systemd-cryptsetup page — though it’s shared with the > corresponding service and the binary itself isn’t described. /usr/lib/systemd/ is indeed the place for internal binaries with unstable interfaces. But it's also the place where we put binaries that we don't typically expect users to call, because they are generally called via some well define .service unit or so only. systemd-cryptsetup is one of the latter, we'd expect people to use this via crypttab mostly. However, the interface is nonetheless stable, it is a long-time part of systemd and so far we never broke interface and I see no reason we ever would. In fact it might be a candidate to move over to /usr/bin to make official, if there's sufficient request for that. (such a request should be made via github issue tracker) > Thanks in advance for indicating, if systemd-cryptsetup (the binary) is a > tool users may rely on. Yes, absolutely. The only reason when we might break things for you is when we one day move it from /usr/lib to /usr/bin, ;-) Hence: the call interface is certainly stable, the location in that sense maybe not yet. Lennart -- Lennart Poettering, Berlin
[systemd-devel] Is systemd-cryptsetup binary internal?
Hello, I got redirected to here from #systemd on Libera. While responding to a query from another person (not on #systemd), I came across an ambiguity. Any answer I give, its validity would be uncertain. I wish to receive an authoritative clarification. There is systemd-cryptsetup binary in “/usr/lib/systemd/”. Its location suggests it’s internal to systemd and not intended for user invocation. However, it is also listed in manual as if it was something the user might be concerned with. The manual even has a specific, separate, explicit reference to systemd-cryptsetup page — though it’s shared with the corresponding service and the binary itself isn’t described. Thanks in advance for indicating, if systemd-cryptsetup (the binary) is a tool users may rely on. Cheers! PS Please note that I don’t want to argue with anybody, what is their opinion on this matter. I reach out to systemd-devel to obtain an authoritative answer. Stable interfaces page is not actually answering the above question, “all binaries have entries in manual” is not true, placement in “/usr/lib” is already mentioned by me, and I am aware that systemd-cryptsetup@.service and systemd-cryptsetup the binary are related.
