Re: [systemd-devel] alternative approach to waiting for system time to be set

On 03/19/2018 04:17 PM, Lennart Poettering wrote: On So, 18.03.18 20:45, Peter A. Bigot (p...@pabigot.com) wrote: Like others I'd like to use systemd to defer starting a service until the system time has been set accurately.  Previous approaches to resolving issue #5097 don't seem to be going

Re: [systemd-devel] How do I create/destroy instances dynamically when config files appear/disappear?

On Mon, Mar 19, 2018 at 5:52 PM, John Ioannidis wrote: > I want to have a service with several instances, each of which has a > configuration file; when configuration files appear and disappear, I want > the corresponding instances to be created and started, and die, >

[systemd-devel] How do I create/destroy instances dynamically when config files appear/disappear?

I want to have a service with several instances, each of which has a configuration file; when configuration files appear and disappear, I want the corresponding instances to be created and started, and die, respectively, and in particular have the running processes corresponding to the removed

Re: [systemd-devel] alternative approach to waiting for system time to be set

On So, 18.03.18 20:45, Peter A. Bigot (p...@pabigot.com) wrote: > Like others I'd like to use systemd to defer starting a service until the > system time has been set accurately.  Previous approaches to resolving issue > #5097 don't seem to be going anywhere. > >

Re: [systemd-devel] 2017: systemd-readahead?

On Tue, Feb 7, 2017 at 2:38 AM, Che wrote: > >> However, I finally ditched it. I figured it will slow down boot of an >> aging system. Instead, I added bcache to my spinning rust plus an >> affordable SSD. This works very well and reduces boot times much better >>

[systemd-devel] Robust getpid caching via MADV_WIPEONFORK?

[Bcced to other potentially interested folks.] As discussed in various places, glibc removed the getpid() cache in 2.25, since it was not robust against all possible ways to fork a process. Linux 4.14 added MADV_WIPEONFORK, which robustly ensures that a page gets wiped to zero on any possible

Re: [systemd-devel] Timeout for dev-ttyS0.device in Angstrom 2017.06 Yocto-2.3

On Di, 13.03.18 03:35, Ong, Hean Loong (hean.loong@intel.com) wrote: > Hi, > > I have been faced with intermittent issues with regards to the > dev-ttyS0.device timing out upon boot up Is this on a current systemd and kernel? If not, please upgrade to something more current before trying to

Re: [systemd-devel] Xorg is continuously crashing and dumping core, this is the stack trace from journalctl -p 3 -xb

On Sa, 10.03.18 22:23, Dude And (dudeand2...@gmail.com) wrote: > Process 737 (Xorg) of user 0 dumped core. > >Stack trace of thread 791: >#0 0x7f03fe9d1860 raise (libc.so.6) >#1 0x7f03fe9d2ec9 abort (libc.so.6) >#2

Re: [systemd-devel] 2017: systemd-readahead?

> > > However, I finally ditched it. I figured it will slow down boot of an > aging system. Instead, I added bcache to my spinning rust plus an > affordable SSD. This works very well and reduces boot times much better > than readahead (by a factor of at least 5). Perhaps such a feature is more

[systemd-devel] start service in multi-user.target but don't stop it on isolate

Hi! I am using the software watchdog daemon together with a watchdog device in "nowayout" mode. Thus once started, the watchdog daemon should never be stopped or the box will be rebooted. watchdog.service is WantedBy multi-user.target and when changing e.g. to rescue.target, it should stay

Re: [systemd-devel] How to debug why a unit is started when?

-4.16.0-rc5+ ``` Kind regards, Paul [1] https://gitlab.gnome.org/GNOME/gnome-shell/issues/126 20180319–bootchart-201080319-1014.svg.7z Description: application/7z-compressed ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https

Re: [systemd-devel] ShutdownWatchdogSec does not work as described

On Mon, Mar 19, 2018 at 11:41:33AM +0530, prashantkumar dhotre wrote: > I am observing that ShutdownWatchdogSec setting in system.conf > > In man page, for ShutdownWatchdogSec, I see : > " It works as a safety net to ensure that the reboot takes place even if a > clean reboot attempt

Re: [systemd-devel] alternative approach to waiting for system time to be set

Maybe start a github pull-request ? things seems to be less forgotten that way. since your code already exist, creating a first PR should not be too much work... On 19/03/2018 02:45, Peter A. Bigot wrote: Like others I'd like to use systemd to defer starting a service until the system time

Re: [systemd-devel] ShutdownWatchdogSec does not work as described

I see another issue also wrt hardware watchdog reboot-force seem to be overwriting the hardware watchdog timeout value. I have changed reboot.target to make JobTimeoutSec=5sec when system boots up i see that hardware watchdog is set to 1 min 4 sec. but when 'systemctl reboot' timesout ,

Re: [systemd-devel] How to debug why a unit is started when?

Paul Menzel wrote on 17/03/18 17:50: > Dear Andrei, > > > On 03/16/2018 05:04 PM, Andrei Borzenkov wrote: >> 16.03.2018 18:49, Paul Menzel пишет: > >>> I am trying to get the GDM login screen started earlier on a Dell XPS 13 >>> 9370 with Debian Sid/unstable system with systemd 238. Currently,

[systemd-devel] ShutdownWatchdogSec does not work as described

Hi I am observing that ShutdownWatchdogSec setting in system.conf In man page, for ShutdownWatchdogSec, I see : " It works as a safety net to ensure that the reboot takes place even if a clean reboot attempt times out. " I am not clear what is meant by 'clean reboot' and 'times out ' here