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-requ...@lists.freedesktop.org>;
Date: Tue, Sep 8, 2020 11:36 PM
To: "systemd-devel"<systemd-devel@lists.freedesktop.org>;
Subject: systemd-devel Digest, Vol 125, Issue 21
Send systemd-devel mailing list submissions to
systemd-devel@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-requ...@lists.freedesktop.org
You can reach the person managing the list at
systemd-devel-ow...@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.moell...@suse.com>
To: systemd-devel@lists.freedesktop.org
Subject: Re: [systemd-devel] [EXT] Initialization of "vbuf" in
function "token_match_attr"
Message-ID: <a29e4ace-8c58-45e6-8d8f-4a99b8e86...@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.wi...@rz.uni-regensburg.de
> <mailto:ulrich.wi...@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.ta...@gmail.com
> <mailto:amit.ta...@gmail.com>> schrieb am
08.09.2020 um 13:56 in
> Nachricht
>
<CAMkFpM5NFmN+pc_cztmMZW=j1vn2ryc16agj3lyl6rsgdqp...@mail.gmail.com
>
<mailto:j1vn2ryc16agj3lyl6rsgdqp...@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@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 <syst...@howorth.org.uk>
To: systemd-devel@lists.freedesktop.org
Subject: Re: [systemd-devel] Journal message timestamps
Message-ID: <20200908151322.14ca0...@acer-suse.lan>
Content-Type: text/plain; charset=US-ASCII
On Tue, 8 Sep 2020 07:18:15 -0400
"Kevin P. Fleming" <ke...@km6g.us> wrote:
> On Tue, Sep 8, 2020 at 7:12 AM Reindl Harald <h.rei...@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 <lenn...@poettering.net>
To: Alec Moskvin <al...@gmx.com>
Cc: systemd-devel@lists.freedesktop.org
Subject: Re: [systemd-devel] socket: Failed to queue service startup
job: Transport endpoint is not connected
Message-ID: <20200908141925.GA272516@gardel-login>
Content-Type: text/plain; charset=us-ascii
On Mo, 07.09.20 14:22, Alec Moskvin (al...@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 <lenn...@poettering.net>
To: Ulrich Windl <ulrich.wi...@rz.uni-regensburg.de>
Cc: "systemd-devel@lists.freedesktop.org"
<systemd-devel@lists.freedesktop.org>
Subject: Re: [systemd-devel] Q: Start a unit n minutes after a
successful boot
Message-ID: <20200908141953.GB272516@gardel-login>
Content-Type: text/plain; charset=us-ascii
On Di, 08.09.20 09:21, Ulrich Windl (ulrich.wi...@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 <lenn...@poettering.net>
To: Ulrich Windl <ulrich.wi...@rz.uni-regensburg.de>
Cc: "systemd-devel@lists.freedesktop.org"
<systemd-devel@lists.freedesktop.org>, to...@pipebreaker.pl
Subject: Re: [systemd-devel] Antw: [EXT] Re: Q: Start a unit n minutes
after a successful boot
Message-ID: <20200908142226.GC272516@gardel-login>
Content-Type: text/plain; charset=utf-8
On Di, 08.09.20 11:01, Ulrich Windl (ulrich.wi...@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.m...@gmail.com>
To: Lennart Poettering <lenn...@poettering.net>
Cc: SystemD Devel <systemd-devel@lists.freedesktop.org>
Subject: Re: [systemd-devel] Why systemd keeps references on passed
sockets ?
Message-ID:
<cac9wibgloc2_pqxu2qkt0tunfyn5dcyjkurxgtpgvznpqqh...@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
On Mon, Sep 7, 2020 at 4:38 PM Lennart Poettering
<lenn...@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@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
------------------------------
End of systemd-devel Digest, Vol 125, Issue 21
**********************************************_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
