Re: [systemd-devel] sd_bus_process() + sd_bus_wait() is it not suitable for application?
Hi，
When the busctl command is used to call the method corresponding to this
function, the memory used by the process will increase after 65 ~ 70 times. If
continue to call, the memory usage will continue to increase.
Refer to the method in SYSTEMd. (such as: ListUnits, GetDynamicUsers)
Thanks,
Byron
At 2022-01-22 22:25:35, "Dan Nicholson" wrote:
Aren't your leaking reply there? You don't seem to be unreffing it and it's not
being returned to someone else to do it either.
On Sat, Jan 22, 2022, 3:12 AM www wrote:
+Add the implementation code of the method.
static int method_load_info(sd_bus_message *message, void *userdata, sd_bus_err
*error)
{
sd_bus_message *reply = NULL;
..
r = sd_bus_message_read(message. "r", &xxx);
..
r= sd_bus_message_new_return(message, &reply); //
..
r = sd_bus_message_open_container(reply, 'a', "()");
r = sd_bus_message_append(reply, "()", xx, xx ,xx ,xx);
..
r = sd_bus_message_close_container(reply);
...
return sd_bus_send(NULL, reply, NULL);
}
Thanks,
Byron
At 2022-01-22 14:16:13, "www" wrote:
Dear all,
When using sd_bus_process() + sd_bus_wait() to implement the
application(Service), call the methods function on the service can obtain the
correct information. Run a certain number of times will lead to insufficient
memory and memleak does occur.
It should not be a problem with the DBUS method, because a single call does not
increase memory, it needs to call the method 65 ~ 70 times, and you will see
the memory increase. After stopping the call, the memory will not decrease. It
seems that it has nothing to do with the time interval when the method is
called.
code implementation：
int main()
{
..
r = sd_bus_open_system(&bus);
...
r = sd_bus_add_object_vtable(bus, ..);
..
r= sd_bus_request_name(bus, "xxx.xx.xx.xxx");
..
for( ; ; )
{
r = sd_bus_process(bus, NULL);
...
r = sd_bus_wait(bus, -1);
..
}
sd_bus_slot_unref(slot);
sd_bus_unref(bus);
}
thanks,
Byron
[systemd-devel] Launching script that needs network before suspend
Hello, I have my computer hooked up to an AVR that runs my home cinema and ideally I would like the computer to turn off the AVR when I turn it off or suspend it. The only way to do this is over network and I wrote a simple script that does just that. Hooking it to shutdown was quite easy using network.target that is defined when shutting down. I am struggling to make it work with suspend though. When I look at the logs, terminating network seems to be the first thing that happens when suspend is invoked. I tried putting the script to /usr/lib/systemd/system-sleep/ and it runs, but only after network si down, so it fails. Running the script with systemd-inhibit (ExecStart=/usr/bin/systemd-inhibit --what=sleep my_script) tells me that "Failed to inhibit: The operation inhibition has been requested for is already running". Is there a way to make this work with service files by specifying that the script needs to be run before network is shut down or would I need to run a daemon listening for PrepareForSleep as here: https://github.com/davidn/av/blob/master/av ? Kind regards, Tomas
[systemd-devel] systemd killing processes on monitor wakeup?
(A variation of this message was originally sent to fedora-users) I have a couple processes that have been consistently dying every time I wake up my monitors after the system has been idle. One is Slack Desktop and the other is IntelliJ IDEA. I used an eBPF program (killsnoop.py at https://github.com/iovisor/bcc/blob/master/tools/killsnoop.py) to trace where the signal to shut down these processes was coming from, and it appears that systemd is sending pretty much every active process signal 15 and then 18. TIME PIDCOMM SIG TPID RESULT ... on monitor wakeup ... 12:16:58 2551 systemd 15 2938613 0 12:16:58 2551 systemd 18 2938613 0 12:16:58 2551 systemd 15 2938814 0 12:16:58 2551 systemd 18 2938814 0 12:16:58 2551 systemd 15 2938832 0 12:16:58 2551 systemd 18 2938832 0 12:16:58 2551 systemd 15 2938978 0 12:16:58 2551 systemd 18 2938978 0 12:16:58 2551 systemd 15 2939432 0 12:16:58 2551 systemd 18 2939432 0 12:16:58 2551 systemd 15 2939899 0 12:16:58 2551 systemd 18 2939899 0 12:16:58 2551 systemd 15 2942192 0 12:16:58 2551 systemd 18 2942192 0 ... Process 2551 is the PDF of the source of the signal according to killsnoop, 15 and 18 are the signals being sent, and TPID is the target PID, which among many others, does include my dying processes. Process 2551 is indeed systemd, specifically the user process: raman 2551 1 0 Jan07 ?00:00:10 /usr/lib/systemd/systemd --user This behavior is relatively new. What is going on here? I haven't found any other reports of this behavior anywhere else. I'm using systemd-249.9-1.fc35 on Fedora 35. Regards, Raman
Re: [systemd-devel] Have I got circular dependencies?
On 23/01/2022 19:44, Andrei Borzenkov wrote: Where dependency to /home comes from? It is not in your unit file. If it thinks my unit depends on /home, that's wrong. /home comes from fstab, and the partition is not available until AFTER my service has run. Home is on an lv, which is on raid, which is on dm-integrity, which isn't available until my service has turned it on ... Otherwise normal services are ordered by default after sysinit.target and local file systems are ordered before sysinit.target so you have loop. Add DefaultDependencies=no to your service definition. Thanks. I presume that goes in the [Install] section? I can find plenty of stuff telling me WHAT DefaultDependencies is, but nothing I can understand that tells me WHERE it goes. Thanks, Cheers, Wol
Re: [systemd-devel] Have I got circular dependencies?
On 23.01.2022 19:42, Wols Lists wrote: > This is probably a classic "need a clue" problem ... my system has > suddenly stopped booting properly, and I guess it's a problem with my > custom systemd service. > > Basically, I've configured my raid device on top of dm-integrity, so > that needs to be set up before my /home becomes visible. I've tried to > say my integrity.service needs to run before the mdadm and lvm services. > > I also seem to remember a mention of dm-integrity in recent (the > latest?) release notes? > > The problem being I don't know what - or where - most of the system > systemd services and files are. > > Does all this output indicate a problem with my service? Can I just > delete my "Before" line, bearing in mind that if the service doesn't run > my /home won't appear? (mdadm and lvm pick things up if I run the > service manually.) > > And could this be why my service seems occasionally to get randomly > killed on boot, leading the problem I described where /home has disappeared? > > Cheers, > Wol > > anthony@thewolery /etc/systemd/system $ systemctl --version > systemd 249 (249) > +PAM -AUDIT -SELINUX -APPARMOR +IMA +SMACK +SECCOMP +GCRYPT +GNUTLS > +OPENSSL +ACL +BLKID -CURL -ELFUTILS -FIDO2 +IDN2 -IDN -IPTC +KMOD > -LIBCRYPTSETUP +LIBFDISK +PCRE2 -PWQUALITY -P11KIT -QRENCODE -BZIP2 +LZ4 > -XZ -ZLIB +ZSTD -XKBCOMMON +UTMP +SYSVINIT default-hierarchy=unified > anthony@thewolery /etc/systemd/system $ > > anthony@thewolery /etc/systemd/system $ cat integritysetup.service > [Unit] > Before=mdmonitor.service lvm2-lvmetad.service > > [Service] > ExecStart=/usr/local/bin/integritysetup.sh > > [Install] > WantedBy=default.target > anthony@thewolery /etc/systemd/system $ systemctl status home.mount > > > [8.193416] systemd[1]: Detected architecture x86-64. > [8.221972] systemd[1]: Hostname set to . > [9.387275] systemd[1]: Configuration file > /etc/systemd/system/scarletdme.service is marked executable. Please > remove executable permission bits. Proceeding anyway. > [9.397748] systemd[1]: Configuration file > /etc/systemd/system/integritysetup.service is marked executable. Please > remove executable permission bits. Proceeding anyway. > [9.531750] systemd[1]: Configuration file > /etc/systemd/system/gentoo_root_snapshot.timer is marked executable. > Please remove executable permission bits. Proceeding anyway. > [9.563443] systemd[1]: Configuration file > /etc/systemd/system/gentoo_root_snapshot.service is marked executable. > Please remove executable permission bits. Proceeding anyway. > [9.610463] systemd[1]: integritysetup.service: Found ordering cycle > on sysinit.target/start > [9.610534] systemd[1]: integritysetup.service: Found dependency on > systemd-timesyncd.service/start > [9.610604] systemd[1]: integritysetup.service: Found dependency on > systemd-tmpfiles-setup.service/start > [9.610673] systemd[1]: integritysetup.service: Found dependency on > local-fs.target/start > [9.610740] systemd[1]: integritysetup.service: Found dependency on > home-ISO.automount/start > [9.610807] systemd[1]: integritysetup.service: Found dependency on > home.mount/start > [9.610872] systemd[1]: integritysetup.service: Found dependency on > integritysetup.service/start Where dependency to /home comes from? It is not in your unit file. Otherwise normal services are ordered by default after sysinit.target and local file systems are ordered before sysinit.target so you have loop. Add DefaultDependencies=no to your service definition.
[systemd-devel] Have I got circular dependencies?
This is probably a classic "need a clue" problem ... my system has suddenly stopped booting properly, and I guess it's a problem with my custom systemd service. Basically, I've configured my raid device on top of dm-integrity, so that needs to be set up before my /home becomes visible. I've tried to say my integrity.service needs to run before the mdadm and lvm services. I also seem to remember a mention of dm-integrity in recent (the latest?) release notes? The problem being I don't know what - or where - most of the system systemd services and files are. Does all this output indicate a problem with my service? Can I just delete my "Before" line, bearing in mind that if the service doesn't run my /home won't appear? (mdadm and lvm pick things up if I run the service manually.) And could this be why my service seems occasionally to get randomly killed on boot, leading the problem I described where /home has disappeared? Cheers, Wol anthony@thewolery /etc/systemd/system $ systemctl --version systemd 249 (249) +PAM -AUDIT -SELINUX -APPARMOR +IMA +SMACK +SECCOMP +GCRYPT +GNUTLS +OPENSSL +ACL +BLKID -CURL -ELFUTILS -FIDO2 +IDN2 -IDN -IPTC +KMOD -LIBCRYPTSETUP +LIBFDISK +PCRE2 -PWQUALITY -P11KIT -QRENCODE -BZIP2 +LZ4 -XZ -ZLIB +ZSTD -XKBCOMMON +UTMP +SYSVINIT default-hierarchy=unified anthony@thewolery /etc/systemd/system $ anthony@thewolery /etc/systemd/system $ cat integritysetup.service [Unit] Before=mdmonitor.service lvm2-lvmetad.service [Service] ExecStart=/usr/local/bin/integritysetup.sh [Install] WantedBy=default.target anthony@thewolery /etc/systemd/system $ systemctl status home.mount [8.193416] systemd[1]: Detected architecture x86-64. [8.221972] systemd[1]: Hostname set to . [9.387275] systemd[1]: Configuration file /etc/systemd/system/scarletdme.service is marked executable. Please remove executable permission bits. Proceeding anyway. [9.397748] systemd[1]: Configuration file /etc/systemd/system/integritysetup.service is marked executable. Please remove executable permission bits. Proceeding anyway. [9.531750] systemd[1]: Configuration file /etc/systemd/system/gentoo_root_snapshot.timer is marked executable. Please remove executable permission bits. Proceeding anyway. [9.563443] systemd[1]: Configuration file /etc/systemd/system/gentoo_root_snapshot.service is marked executable. Please remove executable permission bits. Proceeding anyway. [9.610463] systemd[1]: integritysetup.service: Found ordering cycle on sysinit.target/start [9.610534] systemd[1]: integritysetup.service: Found dependency on systemd-timesyncd.service/start [9.610604] systemd[1]: integritysetup.service: Found dependency on systemd-tmpfiles-setup.service/start [9.610673] systemd[1]: integritysetup.service: Found dependency on local-fs.target/start [9.610740] systemd[1]: integritysetup.service: Found dependency on home-ISO.automount/start [9.610807] systemd[1]: integritysetup.service: Found dependency on home.mount/start [9.610872] systemd[1]: integritysetup.service: Found dependency on integritysetup.service/start [9.610941] systemd[1]: integritysetup.service: Job systemd-timesyncd.service/start deleted to break ordering cycle starting with integritysetup.service/start [9.611216] systemd[1]: integritysetup.service: Found ordering cycle on sysinit.target/start [9.611284] systemd[1]: integritysetup.service: Found dependency on systemd-journal-catalog-update.service/start [9.611354] systemd[1]: integritysetup.service: Found dependency on systemd-tmpfiles-setup.service/start [9.611424] systemd[1]: integritysetup.service: Found dependency on local-fs.target/start [9.611490] systemd[1]: integritysetup.service: Found dependency on home-ISO.automount/start [9.611557] systemd[1]: integritysetup.service: Found dependency on home.mount/start [9.611623] systemd[1]: integritysetup.service: Found dependency on integritysetup.service/start [9.611690] systemd[1]: integritysetup.service: Job systemd-journal-catalog-update.service/start deleted to break ordering cycle starting with integritysetup.service/start [9.611911] systemd[1]: integritysetup.service: Found ordering cycle on sysinit.target/start [9.611979] systemd[1]: integritysetup.service: Found dependency on systemd-tmpfiles-setup.service/start [9.612048] systemd[1]: integritysetup.service: Found dependency on local-fs.target/start [9.612119] systemd[1]: integritysetup.service: Found dependency on home-ISO.automount/start [9.612186] systemd[1]: integritysetup.service: Found dependency on home.mount/start [9.612251] systemd[1]: integritysetup.service: Found dependency on integritysetup.service/start [9.612319] systemd[1]: integritysetup.service: Job systemd-tmpfiles-setup.service/start deleted to break ordering cycle starting with integritysetup.service/start [9.612539] systemd[1]: integritysetup.service: Foun
Re: [systemd-devel] stacked extension not working
FYI, support for using directories with --extension has just been merged in main and will be available in v251. On Wed, 20 Oct 2021 at 16:15, Luca Boccassi wrote: > > No, it's only supported for images at the moment, as the documentation > says: > >--extension=PATH >Add an additional image PATH as an overlay on top of IMAGE > when attaching/detaching. This argument can >be specified multiple times, in which case the order in > which images are laid down follows the rules >specified in systemd.exec(5) for the ExtensionImages= > directive. The image(s) must contain an >extension-release file with metadata that matches what is > defined in the os-release of IMAGE. See: os- >release(5). > > The internal implementation of extensions is ExtensionImage= which as > the name says, it's for binary images. There's no ExtensionDirectory= > yet - no reason it can't there be one, just someone needs to implement > it. PRs welcome! > > On Wed, 2021-10-20 at 17:04 +0200, Umut Tezduyar Lindskog wrote: > > It indeed worked as squashfs image. Thanks for that. > > > > It is not working as a folder though (portablectl --runtime attach -- > > extension=./stackupper ./base stackupper) This stuff should work on > > folders too right? Should I open a ticket? > > > > Also, when it works, the upper stack shows as detached. Isn't that > > wrong too? Should I open a ticket? > > > > root@osboxes:/home/osboxes/Development# portablectl attach --runtime > > --extension $PWD/stackupper.raw $PWD/base.raw stackupper > > (Matching unit files with prefixes 'stackupper'.) > > Created directory /run/systemd/system.attached. > > Created directory /run/systemd/system.attached/stackupper.service.d. > > Written /run/systemd/system.attached/stackupper.service.d/20- > > portable.conf. > > Created symlink /run/systemd/system.attached/stackupper.service.d/10- > > profile.conf → > > /usr/lib/systemd/portable/profile/default/service.conf. > > Copied /run/systemd/system.attached/stackupper.service. > > Created symlink /run/portables/stackupper.raw → > > /home/osboxes/Development/stackupper.raw. > > Created symlink /run/portables/base.raw → > > /home/osboxes/Development/base.raw. > > root@osboxes:/home/osboxes/Development# portablectl list > > NAME TYPE RO CRTIME MTIME > > USAGE STATE > > base raw no Wed 2021-10-20 10:54:41 EDT Wed 2021-10-20 > > 10:54:41 EDT 920.0K attached-runtime > > stackupper raw no Wed 2021-10-20 10:54:57 EDT Wed 2021-10-20 > > 10:54:57 EDT 36.0K detached > > > > > > Thanks again > > Umut > > > > On Wed, Oct 20, 2021 at 12:01 AM Luca Boccassi > > wrote: > > > On Tue, 2021-10-19 at 16:09 +0200, Umut Tezduyar Lindskog wrote: > > > > Hi Luca, have you had time to help me out or do you think you > > > could > > > > help me > > > > out? Thanks in advance. > > > > > > Works fine for me with systemd 249.5: > > > > > > $ tar xf ~/Downloads/portable.tar > > > $ mksquashfs base/ base.raw > > > Parallel mksquashfs: Using 4 processors > > > Creating 4.0 filesystem on base.raw, block size 131072. > > > [== > > > =|] 23/23 100% > > > > > > Exportable Squashfs 4.0 filesystem, gzip compressed, data block > > > size 131072 > > > compressed data, compressed metadata, compressed fragments, > > > compressed xattrs, compressed ids > > > duplicates are removed > > > Filesystem size 918.80 Kbytes (0.90 Mbytes) > > > 39.83% of uncompressed filesystem size (2306.95 Kbytes) > > > Inode table size 359 bytes (0.35 Kbytes) > > > 35.69% of uncompressed inode table size (1006 bytes) > > > Directory table size 319 bytes (0.31 Kbytes) > > > 62.80% of uncompressed directory table size (508 bytes) > > > Number of duplicate files found 3 > > > Number of inodes 29 > > > Number of files 9 > > > Number of fragments 2 > > > Number of symbolic links 0 > > > Number of device nodes 0 > > > Number of fifo nodes 0 > > > Number of socket nodes 0 > > > Number of directories 20 > > > Number of ids (unique uids + gids) 1 > > > Number of uids 1 > > > luca (1000) > > > Number of gids 1 > > > luca (1000) > > > $ mksquashfs stackupper/ stackupper.raw > > > Parallel mksquashfs: Using 4 processors > > > Creating 4.0 filesystem on stackupper.raw, block size 131072. > > > [== > > > ===|] 3/3 100% > > > > > > Exportable Squashfs 4.0 filesystem, gzip compressed, data block > > > size 131072 > > > compressed data, compressed metadata, compressed fragments, > > > compressed xattrs, compressed ids > > > duplicates are removed > > > Filesystem size 33.94 Kbytes (0.03 Mbytes) > > > 41.81% of uncompressed filesystem size (81.18 Kbytes) > > > Inode table size 269 bytes (0.26 Kbytes) > > > 3
