<meta http-equiv="Content-Type" content="text/html; charset=GB18030"><div><div>Hi All,</div><div><br></div><div>Could you help with the question below? </div><div>Does sd_dbus support non-blocking or multi-thread?</div><div><br></div><div>I created a dbus program, and when usleep(60000*1000) is called, the program will block for 60s.</div><div>During the 60s-blocking state, the external sd_bus_call the dbus will time out. Even if I use pthred creating a thread to call usleep(60000*1000), this problem still exists.</div><div><br></div><div>It seems that sd_bus is tied to the process, and when the process is blocked, dbus will be blocked, and it does not support multithreading, right?</div><div><br></div><div>Is there any way to solve this problem?</div><div><br></div><div>this is my code:</div><div>sdbusplus::bus::bus _bus;</div><div>_bus.request_name(busname.c_str());</div><div>std::function<void()> callback(std::bind(&SENSORS::read, this)); //Timer, call usleep(60000*1000) regularly</div><div>_bus.attach_event(_event.get(), SD_EVENT_PRIORITY_IMPORTANT);</div><div>_event.loop();</div><div>(sdbusplus is a c++ dbus library that encapsulates sd_dbus)</div><div><br></div><div><br></div><div>Thank you guys!</div></div><div>Frank</div><div><div><br></div><div><br></div><div style="font-size: 12px;font-family: Arial Narrow;padding:2px 0 2px 0;">------------------ Original ------------------</div><div style="font-size: 12px;background:#efefef;padding:8px;"><div><b>From:</b>                                                                                                                        "systemd-devel"                                                                                    <systemd-devel-request@lists.freedesktop.org>;</div><div><b>Date:</b> Tue, Sep 8, 2020 11:36 PM</div><div><b>To:</b> "systemd-devel"<systemd-devel@lists.freedesktop.org>;<wbr></div><div></div><div><b>Subject:</b> systemd-devel Digest, Vol 125, Issue 21</div></div><div><br></div>Send systemd-devel mailing list submissions to<br>     systemd-devel@lists.freedesktop.org<br><br>To subscribe or unsubscribe via the World Wide Web, visit<br>      https://lists.freedesktop.org/mailman/listinfo/systemd-devel<br>or, via email, send a message with subject or body 'help' to<br>    systemd-devel-request@lists.freedesktop.org<br><br>You can reach the person managing the list at<br>  systemd-devel-owner@lists.freedesktop.org<br><br>When replying, please edit your Subject line so it is more specific<br>than "Re: Contents of systemd-devel digest..."<br><br><br>Today's Topics:<br><br>   1. Re:  [EXT] Initialization of "vbuf" in function<br>      "token_match_attr" (Josef M?llers)<br>   2. Re:  Journal message timestamps (Dave Howorth)<br>   3. Re:  socket: Failed to queue service startup job: Transport<br>      endpoint is not connected (Lennart Poettering)<br>   4. Re:  Q: Start a unit n minutes after a successful boot<br>      (Lennart Poettering)<br>   5. Re:  Antw: [EXT] Re: Q: Start a unit n minutes after a<br>      successful boot (Lennart Poettering)<br>   6. Re:  Why systemd keeps references on passed sockets ?<br>      (Francis Moreau)<br><br><br>----------------------------------------------------------------------<br><br>Message: 1<br>Date: Tue, 8 Sep 2020 16:13:10 +0200<br>From: Josef M?llers <josef.moellers@suse.com><br>To: systemd-devel@lists.freedesktop.org<br>Subject: Re: [systemd-devel] [EXT] Initialization of "vbuf" in<br>  function "token_match_attr"<br>Message-ID: <a29e4ace-8c58-45e6-8d8f-4a99b8e86d30@suse.com><br>Content-Type: text/plain; charset="utf-8"<br><br>On 08.09.20 16:03, Amit anand wrote:<br>> Hi,<br>><br>> On Tue, Sep 8, 2020 at 6:23 PM Ulrich Windl<br>> <Ulrich.Windl@rz.uni-regensburg.de<br>> <mailto:Ulrich.Windl@rz.uni-regensburg.de>> wrote:<br>><br>>     Hi!<br>><br>>     vbuf is initialized: It has some address on the stack, so "if<br>>     (value != vbuf)" is comparing adresses, if I got it right...<br>><br>> vbuf having some address on stack and "if(value!=vbuf)" is comparing<br>> addresses doesn't necessarily implies that vbuf is initialized.<br>> I am still not clear about where vbuf is initialized.<br><br>It is initialized with the strscpy() call.<br><br>The comparison just compares the pointer in *value (+) with the ADDRESS<br>of "vbuf"!<br><br>(+) Please ignore my previous remark. I don't know what I had been<br>smoking at that time!<br><br>So if "value" does not point at "vbuf", it points at some other buffer,<br>but the data in that buffer should be in "vbuf", so the contents of the<br>buffer "value" points at is copied into the buffer named "vbuf"!<br><br>If "value" points at "vbuf", the call to "sd_device_get_sysattr_value"<br>would have? already put the data into "vbuf" and thus the strscpy()<br>would not be needed, as it would copy "vbuf" into itself.<br><br>HTH,<br><br>Josef<br><br>> Also, expecting some information regarding my queries in below mail.<br>><br>> Thanks,<br>> Amit<br>><br>><br>>     >>> Amit anand <amit.table@gmail.com<br>>     <mailto:amit.table@gmail.com>> schrieb am 08.09.2020 um 13:56 in<br>>     Nachricht<br>>     <CAMkFpM5NFmN+pc_cztmMZW=j1vn2RYC16AgJ3LYL6RSgdqP1eA@mail.gmail.com<br>>     <mailto:j1vn2RYC16AgJ3LYL6RSgdqP1eA@mail.gmail.com>>:<br>>     > Hi systemd-devel team,<br>>     ><br>>     > I am trying to understand where "vbuf" is initialized in function<br>>     > "token_match_attr()" in file udev-rules.c<br>>     ><br>>     > Below code snippet :<br>>     > static bool* token_match_attr*(UdevRuleToken *token, sd_device *dev,<br>>     > UdevEvent *event) {<br>>     >? *char* nbuf[UTIL_NAME_SIZE], *vbuf*[UTIL_NAME_SIZE];? ? ?//<br>>     Here, vbuf is<br>>     > defined, however not initialized.<br>>     > *const char* *name, **value;? ? ? ? *// Here, value is declared<br>>     to be of<br>>     > type const char *, however, not initialized.<br>>     > ...<br>>     > ... // some code<br>>     > ...<br>>     > switch (token->attr_subst_type) {? ?// *Event 1* : This evaluates to<br>>     > SUBST_TYPE_PLAIN<br>>     > ...<br>>     > case *SUBST_TYPE_PLAIN*:? ?if (sd_device_get_sysattr_value(dev,<br>>     name,<br>>     > &value) < 0)? ?// *Event 2* :The if condition evaluates to false.<br>>     >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? return false;<br>>     >? break;<br>>     > ...// some code<br>>     > ...<br>>     > }<br>>     ><br>>     >? ? ? ? ?if (token->attr_match_remove_trailing_whitespace) {? ? ?<br>>     // *Event<br>>     > 4*: If condition evaluates to true<br>>     >? ? ? ? ? ? ? ? ?if (value != vbuf) {? ? ? //? *Event 5* : vbuf<br>>     and value<br>>     > are both declared but not initialized. Comparison is done without<br>>     > initializing "vbuf" and "value".<br>>     >? ? ? ? ? ? ? ? ? ? ? ? ?strscpy(vbuf, sizeof(vbuf), value);<br>>     >? ? ? ? ? ? ? ? ? ? ? ? ?value = vbuf;<br>>     >? ? ? ? ? ? ? ? ?} // End of if.<br>>     ><br>>     >? ? ? ? ? ? ? ? ?delete_trailing_chars(vbuf, NULL);? ? ? ? ?//<br>>     *Event 6*:<br>>     > trying to delete trailing chars from "vbuf" which is not<br>>     initialzed. ??<br>>     >? ? ? ? ?} // End of outer if.<br>>     > ... // some code<br>>     > } /End of function : *token_match_attr()*<br>>     ><br>>     > Below are my queries :<br>>     > 1. *Event 5 *above, we are comparing two resources ("value" and<br>>     "vbuf")<br>>     > even before initializing them.<br>>     >? ? ?Are we doing this comparision to do decision making based on<br>>     whether<br>>     > the pointer type variable "value" is pointing to "vbuf" or not.<br>>     > *Query*: Kindly confirm whether my understanding is correct.<br>>     ><br>>     > 2. *Event 6* above, delete_trailing_chars(vbuf, NULL) is called<br>>     outside? *if<br>>     > (value != vbuf).*<br>>     >? ? ?This implies there may occur a situation where:<br>>     >? ? ? ? ? ? ? ?step 1 ) *if (value != vbuf) *condition fails? --><br>>     step 2 )<br>>     > *vbuf* is not initialzed inside the *if(value != vbuf)? *--><br>>     step 3 )<br>>     > delete_trailing_chars(*vbuf*, NULL).<br>>     > Here, delete_trailing_chars() called for "*vbuf*" which is not<br>>     necessarily<br>>     > initiazlied.<br>>     > *Query*: Kindly let me know if my understanding is correct or I<br>>     am missing<br>>     > something.<br>>     ><br>>     > Thanks,<br>>     > Amit<br>><br>><br>><br>><br>><br>> _______________________________________________<br>> systemd-devel mailing list<br>> systemd-devel@lists.freedesktop.org<br>> https://lists.freedesktop.org/mailman/listinfo/systemd-devel<br><br><br>-------------- next part --------------<br>An HTML attachment was scrubbed...<br>URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20200908/9308c3da/attachment-0001.htm><br><br>------------------------------<br><br>Message: 2<br>Date: Tue, 8 Sep 2020 15:13:22 +0100<br>From: Dave Howorth <systemd@howorth.org.uk><br>To: systemd-devel@lists.freedesktop.org<br>Subject: Re: [systemd-devel] Journal message timestamps<br>Message-ID: <20200908151322.14ca0e23@acer-suse.lan><br>Content-Type: text/plain; charset=US-ASCII<br><br>On Tue, 8 Sep 2020 07:18:15 -0400<br>"Kevin P. Fleming" <kevin@km6g.us> wrote:<br>> On Tue, Sep 8, 2020 at 7:12 AM Reindl Harald <h.reindl@thelounge.net><br>> wrote:<br>> <br>> > your playground is in<br>> > /etc/systemd/system/fake-hwclock.service.d/myoverrides.conf<br>> ><br>> > and yes that is important so that you don#t have to redo your<br>> > changes after each and every update and way better than cloning the<br>> > whole unit-file in /etc/systemd/system/ so that reasonable upstream<br>> > changes get applied in teh future<br>> ><br>> > -------------------------<br>> ><br>> > /etc/systemd/system/fake-hwclock.service.d/myoverrides.conf:<br>> ><br>> > [Unit]<br>> > Before=systemd-journald.service  <br>> <br>> ... and this is most easily done by using 'systemctl edit<br>> fake-hwclock.service', which will create the file in the proper<br>> location so you don't have to (and will handily cause a daemon reload<br>> as well).<br><br>Hi Mark, Reindl, Kevin, et al,<br><br>I have added<br><br>[Unit]<br>Before=systemd-journald.service<br><br>to a drop-in file in /etc/systemd/system/fake-hwclock.service.d/ so<br>hopefully it will get tested next time the machines reboot (they're<br>production data loggers so I don't want to reboot unnecessarily).<br><br>I had appreciated it should be done via an override file but thanks for<br>the warning. I'd forgotten about the edit command so I had done it the<br>hard way :) I don't think a daemon reload is necessary in this case,<br>since it only affects matters on the next and subsequent boots anyway.<br><br><br>------------------------------<br><br>Message: 3<br>Date: Tue, 8 Sep 2020 16:19:25 +0200<br>From: Lennart Poettering <lennart@poettering.net><br>To: Alec Moskvin <alecm@gmx.com><br>Cc: systemd-devel@lists.freedesktop.org<br>Subject: Re: [systemd-devel] socket: Failed to queue service startup<br>        job: Transport endpoint is not connected<br>Message-ID: <20200908141925.GA272516@gardel-login><br>Content-Type: text/plain; charset=us-ascii<br><br>On Mo, 07.09.20 14:22, Alec Moskvin (alecm@gmx.com) wrote:<br><br>> A few days ago I tried to ssh into one of my boxes (which was using<br>> socket-activated per-connection ssh) but got connection refused. Luckily<br>> I had another ssh session open. In the journal, the only relevant thing<br>> logged was:<br>><br>>   systemd[1]: sshd.socket: Failed to queue service startup job (Maybe the service file is missing or not a template unit?): Transport endpoint is not connected<br>>   systemd[1]: sshd.socket: Failed with result 'resources'.<br>><br>> I started the socket back up and could connect again. The system had<br>> been mostly idle and there were no upgrades since it booted up 2 days<br>> earlier. The previous ssh login attempt was 4 hours before.<br><br>It's a bug. Should be fixed by 86e045ecefc404d4fccbeb78aa212ec4714a5763.<br><br>Lennart<br><br>--<br>Lennart Poettering, Berlin<br><br><br>------------------------------<br><br>Message: 4<br>Date: Tue, 8 Sep 2020 16:19:53 +0200<br>From: Lennart Poettering <lennart@poettering.net><br>To: Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de><br>Cc: "systemd-devel@lists.freedesktop.org"<br>      <systemd-devel@lists.freedesktop.org><br>Subject: Re: [systemd-devel] Q: Start a unit n minutes after a<br>   successful boot<br>Message-ID: <20200908141953.GB272516@gardel-login><br>Content-Type: text/plain; charset=us-ascii<br><br>On Di, 08.09.20 09:21, Ulrich Windl (Ulrich.Windl@rz.uni-regensburg.de) wrote:<br><br>> Hi!<br>><br>> Configuring a new system with non-redundant system disk I'm<br>> wondering: How could I start an automatic backup job that is<br>> triggered n minutes after the system started successfully (to avoid<br>> backing up broken configurations)?<br><br>What does "started successfully" mean to you?<br><br>Lennart<br><br>--<br>Lennart Poettering, Berlin<br><br><br>------------------------------<br><br>Message: 5<br>Date: Tue, 8 Sep 2020 16:22:26 +0200<br>From: Lennart Poettering <lennart@poettering.net><br>To: Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de><br>Cc: "systemd-devel@lists.freedesktop.org"<br>   <systemd-devel@lists.freedesktop.org>, tomek@pipebreaker.pl<br>Subject: Re: [systemd-devel] Antw: [EXT] Re: Q: Start a unit n minutes<br>     after a successful boot<br>Message-ID: <20200908142226.GC272516@gardel-login><br>Content-Type: text/plain; charset=utf-8<br><br>On Di, 08.09.20 11:01, Ulrich Windl (Ulrich.Windl@rz.uni-regensburg.de) wrote:<br><br>> >> Configuring a new system with non?redundant system disk I'm wondering:<br>> >> How could I start an automatic backup job that is triggered n minutes<br>> >> after the system started successfully (to avoid backing up broken<br>> >> configurations)?<br>> ><br>> >   Timer with "OnBootSec=n minutes" is exactly what you want, right?<br>><br>> Hi!<br>><br>> Is every boot a successful boot? Will (e.g.) default.target be reached even if<br>> some service failed? If not, that is what I had in mind:<br>> Start a unit n minutes after default.target was reached<br>> "sucessfully".<br><br>Define a timer unit like this if you want to make this dependent on<br>"default.target" having been reached.<br><br>    [Unit]<br>    Requisite=default.target<br>    After=default.target<br><br>    [Timer]<br>    OnActiveSec=2min<br><br>    [Install]<br>    WantedBy=timers.target<br><br>This will enqueue the timer during early boot, but not actually<br>activate it until default.target has been reached. Then once active,<br>after 2mn the associated service is triggered.<br><br>Lennart<br><br>--<br>Lennart Poettering, Berlin<br><br><br>------------------------------<br><br>Message: 6<br>Date: Tue, 8 Sep 2020 17:35:53 +0200<br>From: Francis Moreau <francis.moro@gmail.com><br>To: Lennart Poettering <lennart@poettering.net><br>Cc: SystemD Devel <systemd-devel@lists.freedesktop.org><br>Subject: Re: [systemd-devel] Why systemd keeps references on passed<br>        sockets ?<br>Message-ID:<br>        <CAC9WiBgLoc2_PqXu2Qkt0TuNfyN5dCYJkurXGTPGVznpQQHeGw@mail.gmail.com><br>Content-Type: text/plain; charset="UTF-8"<br><br>On Mon, Sep 7, 2020 at 4:38 PM Lennart Poettering<br><lennart@poettering.net> wrote:<br>><br>> "React on the socket close?" ? What do you mean by that?<br>><br><br>I mean if my service explicitly calls close() then systemd could stop<br>the socket on its side so its are freed until the service is<br>restarted. I think it is what you described below.<br><br>> Note that on Linux you can invoke shutdown() on a listening socket<br>> (i.e. not just on the connection socket, but on a listening<br>> socket). iirc in that case systemd actually notices and will put the<br>> .socket unit in failure mode...<br>><br><br>I looked at the code and there is:<br><br>    if (state != SOCKET_LISTENING)<br>        socket_unwatch_fds(s);<br><br>So I'm not sure how systemd can react on shutdown(). And I tried to<br>call shutdown() in my service but it has no effects.<br><br>> Would that work for you? (Maybe we could even tweak this a bit in<br>> systemd, so that when you invoke shutdown() on the socket systemd<br>> holds for you we do not consider that a failure anymore, but a clean<br>> way to tell systemd to stop the socket).<br><br>That is a good idea especially if systemd doesn't consider an error<br>when the service closes or shutdown the socket.<br><br>But again in the code I can see:<br><br>  sd_event_add_io(UNIT(s)->manager->event, &p->event_source, p->fd,<br>EPOLLIN, socket_dispatch_io, p);<br><br>It seems that it only listens to "EPOLLIN" events. So it doesn't<br>listen to "EPOLLUP".<br><br>Thank you.<br>-- <br>Francis<br><br><br>------------------------------<br><br>Subject: Digest Footer<br><br>_______________________________________________<br>systemd-devel mailing list<br>systemd-devel@lists.freedesktop.org<br>https://lists.freedesktop.org/mailman/listinfo/systemd-devel<br><br><br>------------------------------<br><br>End of systemd-devel Digest, Vol 125, Issue 21<br>**********************************************<br></div>