Re: [systemd-devel] shutdown on service unit timeout?
On Mo, 19.08.19 08:54, Chris Murphy (li...@colorremedies.com) wrote: > Hi, > > Is it possible for a systemd service file to ask for a poweroff upon > service timeout? If not, could it be done; or suggest an alternative? > > Here's the use case: > > No Screensaver/Powerdown after Inactivity at LUKS Password Prompt > https://bugzilla.redhat.com/show_bug.cgi?id=1742953 > > The summary is: plymouth waits indefinitely with a prompt for a > passphrase, leads to excessive power consumption including battery if > it's a laptop (it'll wait until the battery dies), and screen burn in. > This can happen unattended if e.g. Fedora is the default boot, but the > user dual boots Windows which has a tendency to wake up, do updates at > "offline" times, and reboots... to Fedora where it waits indefinitely > for a LUKS passphrase. > > I'm sure there are other examples. Plausibly anything that hangs > during startup would have this behavior; only once we're at gdm (or > equivalent on other DE's) is there a timer that will at least blank > the screen, and possibly also optionally trigger suspend to RAM. > > Or alternative to a service unit opt in method, a way for systemd > itself to opt into a "power off after X minutes unless Y process > reports it's started successfully" type of behavior. In any case, it's > up to the distro to decide the policy, with a way for the user to opt > out of that by setting the applicable timeout value to something like > 0, to indicate they really want an indefinite wait. So, we have some logic for something like that (JobRunningTimeoutSec=, JobTimeoutSec=, JobTimeoutAction=) and so on. But I am not convinced we really should use that here... The thing is: you can pull in LUKS devices any time, including during run time long after boot-up (think: a backup disk is mounted right before the backup script runs). A shutdown-on-timeout logic should hence only be used during the early boot phase, but when this happens while the system is up we should not. Thus I figure systemd-cryptsetup should probably have code for this natively, maybe inspired what systemd-fsck does, since it needs to be a tiny bit mor intelligent. Happy to review a PR about this! ;-) Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] shutdown on service unit timeout?
Hi, Is it possible for a systemd service file to ask for a poweroff upon service timeout? If not, could it be done; or suggest an alternative? Here's the use case: No Screensaver/Powerdown after Inactivity at LUKS Password Prompt https://bugzilla.redhat.com/show_bug.cgi?id=1742953 The summary is: plymouth waits indefinitely with a prompt for a passphrase, leads to excessive power consumption including battery if it's a laptop (it'll wait until the battery dies), and screen burn in. This can happen unattended if e.g. Fedora is the default boot, but the user dual boots Windows which has a tendency to wake up, do updates at "offline" times, and reboots... to Fedora where it waits indefinitely for a LUKS passphrase. I'm sure there are other examples. Plausibly anything that hangs during startup would have this behavior; only once we're at gdm (or equivalent on other DE's) is there a timer that will at least blank the screen, and possibly also optionally trigger suspend to RAM. Or alternative to a service unit opt in method, a way for systemd itself to opt into a "power off after X minutes unless Y process reports it's started successfully" type of behavior. In any case, it's up to the distro to decide the policy, with a way for the user to opt out of that by setting the applicable timeout value to something like 0, to indicate they really want an indefinite wait. Thanks, -- Chris Murphy ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] MACVLAN= in .nspawn file vs command line results in /sys/class/net showing host interfaces
I'm running Ubuntu bionic, with systemd 237, so I haven't filed a bug report, but I'm wondering if it rings any bells with anyone.. I've tried searching github issues, but my keywords either get too few or too many results to be useful. I have machine with the following nspawn file: -- [Network] MACVLAN=laneth0 [Exec] PrivateUsers=false -- if I start it with systemctl start systemd-nspawn@name, all works as expected. If I start manually with systemd-nspawn -M name -b, I seem to correctly get a new network namespace (ip link output in container is correct), but ls /sys/class/net shows the host's interfaces. The difference turns out to be that starting with systemctl uses a default command line which includes --private-network; the MACVLAN= in the config file should imply this, but instead it seems I'm getting "half" a private network, with the namespace correctly set but /sys not. Having a quick poke around, I suspect https://github.com/systemd/systemd/commit/60f1ec13ed059e412c2a2ee4cc3093e2d520673c may have 'accidentally' fixed this - it moves if (arg_private_network) arg_mount_settings |= MOUNT_APPLY_APIVFS_NETNS; from parse_argv to verify_arguments which is called later - does that sound like a correct interpretation? This bug causes netplan to fail on Ubuntu as it rummages around in /sys/class/net .. S. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Deferring start of service until file exists
Hi, (Hoping this is an appropriate place to ask this question...) During system start-up, I want to defer starting a unit (a service) until a particular file is written (amongst other dependencies). In my case I am writing the service's configuration file within a dhclient hook script. Any guidance on achieving this with systemd would be much appreciated. I don't think a .path unit is the appropriate tool for the job, since AIUI that is intended to start a new systemd transaction rather than for scheduling within an existing transaction. I tried having my service depend on (via Requires/After) the foo.unit related to foo.path, but then systemd starts foo.unit straight away regardless of foo.path. If I have After=foo.unit and Requires=foo.path, then it seems like foo.unit is not "pulled in", and the After has no effect. But maybe I missed something. The .path causes its related unit to start, whereas I think I want to provoke a transition in a unit from startING to startED - am I right? I thought of using the 'inotify' executable within a unit upon which my service could depend. Unfortunately, CentOS (& Redhat) in their wisdom decided not to package inotify-tools. Thanks for any help, -- Colin Hogben ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Fwd: nspawn blocks sync_file_range on arm
[apologies for off-list dupe, I hate gmail...] On Mon, 19 Aug 2019 at 07:56, Zbigniew Jędrzejewski-Szmek wrote: Please test https://github.com/systemd/systemd/pull/13352. > I backported to my distro's stable version and it solves the problem: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1840640 Thanks! S. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] nspawn blocks sync_file_range on arm
On Sun, Aug 18, 2019 at 05:02:35PM +0100, Steve Dodd wrote:
> ARM has two sync_file_range syscalls, sync_file_range and sync_file_range2.
> The former is apparently not used, and glibc calls the latter whenever a
> userspace program calls sync_file_range. I'm guessing systemd-nspawn
> doesn't know this, because the follow code consistently fails in an nspawn
> container on ARM:
>
> #define _GNU_SOURCE
> #include
> #include
> #include
> #include
>
> void main()
> {
> int f = open("/tmp/syncrange.test",O_CREAT|O_RDWR,0666);
> int r=sync_file_range(f, 0, 0, 0);
> if (r)
> perror("sync_file_range");
> close(f);
> }
>
> This seems to be causing problems specifically for borg(backup) and
> postgres:
> https://github.com/borgbackup/borg/issues/4710
> https://www.postgresql.org/message-id/flat/CA%2BhUKG%2BydOUT4zjxb6QmJWy8U9WbC-q%2BJWV7wLsEY9Df%3Dmw0Mw%40mail.gmail.com#ac8f14897647dc7eae3c7e7cbed36d93
>
> I will test the obvious fix when I can, unless someone beats me to it :)
Please test https://github.com/systemd/systemd/pull/13352.
Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
