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