The builder has this convoluted `while` loop which just replicates
`readlink -e`. I'm sure there was a reason at one point, because the
loop has been there since time immemorial. It kept getting copied
around, I suspect because nobody bothered to understand what it actually
did.
Incidentally, this fixes#17513, but I have no idea why.
We currently only allow upstream's default of "reboot.target" due to the
way the symlinks are initialized. I made this configurable similar to the
default unit.
This reverts commit c69c76ca7e.
This patch was messed up during a rebase -- the commit title doesn't match what
it really does at all (it is actually a broken attempt to get LUKS passphrase
prompts in Plymouth).
A disabled systemd service with a "startAt" attribute, like this:
systemd.services.foo-service = {
enable = false;
startAt = "*-*-* 05:15:00";
...
};
will cause the following errors in the system journal:
systemd[1]: foo-service.timer: Refusing to start, unit to trigger not loaded.
systemd[1]: Failed to start foo-service.timer.
Fix it by not generating the corresponding timer unit when the service
is disabled.
Previously, the value from stdenv.platform.kernelDTB was used. That
doesn't work well if both kinds (DTB and non-DTB) of generations exist
in the system profile.
':' is currently used as separator in /boot/grub/state for the list of
devices GRUB should be installed to. The problem is that ':' itself may
appear in a device path:
/dev/disk/by-id/usb-SanDisk_Cruzer_20043512300546C0B317-0:0
With such a path, NixOS will install GRUB *every* time, because it
thinks the configuration differs from the state file (due to the wrong
list split). Fix it by using ',' as separator.
For existing systems with GRUB installed on multiple devices, this
change means that GRUB will be installed one extra time.
This allows setting options for the same LUKS device in different
modules. For example, the auto-generated hardware-configuration.nix
can contain
boot.initrd.luks.devices.crypted.device = "/dev/disk/...";
while configuration.nix can add
boot.initrd.luks.devices.crypted.allowDiscards = true;
Also updated the examples/docs to use /disk/disk/by-uuid instead of
/dev/sda, since we shouldn't promote the use of the latter.
Unfortunately, pkill doesn't distinguish between kernel and user space
processes, so we need to make sure we don't accidentally kill kernel
threads.
Normally, a kernel thread ignores all signals, but there are a few that
do. A quick grep on the kernel source tree (as of kernel 4.6.0) shows
the following source files which use allow_signal():
drivers/isdn/mISDN/l1oip_core.c
drivers/md/md.c
drivers/misc/mic/cosm/cosm_scif_server.c
drivers/misc/mic/cosm_client/cosm_scif_client.c
drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
drivers/staging/rtl8188eu/core/rtw_cmd.c
drivers/staging/rtl8712/rtl8712_cmd.c
drivers/target/iscsi/iscsi_target.c
drivers/target/iscsi/iscsi_target_login.c
drivers/target/iscsi/iscsi_target_nego.c
drivers/usb/atm/usbatm.c
drivers/usb/gadget/function/f_mass_storage.c
fs/jffs2/background.c
fs/lockd/clntlock.c
fs/lockd/svc.c
fs/nfs/nfs4state.c
fs/nfsd/nfssvc.c
While not all of these are necessarily kthreads and some functionality
may still be unimpeded, it's still quite harmful and can cause
unexpected side-effects, especially because some of these kthreads are
storage-related (which we obviously don't want to kill during bootup).
During discussion at #15226, @dezgeg suggested the following
implementation:
for pid in $(pgrep -v -f '@'); do
if [ "$(cat /proc/$pid/cmdline)" != "" ]; then
kill -9 "$pid"
fi
done
This has a few downsides:
* User space processes which use an empty string in their command line
won't be killed.
* It results in errors during bootup because some shell-related
processes are already terminated (maybe it's pgrep itself, haven't
checked).
* The @ is searched within the full command line, not just at the
beginning of the string. Of course, we already had this until now, so
it's not a problem of his implementation.
I posted an alternative implementation which doesn't suffer from the
first point, but even that one wasn't sufficient:
for pid in $(pgrep -v -f '^@'); do
readlink "/proc/$pid/exe" &> /dev/null || continue
echo "$pid"
done | xargs kill -9
This one spawns a subshell, which would be included in the processes to
kill and actually kills itself during the process.
So what we have now is even checking whether the shell process itself is
in the list to kill and avoids killing it just to be sure.
Also, we don't spawn a subshell anymore and use /proc/$pid/exe to
distinguish between user space and kernel processes like in the comments
of the following StackOverflow answer:
http://stackoverflow.com/a/12231039
We don't need to take care of terminating processes, because what we
actually want IS to terminate the processes.
The only point where this (and any previous) approach falls short if we
have processes that act like fork bombs, because they might spawn
additional processes between the pgrep and the killing. We can only
address this with process/control groups and this still won't save us
because the root user can escape from that as well.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Fixes: #15226
