Re: [systemd-devel] RebootWatchdogSec does not configure hardware watchdog timeout for reboots correctly

[Ray, Ian (GE Healthcare)]

On 11/09/2020, 03:29, "systemd-devel on behalf of Karim, Hafiz Abdul" 
 wrote:
> 
> After following this 
> https://www.freedesktop.org/software/systemd/man/systemd-system.conf.html I 
> tried to configure the hardware watchdog for reboots.
> 
> I made the following changes to systemd configurations. 
> # cat /etc/systemd/system.conf.d/99-watchdog.conf
> [Manager]
> RuntimeWatchdogSec=8s
> RebootWatchdogSec=10min
> 
> Even though I have set RebootWatchdogSec to 10min, but after the reboot fails 
> and system is halted, Timeout occurs in around 2 minutes
> and system restarts. 
> 
> Is this expected? if no, how can I fix this. 
> 

From the above link: "Not all hardware watchdogs allow configuration of all 
possible reboot timeout values, in which case the closest available timeout is 
picked."

Does your hardware watchdog have a maximum timeout of 128s?


> Thanks
> 
> Regards,
> Hafiz Abdul Karim, 
> Senior Software Development Engineer | Mentor Embedded Linux
> Mentor, A Siemens Business
> 6th Floor Ali Tower M. M. Alam Road Gulberg III Lahore Pakistan, 54660
> 
> hafizabdul_ka...@mentor.com   | office: 
> +92-42-3609-9202 | cell: +92-334-5099746
> 



___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] EXT: sdbus_event loop state mark as volatile?

[Ray, Ian (GE Healthcare)]

> On 5 Sep 2019, at 20.46, Stephen Hemminger  wrote:
> 
> The libsystemd bus event loop is:
> 
> 
>while (e->state != SD_EVENT_FINISHED) {
>r = sd_event_run(e, (uint64_t) -1);
> 
> But since e->state is changed by another thread it

What other thread?


> should be marked volatile to avoid compiler thinking
> the state doesn't get changed.
> 

The “volatile” keyword does not equate to thread safety.

If thread-safety is a design goal (and I don’t believe that it is [1])
then atomic or thread-safe primitives should be used.

[1] https://lists.freedesktop.org/archives/systemd-devel/2017-March/038519.html


While “volatile” _is_ a useful hint to the compiler, it provides *no*
atomic or thread-safe guarantees: for example about the ordering and
visibility of operations in a multi-core system.

It is true that for _certain_ { chipset, compiler, compiler-option }
combinations we can effectively reason about atomicity [for example
of word-size integers], however this does not generalise, and is
certainly not portable.

Ian


> 
> diff --git a/src/libsystemd/sd-event/sd-event.c 
> b/src/libsystemd/sd-event/sd-event.c
> index 5adbceeb0247..b7be2472a398 100644
> --- a/src/libsystemd/sd-event/sd-event.c
> +++ b/src/libsystemd/sd-event/sd-event.c
> @@ -90,7 +90,7 @@ struct sd_event {
> 
> uint64_t iteration;
> triple_timestamp timestamp;
> -int state;
> +volatile int state;
> 
> bool exit_requested:1;
> bool need_process_child:1;
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] EXT: looking for help to resolve shutdown problem

[Ray, Ian (GE Healthcare)]

> On 4 Apr 2019, at 10.16, Harald Dunkel  wrote:
> 
> Hi folks,
> 
> I am looking for help how to track down a delay of 90 secs at
> shutdown time. I suspect that there is a problem with umounting
> the /home directory tree (mounted via NFS).
> 
> Apparently it comes up after journal has been stopped, so I
> tried the procedure described on
> 
>   https://freedesktop.org/wiki/Software/systemd/Debugging/
> 
> The promised /shutdown-log.txt file was not created (or I was too
> blind to see).
> 
> 
> Every helpful hint is highly appreciated.

Use a serial console + kernel command line "printk.devkmsg=on".

At shutdown you will then be able to see logs as systemd-shutdown
progresses.

(An alternative is to run `dmesg -n 8` before shutting down -- but
note that the kernel may rate-limit the output.)

Good luck!

Ian


> 
> Harri
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] EXT: Re: Returning a struct from an sd-bus method

[Ray, Ian (GE Healthcare)]

> On 23 Aug 2018, at 20.05, Niall Murphy  wrote:
> 
> Hi, thanks! You are correct about the signature, I was trying various things 
> and pasted in some half complete code, sorry. After changing to pass the 
> fields of the struct as individual parameters it does work correctly. 
> 
> I guess I would prefer to pass the struct so that you can share a single 
> definition of the struct with both the client and service so as to avoid 
> possible errors where you pass the fields in the wrong order. Also if you 
> have a large struct it's a bit inconvenient to spell out every field on both 
> ends. 
> 
> I thought it would be possible for sd-bus to marshall my C struct into a 
> D-bus struct. Perhaps that is not possible? 
> 

Hi!

That would require some form of reflection (in order to know the contents
of an arbitrary struct at run-time) or meta-programming (to generate both
the C code that defines the structure, and the sd-bus code for performing
the marshalling).


> Niall
> 
> On Thu, 23 Aug 2018 at 18:35, Simon McVittie  wrote:
> On Thu, 23 Aug 2018 at 16:52:38 +0200, Niall Murphy wrote:
> > struct pack {
> > int x;
> > int y;
> > };
> ...
> > return sd_bus_reply_method_return(m, "(xx)", s);
> 
> Is there a reason why you're returning a struct/tuple? D-Bus methods
> can return as many things as you want[1], unlike C functions, so a more
> conventional return type would be "xx" instead of "(xx)".
> 
> You also have a mismatch between your integer types: "x" is a 64-bit signed
> integer (mnemonic: the 64-bit signed and unsigned types are "x" and "t",
> which are the first letters of "sixty" that weren't already used for
> something more important) so they'll expect an int64_t. The type
> signatures for 32-bit integers are "i" and "u", depending on signedness.
> There is no correct type signature for types like int/long/long long
> whose size can vary between platform: integers in D-Bus messages are
> always fixed-size.
> 
> Finally, I think the message-building API expects struct members as
> individual arguments, like
> 
> sd_bus_reply_method_return(m, "xx", (int64_t) s->x, (int64_t) s->y);
> 
> although I could be wrong about that.
> 
> smcv
> 
> [1] up to arbitrary message size limits measured in megabytes
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] EXT: Re: Triggering the HW Watchdog

[Ray, Ian (GE Healthcare)]

> On 27 Feb 2018, at 16.12, D.S. Ljungmark  wrote:
> 
> ( re-send as I forgot the list )
> 
> On 27/02/18 13:20, Lennart Poettering wrote:> On Di, 27.02.18 12:44,
> D.S. Ljungmark (ljungm...@modio.se) wrote:
>> 
>>> Hi list!
>>> 
>>> We're using systemd to control the hardware watchdog, and would want to
>>> induce fail state to _verify_ that the shutdown/reboot process works as
>>> expected.
>>> 
>>> How do we make systemd "fail" to ping the watchdog?
>> 
>> I figure you can send SIGSTOP to PID 1, no? (there are some signals
>> the kernel blocks for PID 1, but I think SIGSTOP is not among them,
>> please try)
> 
> It seems that SIGSTOP is being filtered, because nothing appears to
> happen, and the system certainly isn't rebooting.
> 

This works for me: `gdb --pid 1'.


> 
>>> How do we control which states ( root fs not available, etc) cause
>>> systemd to not ping the hardware watchdog?
>> 
>> The watchdog is for detecting software hanging. Root fs not being
>> available does not really qualify as "software hanging". If you want
>> to reboot the machine if it fails to bring everything up, then use
>> JobTimeoutAction= on some suitable action, for example local-fs.target
>> or multi-user.target.
>> 
>> Lennart
> Thanks,
>  I'm trying to get to a state where the machine fails over and triggers
> watchdog on known things, rather than triggering the rescue shell or
> similar.
> 
> 
> I'll try with a jobtimeout on multi-user.
> 
> //D.S.
> 
> 
> -- 
> 8362 CB14 98AD 11EF CEB6  FA81 FCC3 7674 449E 3CFC
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel