Bug#819342: More brokenness in date(1) around DST
Hi, my timezone is CEST; we switched from CET today. % TZ=Europe/Budapest LC_TIME=C date --date 'tomorrow 2:30' date: invalid date ‘tomorrow 2:30’ 2:30 would be invalid today (2:00am became 3:00am), but it exists tomorrow, and date(1) can print that date if I request it in a different way: % TZ=Europe/Budapest LC_TIME=C date --date 'now+10 hours+30 minutes' Mon Apr 1 02:30:51 CEST 2024 This also works: % TZ=Europe/Budapest LC_TIME=C date --date @1711931400 Mon Apr 1 02:30:00 CEST 2024 Best regards, András -- To shoot a mime, do you use a silencer?
Bug#1051187: [Pkg-zfsonlinux-devel] Bug#1051187: Avoid building module for kernels that have appropriate zfs-modules- package installed
On Fri, Jan 05, 2024 at 07:04:02AM +, 陈 晟祺 wrote: Hi, > > zfs-dkms is the failsafe in case the zfs-modules- package is > > *not* installed > > (for example, because this is the first slow box I'm installing this kernel > > or this version of > > zfs-dkms on and I don't yet have a corresponding zfs-modules package). > > Let's imagine you install modules pkg first, then dkms pkg, which skips > building because you have > "same" modules installed. After some days you accidentally uninstalled the > modules pkg, then how > would the dkms pkg know and start the building? There is no such mechanism > according to my knowledge. I'd like to start by saying that installing a zfs-modules- package is something only few people would probably do, people who have good reasons for going off the beaten path. I submit that it's not unreasonable to expect such people to be extra careful and be aware of the risks inherent in what they are doing. That said, I suppose a dpkg trigger could be used; or the postrm script of the zfs-modules- package could trigger the module build if zfs-dkms is installed. But frankly, I'm a great believer in allowing people to shoot themselves in the foot if they so desire. Expert features (which this would be) don't call for nanny automation. > Even though such mechanism can be implemented by dkms, let's dig deeper into > details: how would dkms > know that your prebuilt version and dkms source files are "the exact same" > and decide to skip? Designing > such a mechanism would be either cumbersome for developers, or confusing for > users, I suppose. I don't think it needs to do that. If the zfs-modules- package is installed, that means the admin is taking care of things. If they have outdated kernel modules installed, it's their problem and not up to dkms or zfs-dkms maintainers to fix for them. You don't have to do everything for everyone. I'd say it would be sufficient to document that installing a zfs-modules- package is not officially supported, and has the following consequences: 1. zfs-dkms won't build a new module for ; 2. if you subsequently remove zfs-modules-, you'll be left without a zfs module for unless you trigger a zfs-dkms build yourself. FWIW, you could also look at it from a green angle: building the modules when it's not necessary consumes extra electricity and is thus wasteful. Best regards, András -- I break into song if I can't find the key.
Bug#1054537: Squid 6.3: multiple vulnerabilities, patches available
Package: squid Version: 6.3-1 Severity: grave Tags: security patch X-Debbugs-Cc: Debian Security Team Hi, https://wid.cert-bund.de/portal/wid/securityadvisory?name=WID-SEC-2023-2725 links to a bunch of squid advisories, three of which have CVSS scores of 9+: https://github.com/squid-cache/squid/security/advisories/GHSA-2g3c-pg7q-g59w https://github.com/squid-cache/squid/security/advisories/GHSA-phqj-m8gv-cq4g https://github.com/squid-cache/squid/security/advisories/GHSA-543m-w2m2-g255 https://github.com/squid-cache/squid/security/advisories/GHSA-j83v-w3p4-5cqh Squid 6.4 includes the fix; patches for 6.3 are provided, but don't apply cleanly to the Debian sources. Please package a non-vulnerable version ASAP. Thanks! András -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (350, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Init: runit (via /run/runit.stopit) LSM: AppArmor: enabled -- Computers are not intelligent. They only think they are.
Bug#1053358: Breaks if user-defined zfs properties contain whitespace
On Mon, Oct 02, 2023 at 04:00:57PM -0400, Michael Jeanson wrote: Hi, > Can you open a bug upstream? I would prefer to go with a fix approved by > upstream. Sure, will do. > Also I'm not sure I understand under which circumstances the content of > '$value' could be controlled by an 'adversary'? Can you explain shortly what > would be an exploitation scenario you envision? It doesn't have to be an adversary; you could also have some free-text comment in a zfs user property that, if passed to a shell unescaped, does something you don't want. My examples were perhaps extreme. That said, at least two feasible scenarios exist: 1. the admin could be delegating the permission to set properties to users (using zfs allow), who would then potentially be adversaries. If "userprop" is delegated, the user can create their own free-text properties. 2. you could be working with a zfs pool created by an adversary (e.g. as part of a forensic examination). András -- Crawlers never stumble.
Bug#1053358: Breaks if user-defined zfs properties contain whitespace
OK, that quick fix will work for whitespace but still break on apostrophes. How about using the escapeshellparam sub? https://github.com/jimsalterjrs/sanoid/blob/61000c9da2f8762424ba2de8a49abb1b7ec5154d/syncoid#L2070 Or, better yet, replace that sub with this: https://metacpan.org/dist/String-ShellQuote/source/ShellQuote.pm (why reinvent the wheel?). András -- Minél távolabbról nézzük, annál messzebbről látjuk.
Bug#1053358: Breaks if user-defined zfs properties contain whitespace
Package: sanoid Version: 2.2.0-1 Severity: important Tags: upstream patch Hi, line 496 of syncoid reads $recvoptions .= " -o $key=$value"; this string is then apparently passed to a shell, which will split $value into words on whitespace, causing the zfs command line to become invalid at best and do something nasty at worst (think e.g. "zfs set foo='; zpool destroy tank'" or "zfs set foo='$(cat /path/to/secret/file)'" -- I haven't determined whether these would "work" but they might). The following looks like a valid quick fix, but I don't know enough perl to be sure: $recvoptions .= " -o $key='''$value'''"; Justification for severity 'important': this is serious (potentially security relevant) breakage but it doesn't affect everyone. András -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (350, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=hu_HU.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 Init: runit (via /run/runit.stopit) sanoid recommends no packages. sanoid suggests no packages. -- I've often asked myself what kind of idiot makes up taglines, and now I know.
Bug#1036095: freerdp2-x11: Compile with Kerberos support
Hi,
I've tried a kerberos-enabled build of freerdp2; it didn't actually work. I
asked the freerdp people in #freerdp on irc.oftc.net and they said to use
FreeRDP3:
14:49 -> hi, I'm trying to use kerberos authentication to connect to a Windows
server using xfreerdp (compiled with gssapi support); I can see it request a
kerberos ticket successfully, but then authentication fails with
"[ERROR][com.winpr.sspi.Kerberos] - Init GSS security context failed : can't
use Kerberos" and "[WARN][com.winpr.sspi] - InitializeSecurityContextA status
SEC_E_INTERNAL_ERROR [0x80090304]" (also "NLA begin failed") -- what could be
wrong?
14:50 < hardening2[m]> switch to FreeRDP3 (master)
14:51 < hardening2[m]> it's not working with freerdp2
Since FreeRDP3 appears to be in late beta I think it would already be
appropriate to include it in sid.
Getting the current packaging to work with it doesn't look too difficult, only
some hardwired 2s need to be changed to 3s, and there is this bit in
debian/rules:
sed -E -i \
-e "s$(xSEDx)$${o}=[^=]+=\. $(xSEDx)$(xSEDx)g;" \
-e "s$(xSEDx) $${o}=[^=]+=\.$(xSEDx)$(xSEDx)g;" \
obj-$(DEB_HOST_GNU_TYPE)/*/*/buildflags.h
obj-$(DEB_HOST_GNU_TYPE)/*/*/*/buildflags.h
(There are several buildflags.h files now.)
András
--
To err is human; to forgive, infrequent.
Bug#1051187: [Pkg-zfsonlinux-devel] Bug#1051187: Avoid building module for kernels that have appropriate zfs-modules- package installed
On Mon, Sep 04, 2023 at 08:19:45AM +0200, Petter Reinholdtsen wrote: > [Andras Korn] > > I have computers that take forever to build kernel modules; therefore, > > while I have zfs-dkms installed as a failsafe, I also strive to always > > install zfs-modules- preemptively. > > How do you imagine zfs-dkms should work as a failsafe if it is not built > when the zfs-modules- package is installed? That's not the case I need the failsafe for. :) zfs-dkms is the failsafe in case the zfs-modules- package is *not* installed (for example, because this is the first slow box I'm installing this kernel or this version of zfs-dkms on and I don't yet have a corresponding zfs-modules package). András -- Need an ark to save two of every species of animal? I noah guy.
Bug#1051187: Avoid building module for kernels that have appropriate zfs-modules- package installed
Package: zfs-dkms Version: 2.1.12-2 Severity: normal Hi, I have computers that take forever to build kernel modules; therefore, while I have zfs-dkms installed as a failsafe, I also strive to always install zfs-modules- preemptively. Unfortunately, the zfs-dkms postinst still causes the zfs modules to be built for kernels that already have the exact same zfs modules provided by the installed zfs-modules package. I don't know enough about dkms to be able to suggest where a check that avoids this build belongs; please feel free to reassign this bug to the dkms package if that's more appropriate. Thanks András -- System Information: Debian Release: trixie/sid APT prefers stable-security APT policy: (500, 'stable-security'), (350, 'unstable'), (1, 'experimental') merged-usr: no Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.4.0-3-amd64 (SMP w/8 CPU threads; PREEMPT) Init: runit (via /run/runit.stopit) -- I'd love to go out with you, but there is a disturbance in the Force.
Bug#1051186: *-dkms packages shouldn't fail postinst if all modules to be installed already exist in identical versions
Package: dkms
Version: 3.0.11-3
Severity: normal
Hi,
I have computers where I install both zfs-dkms and sometimes
zfs-modules- packages.
When zfs-modules- is installed, zfs-dkms fails postinst:
[...]
zzstd.ko:
Running module version sanity check.
Module version 1.4.5a-2.1.12-2 for zzstd.ko
exactly matches what is already found in kernel 6.4.0-3-amd64.
DKMS will not replace this module.
You may override by specifying --force.
Error! Installation aborted.
dpkg: error processing package zfs-dkms (--configure):
installed zfs-dkms package post-installation script subprocess returned error
exit status 6
I think that when all modules to be installed exactly match the ones already in
place, that shouldn't result in a failure.
In case you wonder why I'm doing this: these computers take forever to build
kernel modules, so whenever possible, I install pre-built modules and want to
keep dkms only as a failsafe, to make sure the zfs modules are in place before
I reboot (because they're needed for booting).
I'm filing the bugreport against dkms because it contains these lines of code
(around line 800):
if [[ ! "$force" ]]; then
# if the module has neither version nor srcversion/checksum, check
the binary files instead
local verinfo="$(get_module_verinfo "${dkms_module}")"
if [[ "$(echo "$verinfo" | tr -d '[:space:]')" ]] || diff
"${kernels_module}" "${dkms_module}" &>/dev/null; then
echo $"Module version $(echo "$verinfo" | head -n 1) for
$4${module_suffix}" >&2
echo $"exactly matches what is already found in kernel $1." >&2
echo $"DKMS will not replace this module." >&2
echo $"You may override by specifying --force." >&2
return 1
fi
fi
I believe that "return 1" should be a "return 0" because there is no failure. A
binary with the exact same version and/or contents is already installed; that's
exactly the outcome dkms was asked to achieve.
I'll file a separate bug against zfs-dkms asking to avoid building the module
for kernels for which an appropriate zfs-modules- package is installed.
András
-- System Information:
Debian Release: trixie/sid
APT prefers stable-security
APT policy: (500, 'stable-security'), (350, 'unstable'), (1, 'experimental')
merged-usr: no
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.4.0-3-amd64 (SMP w/8 CPU threads; PREEMPT)
Init: runit (via /run/runit.stopit)
--
Give a man a fire and he's warm for a day, but set
fire to him and he's warm for the rest of his life.
Bug#1051138: 3.0pl1-166 introduced undeclared dependency on usrmerge
Package: cron Version: 3.0pl1-174 Severity: important Hi, with /bin gone from the default PATH in /etc/crontab (due to #1042894), cron will no longer find run-parts(8), which is in /bin, unless /bin is merged into /usr/bin. I ran into this on dozens of systems that were upgraded to sid semi-regularly but have existed for several years. Cron was suddenly unable to run hourly, daily, weekly and monthly jobs, which would all have involved run-parts, effectively breaking cron on these systems almost completely (which is my justification for the "important" severity). I believe it would make sense to either 1. add an explicit dependency on usrmerge; or 2. modify the default crontab to at least invoke run-parts itself with its full path (although this may still lead to breakage if the jobs themselves assume /bin and /sbin are in the PATH); or 3. revert the change to the default PATH; or 4. somehow make the PATH dependent on whether /bin is a symlink to /usr/bin. I only include the fourth option for completeness; I don't think it would be a good idea. András -- System Information: Debian Release: trixie/sid APT prefers stable-security APT policy: (500, 'stable-security'), (350, 'unstable'), (1, 'experimental') merged-usr: no Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.4.0-3-amd64 (SMP w/8 CPU threads; PREEMPT) Init: runit (via /run/runit.stopit) -- To be or to not be, that is the split infinitive.
Bug#1050217: Better coexistence with libpam-tmpdir
Package: tmpreaper Version: 1.6.17 Severity: normal Hi, having libpam-tmpdir installed results in PAM creating a /tmp/user/ directory for every user when they start a session, setting TMP and TMPDIR to this directory. Long-running processes such as web applications started e.g. via sudo -u someuser may end up with their TMP set to /tmp/user/, which is desirable because it makes /tmp attacks against them harder. However, if they don't use their individual tmp directories frequently, tmpreaper with its default settings may delete them, breaking the application. I suggest that the default configuration be changed thusly: TMPREAPER_PROTECT_EXTRA='/tmp/user/[0-9]*' TMPREAPER_DIRS='/tmp/. /tmp/user/*/.' This would (I hope) cause the per-user tmp directories themselves to be left alone but their contents cleaned up. Thanks András -- System Information: Debian Release: trixie/sid APT prefers stable-security APT policy: (500, 'stable-security'), (350, 'unstable'), (1, 'experimental') merged-usr: no Architecture: amd64 (x86_64) Foreign Architectures: i386 Locale: LANG=en_US.UTF-8, LC_CTYPE=hu_HU.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 Init: runit (via /run/runit.stopit) LSM: AppArmor: enabled Versions of packages tmpreaper depends on: ii debconf [debconf-2.0] 1.5.82 ii libc6 2.37-7 ii libmount1 2.38.1-5devuan1+b1 tmpreaper recommends no packages. tmpreaper suggests no packages. -- Configuration Files: /etc/tmpreaper.conf changed [not included] -- debconf information excluded
Bug#1039740: Please ship slapm-ppm
Package: slapd-contrib Version: 2.5.13+dfsg-5 Severity: wishlist Hi, please build and ship contrib/slapd-modules/ppm. It greatly enhances the functionality of the password policy overlay by allowing the user to implement semi-complex password policies (such as "have characters from at least 4 of these 5 character classes"). Thanks! András -- Who is General Failure, and why is he reading MY disk??
Bug#1038158: Uses /etc/nullmailer/../mailname instead of /etc/mailname; misleading message
On Wed, Jun 21, 2023 at 10:18:13AM +0300, David Bremner wrote:
> > I began using a revision tracking system for some configfiles. This
> > involved replacing /etc/nullmailer with a symlink to a directory
> > within the local working copy.
>
> I don't know if it's practical for you, but as a workaround etckeeper
> works fine with the current nullmailer, since it doesn't use symlinks.
Thanks for the suggestion, but no, it's not practical.
> > Also, printing messages to /dev/console isn't terribly useful in the
> > case of remote headless servers.
>
> I don't (yet) see what is explicitely opening /dev/console. How are you
> starting nullmailer? For example, I would expect systemd to capture
> stdout. Although README.Debian mentions /dev/console, this patching to
> change upstream's logging is no longer done in the current version of
> nullmailer.
I'm running nullmailer-send via runit. stdout is definitely a pipe (and so is
stderr); somewhere it opens /dev/console explicitly.
My runit 'run' script for nullmailer is:
--- >8 ---
#!/bin/sh
exec 2>&1
if [ ! -c /var/spool/nullmailer/trigger ]; then
rm -f /var/spool/nullmailer/trigger
mkfifo /var/spool/nullmailer/trigger
fi
chown mail:root /var/spool/nullmailer/trigger
chmod 0622 /var/spool/nullmailer/trigger
exec chpst -u mail nullmailer-send
--- 8< ---
In other instances, I start nullmailer-send from cron to process its queue
every once in a while, using this script:
--- >8 ---
#!/bin/sh
trigger=/var/spool/nullmailer/trigger
[ -r /etc/nullmailer/pausetime ] || exit 0
[ -x /usr/sbin/nullmailer-send ] || exit 0
if [ "$(cat /etc/nullmailer/pausetime)" = "0" ]; then
rm -f /service/nullmailer-send
if [ ! -c $trigger ]; then
[ -e $trigger ] && rm -f $trigger
mkfifo $trigger
fi
chown mail:root $trigger
chmod 0622 $trigger
exec chpst -L /var/lock/nullmailer-oneshot.lock nullmailer-send -s
>/dev/null 2>&1
else
exit 0
fi
--- 8< ---
> > 1. in order to avoid violating the principle of least surprise, don't
> > disregard /etc/nullmailer/me. If it's there, the admin put it there for a
> > reason.
>
> I would have to go back and read the (ancient) bugs for why this change
> was made in the first place. I guess allowing /etc/nullmailer/me to
> override /etc/mailname will break some existing configurations.
I suppose that's possible; but since nullmailer has been printing warnings
about this file all this time, it would be my guess that not many people have
it.
> > 2. if /etc/nullmailer/me doesn't exist, default to "/etc/mailname",
> > not "/etc/nullmailer/../mailname".
>
> Offhand I don't understand why it doesn't use an absolute path there. Maybe
> someone (tm) can change the appropriate line in hostname.cc and test the
> result.
Well, that at least is easy. In
debian/patches/0005-Provide-for-etc-mailname.patch, you have:
diff --git a/lib/hostname.cc b/lib/hostname.cc
index 5a7bde2..ac94ffc 100644
--- a/lib/hostname.cc
+++ b/lib/hostname.cc
@@ -24,6 +24,7 @@
#include "configio.h"
#include "hostname.h"
#include "canonicalize.h"
+#include "fdbuf/fdbuf.h"
mystring me;
mystring defaulthost;
@@ -33,7 +34,13 @@ void read_hostnames()
{
int nome;
nome = 0;
- if (!config_read("me", me)) {
+ // introduced as bugfix for #120660, #157259, #158412 in 1.00RC5-17;
+ // still there since it's more appropriate for Debian systems
+ mystring disregard;
+ if (config_read("me", disregard)) {
+ferr << "Warning: On Debian systems, nullmailer's 'me' is disregarded;
please use '/etc/mailname' instead." << endl;
+ }
+ if (!config_read("../mailname", me)) {
nome = 1;
me = "me";
}
diff --git a/test/functions.in b/test/functions.in
index bc62b67..9f8c922 100644
--- a/test/functions.in
+++ b/test/functions.in
@@ -154,6 +154,6 @@ EOF
export PATH=/bin:/usr/bin:/usr/local/bin
rm -f $SYSCONFDIR/*
-echo f.q.d.n >$SYSCONFDIR/me
+echo f.q.d.n >$SYSCONFDIR/../mailname
echo q.d.n >$SYSCONFDIR/defaultdomain
set -e
I
Bug#1038158: Uses /etc/nullmailer/../mailname instead of /etc/mailname; misleading message
Package: nullmailer Version: 1:2.2-3+b1 Severity: normal Hi, I began using a revision tracking system for some configfiles. This involved replacing /etc/nullmailer with a symlink to a directory within the local working copy. I noticed that locally generated mail was suddenly referencing literal "defaulthost". I tried to create /etc/nullmailer/me with the correct hostname in it, but this didn't help. I attached strace to cron in an attempt to see what was going on and found this: openat(AT_FDCWD, "/etc/nullmailer/me", O_RDONLY) = 3/etc/nullmailer/me> read(3/etc/nullmailer/me>, "my-correct-hostname-here\n", 4096) = 27 close(3/etc/nullmailer/me>) = 0 write(2>, "Warning: On Debian systems, nullmailer's 'me' is disregarded; please use '/etc/mailname' instead.\n", 98) = 98 getuid()= 0 geteuid() = 0 openat(AT_FDCWD, "/etc/nullmailer/../mailname", O_RDONLY) = -1 ENOENT (No such file or directory) So, while nullmailer prints a message instructing me to fill /etc/mailname, it doesn't actually use /etc/mailname but /etc/nullmailer/../mailname, which doesn't necessarily exist and isn't necessarily the correct file if /etc/nullmailer is a symlink. Also, printing messages to /dev/console isn't terribly useful in the case of remote headless servers. I suggest the following changes: 1. in order to avoid violating the principle of least surprise, don't disregard /etc/nullmailer/me. If it's there, the admin put it there for a reason. 2. if /etc/nullmailer/me doesn't exist, default to "/etc/mailname", not "/etc/nullmailer/../mailname". 3. if these two changes are made, the message becomes unnecessary and can be a simple README.Debian item. 4. if you must print a message, log it to syslog instead of (or, if you insist, in addition to) writing it to /dev/console. However, can't writing to /dev/console block e.g. due to flow control on the terminal device? If so, I'd leave /dev/console alone. Best regards, András -- Mishearing the voices in his head, our hero wonders how he's supposed to kill the mall.
Bug#1034363: firefox: Non-default fonts no longer work
Hi, possibly related: since upgrading to 112.0, some custom fonts set by websites are no longer rendered. For example, on https://www.teletal.hu/etlap/16, there is supposed to be a leftmost column of row labels in the table, saying "RE1", "RE2", "A1", "A2" and so on. If the setting "Allow pages to choose their own fonts, instead of your selections above" (browser.display.use_document_fonts) is enabled, these labels are invisible (you can select them and their space will be highlighted, but the letters are not rendered). Disabling use_document_fonts causes the labels to be rendered correctly (in the font chosen in the preferences). The same problem occurs with most text on facebook.com and messenger.com as well. I was able to replicate this with a blank new browser profile, using firefox 112.0-1 and up to date sid as of today. András -- I ? Unicode.
Bug#1022837: /lib/runit/run_sysv_scripts uses wrong test to skip initscripts
On Tue, Mar 28, 2023 at 01:10:36AM +0200, Lorenzo wrote: Hi, > Please follow up and let me know if my idea would solve this issue or at > least improve the situation from your point of view: > > > > Checking for /etc/sv/$name and skipping initscripts if those directories > > exist is wrong for two reasons: > > > > 1. /etc/sv/$name may not be symlinked into /etc/service (false positive); > > > > 2. /etc/service may contain a symlink to a service directory for this > > service that is elsewhere in the filesystem, not in /etc/sv (false > > negative). > > > > As a minimum, I suggest the following: instead of /etc/sv/$name, check for > > /etc/service/$name (and $name-daemon if necessary), and not with "-d" but > > "-L" (because when running rcS.d, the target of the symlink may only appear > > later, for example when a new filesystem is mounted). > > I propose the following: > > * patch runit-helper, update-service and /lib/runit/trigger_sv so that every > (package provided) runit service is always represented in /etc/service/, > either with a foo symlink (enabled) or with a .foo symlink (disabled). OK, this works (although I don't see why it's necessary), as long as nothing gets confused by the existence of both symlinks. For example, under this scheme, I may have: /service/ssh -> /some/dir/where/I/keep/my/services/ssh # created "manually" /service/.ssh -> /etc/sv/ssh# created during container provisioning to prevent the ssh package from installing its version of the service (otherwise it creates /etc/service/ssh/ssh) If there is potential for confusion, then a mechanism to delete the .ssh symlink if/when the plain ssh symlink is present would also be needed. > This way I (as a packager) can test /etc/service/ to know if a runscript > exists in /etc/sv/. You can, but I'm not sure I see why you have to. The /etc/sv location is not special per se; why does it matter whether there is anything there in particular? > For users that have their own runscripts collection somewhere in the > filesystem: they will enable their services by creating the foo symlink, and > they can have the sysv emulation skip certain services (let's say a bar > service) by creating a /etc/service/.bar symlink. That's a needless extra hoop to jump through. When deciding whether to skip invoking /etc/init.d/bar, why is it better to check for the existence of "/etc/service/.bar" than "/etc/service/bar"? The latter needs to exist anyway, because that's what will cause runit to start the service. > This would also prevent runit package (and runit-helper) to enable the bar > service, if any /etc/sv/bar exists, because the logic in runit-helper and > sv_trigger only test if the symlink (or dot-symlink) exists, but it doesn't > care where it points. Again, to me it seems that the existence of /etc/service/bar should be sufficient. If it exists, the service is enabled. If it needs to be disabled in a way that it can be re-enabled later, you can rename the existing bar symlink to ".bar", regardless of where it points. > In any case runit/runit-helper only creates and remove links in the > /etc/runit/runsvdir/default directory, so if you point runsvdir to another > directory runit package doesn't enable or disable anything for you. Perhaps it should be called debian-default; but it's good to know that using a differently-named runsvdir is a way of opting out of much of the nanny-automation I find so annoying. :) > * turn the run_sysv_scripts into a runit service that test for > /etc/service/$name. Two main reason for this: This needs to be thought through carefully (it would need to only run once, but finish before other services are started -- for example, it could do a runsvchdir in ./finish). > 1. users can disable it, or change it at their will, while any change into > /lib/runit/run_sysv_scripts is overwritten by the package, so users are > forced to change stage 2 and create their own version of the script You could also achieve this by preferring /etc/runit/lib/run_sysv_scripts if it is executable, and only running /lib/runit/run_sysv_scripts if not. Even more complex setups would also be possible, with /lib/runit/run_sysv_scripts relying on shell functions that a user-supplied sourced file could override, but I think that would go too far. > 2. when runit services are mixed with sysv scripts in the start sequence, > the run_sysv_scripts can be RC-buggy, see #1024969 [1] for an example Yeah, that's a hard problem to solve cleanly. Maybe you just shouldn't ship (or enable by default) runit services that initscript-based stuff frequently depends on. I'm not sure how much else there is, other than dbus. Alternatively, you could ship a one-shot runit service that depends on the dbus service and that invokes all initscripts that declare a dependency on dbus... Far from my idea of clean. I also have another idea but it's so complex
Bug#1031742: Please make reboot command configurable
Package: unattended-upgrades Version: 2.9.1+nmu3 Severity: wishlist Hi, not all flavours of shutdown(8) support a time argument; for example, runit's only supports 'now' or no time. When unattended-upgrades tries to schedule a reboot on runit systems, shutdown(8) prints an error, causing unattended-upgrades to become sad. I'd like to provide my own mechanism for scheduling reboots (e.g. via at(1)). Please add a config tunable for this. Thanks! András -- System Information: Init: runit (via /run/runit.stopit) -- Keves, mint terdkalacsban a mazsola.
Bug#1030747: Acknowledgement (fuser(1) tries to use statx() which is not available on older kernels and prints misleading error when it can't)
fwiw, psmisc 23.5-3 still works even if the kernel doesn't support statx(). The changelog for 23.6 says "fuser: Use modern statn where possible", but it's regrettably also used where not possible. András -- Is 6 afraid of 7, 'cause 7 8 9?
Bug#1031295: pcp fails to install without systemd
Hi, it seems to me that in postinst, instead of if $do_systemd then systemctl start pmcd.service >/dev/null systemctl start pmlogger.service >/dev/null elif which invoke-rc.d >/dev/null 2>&1 then invoke-rc.d pmcd start invoke-rc.d pmlogger start else /etc/init.d/pmcd start /etc/init.d/pmlogger start fi You could just do service pmcd start service pmlogger start Additionally, I think a case can be made for ignoring failures to start these services in postinst. If the package fails to configure, that'll break unattended-upgrades which will then also not install security updates. András -- A hangover: the wrath of grapes.
Bug#1030747: fuser(1) tries to use statx() which is not available on older kernels and prints misleading error when it can't
Package: psmisc Version: 23.6-1 Severity: normal Hi, fuser(1) will call statx(): statx(0>, "/", AT_STATX_DONT_SYNC|AT_NO_AUTOMOUNT, STATX_TYPE|STATX_INO, 0x7fffb96603a0) = -1 ENOSYS (Function not implemented) which is not avilable on kernels before, I think, 4.11. When that fails, fuser(1) prints "Cannot find socket's device number. Cannot stat /: Invalid argument" which is not helpful in finding out what's wrong. I realize that Debian doesn't ship such old kernels anymore, but I think it would be desirable to be more backwards compatible, and, failing that, to print an error message that actually explains what went wrong. To me it looks like it would be best to fall back to the older stat* calls if statx() is not available at runtime. A point could also be made to refuse installation/upgrade on kernels older than 4.11, or kernels that don't have statx, unless the user creates some flag file to override this (e.g. because they don't need fuser(1)). Best regards, András -- System Information: Debian Release: sid APT prefers unstable Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.337-vs2.3.9.13 (SMP w/24 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=hu_HU.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 Shell: /bin/sh linked to /bin/dash Init: runit (via /run/runit.stopit) LSM: AppArmor: enabled Versions of packages psmisc depends on: ii libc6 2.36-8 ii libtinfo6 6.4-2 psmisc recommends no packages. psmisc suggests no packages. -- no debconf information -- I've always wanted to change my legal name to ';DROP DATABASE; -- ' and see what kind of havoc ensues.
Bug#1030349: gdbm module is missing from zsh package again
Package: zsh Version: 5.9-3 Severity: normal Tags: patch Hi, this was last reported as #951457. Apparently this change (from zsh changelog): 2020-01-06 Daniel Shahaf * 45213: README, configure.ac: Make --enable-gdbm default to false, rather than default to true with an unavoidable warning. ... caused zsh to be build without gdbm support unless --enable-gdbm were passed to configure. Please add --enable-gdm to debian/rules: "CONFIGFLAGS += --enable-gdbm" Thanks. András -- Knowledge is power - if you know it about the right person.
Bug#1030225: /etc/runit/2 assumes it runs in an environment that can mount filesystems
On Thu, Feb 02, 2023 at 12:27:04AM +0100, Lorenzo wrote: Hi, > > /etc/runit/2 ships with this snippet: > > > > mkdir -p /run/runit/supervise > > mkdir -p /run/runit/sv > > mount -t tmpfs -o size=20M,mode=0755 runtimesv /run/runit/sv > > cp -a /etc/sv/* /run/runit/sv/ #TODO do this with > > 'CPSV_DIR=/run/runit/sv cpsv --sync' > > > > If runit is used in an unprivileged container, > with runit you mean runit as init or simply respawn runsvdir via stage > 2? Both, but in my specific case, runit-as-init. > The mount can be moved to stage 1, where other mount invocations already > happen; however this will cause a relevant difference when runit is > used as init vs when only stage 2/runsvdir is run.. I don't think it makes sense to move it, but it *would* make sense to provide a way to turn this off. > > mount -t tmpfs -o size=20M,mode=0755 runtimesv /run/runit/sv > the idea is to have a copy of services there and to run services there, > like /etc/service points to /etc/runit/runsvdir/deafult.run that > contains links to directories in /run/runit/sv/ But why must these directories be on a separate fs under /run? Why can't they just be wherever it suits the administartor to put them? > without that mount line: > Problem 1: run is mounted 'noexec', so each runsv fails This is true, but, to me, all the more reason not to try to put executable stuff under /run. :) > Problem 2: there are mechanism (cpsv) that copy services in /run and by > limiting the size I want to avoid that an abuse of such mechanism could > result in eating all space in /run mount (very unlikely but still..) I never quite got the point of cpsv either, so thanks for explaining it below. > Reasons why I'm thinking of running services in /run/runit/sv/ : > > A) anything in /etc/sv is a conffile, so special care is needed when > upgrade happens to detect and not overwrite local changes. That is > handled by dpkg or ucf, but they work on files, while a service for > runit is a directory. I think ideally the entire service should be > considered locally modified if the run file (or finish, or control/* > and probably also log/run) has local changes. I don't agree. I don't think it's important not to install a new 'finish' script if 'run' was locally modified by 'finish' wasn't. On the other hand, the more complexity you add to the service scripts, the more dangerous it will be to upgrade them piecemeal, so you have a point there. My reaction would be to try and avoid the complexity instead of increasing it by adding a new indirection layer. I think systemd gets this particular thing more or less right, with shipping distribution files (which are not conffiles) in /lib, but allowing local files with the same name in /etc to override them. I think the way you could do this in runit would be to ship your services in /lib/runit/sv, but have /etc/sv directories too, where /etc/sv/foo/run is, by default, a symlink to /lib/runit/sv/foo/run. If the admin wants to customize, he can replace the symlink with a file, and if a particular service looks too complex to feel good about leaving only half-customized, he can replace all symlinks with files. > I can think of many ways to break a service by retaining the local > version of a run file while finish or control/* are changed/upgraded. So can I, but most of those start with making run, finish or control/* more complex (and thus fragile) than necessary. I see runit as a system that is intended to be robust in its simplicity; instead of trying to be clever and generic with service scripts, I'd like to keep them straightforward. On the whole, I also don't think runit needs to ship a plethora of service scripts that invite any kind of customization. How many users are there, and how many of them need or want the package to ship services? (I know I'd be perfectly happy if the runit and runit-init packages only contained the runit framework and I had to supply all service directories myself.) > B) related to A, but different problem: think of what happens if a > foo service crashes while dpkg is upgrading (file by file) the service > directory: the automatic restart performed by runsv can exec a mix of > old and new files inside foo directory, with unexpected results like > in A, but temporary (only during the upgrade). Noted, but I still don't think overengineering is the way to address this. If service scripts were mostly minimal, changes wouldn't have to happen frequently (I have some services scripts I wrote 15 years ago that still work perfectly). Instead of adding more and more complexity to address rare scenarios (and likely introduce additional brittleness that will break in other unexpected ways that may not be immediately obvious), I'd prefer to retain simplicity. > Ideally the entire service directory should be updated atomically but > that requires to address the old.directory with a symlink, creating a > new.directory
Bug#1030225: /etc/runit/2 assumes it runs in an environment that can mount filesystems
Package: runit Version: 2.1.2-53 Severity: minor Hi, /etc/runit/2 ships with this snippet: mkdir -p /run/runit/supervise mkdir -p /run/runit/sv mount -t tmpfs -o size=20M,mode=0755 runtimesv /run/runit/sv cp -a /etc/sv/* /run/runit/sv/ #TODO do this with 'CPSV_DIR=/run/runit/sv cpsv --sync' If runit is used in an unprivileged container, the mount command may fail. Currently this is just a cosmetic problem (/lib/runit/sv will not be a separate filesystem and an error will be printed), but please don't start depending on this mount succeeding. Please also provide some reasoning (e.g. in a README.Debian file) why you're doing this at all, what the motivation is. -- A police officer just knocked on my door and told me my dogs are chasing people on bikes. That’s ridiculous. My dogs don’t even own bikes.
Bug#1030224: Inverted test for /etc/runit/no.emulate.sysv in /etc/runit/2
Package: runit Version: 2.1.2-53 Severity: normal Tags: patch Hi, /etc/runit/2 ships with this snippet: if [ "$runsv_dir" != solo ] || [ ! -e /etc/runit/no.emulate.sysv ]; then /lib/runit/async-timeout /lib/runit/run_sysv_scripts '/etc/rc2.d' fi This means that the rc2.d scripts are run if EITHER $runsv_dir does not equal "solo" OR the file /etc/runit/no.emulate.sysv doesn't exist. In other words, for rc2.d scripts to be skipped, BOTH of the following conditions must be true: 1. $runsv_dir has to equal solo; AND 2. /etc/runit/no.emulate.sysv has to exist. I think that rc2.d should be skipped if /etc/runit/no.emulate.sysv exists, regardless of the value of $runsv_dir. This is also what the README suggests: * /etc/runit/no.emulate.sysv Skip all sysv scripts enabled in rc2.d during the boot sequence, even if there is no correspondent native runscript in /etc/sv/ (I still also think that /etc/sv is the wrong place to check; the directory monitored by runsvdir, e.g. /etc/service, could contain a symlink to a service that resides somewhere else, not in /etc/sv/, and the existence of such a symlink should also cause the initscript invocation to be skipped.) For this particular issue in /etc/runit/2, I recommend just replacing the || with &&, so the snippet becomes: if [ "$runsv_dir" != solo ] && [ ! -e /etc/runit/no.emulate.sysv ]; then /lib/runit/async-timeout /lib/runit/run_sysv_scripts '/etc/rc2.d' fi András -- If debugging is removing bugs, then programming must be putting them in.
Bug#1023476: runit: Improve default-syslog check
On Wed, Nov 16, 2022 at 02:03:14PM +0100, Lorenzo wrote: > > > lsof /dev/log >/dev/null || exit 1 > > > > I think > > > > fuser /dev/log >/dev/null 2>/dev/null || exit 1 > > > > is more efficient, but there is a problem with both approaches: the process > > that is listening on /dev/null may be invisible to us, because it may be > > running in a different namespace. > > Thanks for the above: I didn't thought about using this service inside a > container (when the logger is outside) and I agree it's a nice to have > extension (assuming that you mean listening on /dev/log, otherwise I fail to > understand what you are talking about) Yes, sorry, my brain hit a bad sector there. /dev/log of course. > > The only way to reliably determine whether there is a Unix server listening > > on the /dev/log socket is to try to connect to the socket. > > > > One approach I can think of is to use > > > > unixclient /dev/log /bin/true 2>&1 | grep -q '^connect: Protocol wrong type > > for socket' || exit 1 > > > > This creates a SOCK_STREAM socket and tries to connect it to /dev/log, > > which will fail with EPROTOTYPE if there is a listening server (which will > > use SOCK_DGRAM) and with ECONNREFUSED if not. > > > > Using unixclient would introduce a semi-esoteric dependency on ucspi-unix, > > but it's a tiny package which is a good match for the runit ecosystem > > anyway, so maybe it's acceptable. > > > > A more mainstream but much more heavyweight approach would be to use > > socat(1) or netcat-openbsd with the -U option. > > > > Alternatively, socklog provides its own socklog-check, which does exactly > > what is necessary, but the whole point of trying to detect whether *any* > > syslog daemon is running is to avoid having to install a particular one > > like socklog, so we probably shouldn't use it. > > > > OTOH, it's such a tiny program, and so unlikely to require changes ever, > > you might even ship (a copy of) it as part of the runit package. > > I'm ok with ucspi-unix or socklog-check, but this can happen only after the > bookworm release. How about you make default-syslog/check use socklog-check or unixclient if they are available, and fall back to the current heuristics if not? Something like this: #!/bin/sh # note: only socklog exists as runit service in Debian right now socklog-check && exit 0 unixclient /dev/log /bin/true 2>&1 | grep -q '^connect: Protocol wrong type for socket' && exit 0 fuser /dev/log >/dev/null 2>/dev/null && exit 0 for service in rsyslog socklog socklog-unix syslog-ng busybox-syslogd inetutils-syslogd ; do sv u $service && sv check $service && exit 0 done exit 1 If socklog-check and unixclient aren't installed, those commands will just fail and the script will fall back to the next attempt. The only way I can see this being worse than the current solution is if searching PATH for executables is pathologically slow (e.g. due to an NFS outage maybe). > This bug can probably renamed as "default-syslog: useless inside a > container", right ? I don't think so; that wouldn't be accurate. It's only useless if the syslog daemon and the check script run in different namespaces; if they run in the same container, it works, and it also fails if check runs on the host and it's the syslog daemon that's in the container (this should be rare though). I'd call it "default-syslog: check for running syslogd not robust" or something. András -- Desk: A very large wastebasket with drawers.
Bug#1022172: Bug#1024082: Bug#1022172: /lib/modprobe.d/50-nfs.conf causes initramfs-tools to stop including sunrpc module for nfs
On Tue, Nov 15, 2022 at 10:00:43PM +0100, Salvatore Bonaccorso wrote: Hi, > > Try something like this in /lib/udev/rules.d/60-nfs.rules: > > > > ACTION=="add", SUBSYSTEM=="module", KERNEL=="sunrpc", \ > > RUN+="/sbin/sysctl -q --pattern ^sunrpc --system" > > ACTION=="add", SUBSYSTEM=="module", KERNEL=="rpcrdma", \ > > RUN+="/sbin/sysctl -q --pattern ^sunrpc.svc_rdma --system" > > ACTION=="add", SUBSYSTEM=="module", KERNEL=="lockd", \ > > RUN+="/sbin/sysctl -q --pattern ^fs.nfs.n[sl]m --system" > > ACTION=="add", SUBSYSTEM=="module", KERNEL=="nfsv4", \ > > RUN+="/sbin/sysctl -q --pattern > > ^fs.nfs.(nfs_callback_tcpport|idmap_cache_timeout) --system" > > ACTION=="add", SUBSYSTEM=="module", KERNEL=="nfs", \ > > RUN+="/sbin/sysctl -q --pattern ^fs.nfs --system" > > > > Differently from the original file I tired anchoring the patterns, which > > looks more correct to me. > > Thanks, I will try to test this and bring to nfs-utils upstream. > Michael or Andras, if you can help testing it in your use cases that > would be helpful. I don't have a real world test case for this; I don't set any of those sysctls. Incidentally, busybox sysctl doesn't support --pattern, so if this functionality is important, nfs-kernel-server needs to force inclusion of the "big" /sbin/sysctl in the initramfs. András -- To understand recursion, we must first understand recursion.
Bug#1022103: gdisk: sgdisk produces only errors
On Mon, Oct 24, 2022 at 11:18:03AM +0200, Andras Korn wrote: Hi, > unfortunately the bug is still not fixed despite the NMU; while sgdisk > doesn't print errors anymore, it also doesn't actually perform the requested > operations. I can no longer reproduce the problem. I don't know what happened. These versions work for me: ii gdisk 1.0.9-2.1amd64GPT fdisk text-mode partitioning tool ii libpopt0:amd64 1.19+dfsg-1 amd64lib for parsing cmdline parameters András -- I hope we grow as old as we look.
Bug#1023476: runit: Improve default-syslog check
Hi, > the check could be just something like > > lsof /dev/log >/dev/null || exit 1 I think fuser /dev/log >/dev/null 2>/dev/null || exit 1 is more efficient, but there is a problem with both approaches: the process that is listening on /dev/null may be invisible to us, because it may be running in a different namespace. The only way to reliably determine whether there is a Unix server listening on the /dev/log socket is to try to connect to the socket. One approach I can think of is to use unixclient /dev/log /bin/true 2>&1 | grep -q '^connect: Protocol wrong type for socket' || exit 1 This creates a SOCK_STREAM socket and tries to connect it to /dev/log, which will fail with EPROTOTYPE if there is a listening server (which will use SOCK_DGRAM) and with ECONNREFUSED if not. Using unixclient would introduce a semi-esoteric dependency on ucspi-unix, but it's a tiny package which is a good match for the runit ecosystem anyway, so maybe it's acceptable. A more mainstream but much more heavyweight approach would be to use socat(1) or netcat-openbsd with the -U option. Alternatively, socklog provides its own socklog-check, which does exactly what is necessary, but the whole point of trying to detect whether *any* syslog daemon is running is to avoid having to install a particular one like socklog, so we probably shouldn't use it. OTOH, it's such a tiny program, and so unlikely to require changes ever, you might even ship (a copy of) it as part of the runit package. András -- I break into song if I can't find the key.
Bug#1022837: /lib/runit/run_sysv_scripts uses wrong test to skip initscripts
On Wed, Nov 02, 2022 at 01:45:24PM +0100, Lorenzo wrote: Hi, > Am I correct that this is not a regression introduced with recent changes to > runit? [relevant to understand if I have to revert something in case I can't > fix this before the freeze] Yes. I just started using the default config files (/etc/runit/1 mainly) that you ship, and noticed this problem due to that. > Anyway, let me clarify this one first: > > > > Uh, what runtime directory? /etc/sv is currently a repository for > > package-supplied and admin-provided service directories. Why would you move > > that to /run, which is volatile? > > > > A. package supplied > B. admin-provided > C. runtime directory ( the directory that is actually > monitored by a runsv process when the service is enabled) > > with the current setup, A,B and C are overlapped in /etc/sv/: what I plan to > do is to separate these in 3 different path, like > > A. /usr/share/runit/sv/ (package supplied runscript, source format --> > symlinks are missing) > B. /etc/sv/ (reserved for local admin provided runscript) > C. /run/runit/sv/ (runtime copy of services) > > At system boot (see TODO comment in stage 2) a specialised cpsv(8) tool is > used to copy relevant runscript in C; when a 'name' runscript exists both in > A and B, the copy in B takes precedence. C is kept in sync with A and B > during runtime thanks to a trigger that is activated when a package that ship > a service is installed/ removed/ upgraded. To pick up changes to B, the local > admin will have to call cpsv (either with --sync or with -a). > > Now, cpsv is still WIP, and I can make A and C somehow configurable, and make > run_sysv_script behave consistently with cpsv, but is this really usefull? My first impression is you're trying to solve what is not a problem, and introducing unneeded complexity, where part of runit's appeal (at least for me) is its simplicity and straightforwardness. You're building extra layers around runit so that people who are familiar with runit per se aren't able to use the Debian runit packages without jumping through hoops. There may be good reasons, but personally, I don't like this direction. I would just as soon manage my /etc/service/* symlinks without any package automation. That said, I would be grateful for ways of getting rid of the following annoying behaviours: 1. openssh ships its /etc/sv/ssh directory, which gets symlinked to /etc/service during installation, but which never worked for me (unfortunately I didn't investigate, just replaced the symlink with one to my own /var/lib/svn-checkout/services/ssh); 2. a default-syslog service is created by something, and all it does on my systems is sleep indefinitely (I use socklog as my syslogd, but have my own service directory for that as well, and its name is just "socklog", so the magic "check" script won't pick it up -- and neither will it pick up a syslogd that is not managed by runit. Maybe just try to see if something is listening on /dev/log in "check"?). If I could override /etc/sv/ssh with my own directory (e.g. if "B" were a configurable list of locations in order of precedence), that would solve #1. If it were possible to disable the "default-syslog" service conclusively, permanently, by creating something somewhere during installation, or writing a line into a file, that would be great. Being able to opt out completely of all Debian specific runit glue would be even better; I accept that it's convenient for new or casual users, but for me in particular it's mostly just frustrating due to it being different from upstream runit, which I started using in around 2004 (switching to it from daemontools). > A: with the new layout, what would be the reason for you to checkout your svn > somewhere else than /etc/sv/ ? 1. /etc is for configuration. /var/lib/svn-checkout/services is not configuration; it's more like your /usr/share/runit/sv (except it's not shipped by a package, but it might as well be). 2. I see /etc/sv as a place to instantiate template-based services; like systemd has openvpn@foo, I have /etc/sv/openvpn-foo, whose run script is a symlink to my svn checkout's openvpn-template/run (and the script infers what openvpn config to use based on the "-foo" suffix of the runit service name). Mixing local instantiations with upstream svn content would be hard to maintain (e.g. "svn status" output would be cluttered). > C: to some extent is already configurable, because I need that for the > transition and I want to support user services (in /home/ ), but I'm not sure > there is a reasonable use case beyond that.. FWIW, user-template is another such service I instantiate separately for each user who needs to be able to have their own runit services. But you lost me again: what is already configurable to some extent? > > > > 1. /etc/sv/$name may not be symlinked into /etc/service (false > > > > positive); > > > > 2. /etc/service
Bug#1022837: /lib/runit/run_sysv_scripts uses wrong test to skip initscripts
On Fri, Oct 28, 2022 at 03:07:07PM +0200, Lorenzo wrote:
Hi,
> > Package: runit
> > Version: 2.1.2-50
> > Severity: normal
> >
> > Hi,
> >
> > /lib/runit/run_sysv_scripts has this:
> >
> > for script in "$initdir/$rX"* ; do
> > [ ! -x "$script" ] && continue
> > path=$(realpath "$script")
> > name=${path##*/}
> > # Special case for wicd. Runscript is called "wicd-daemon",
> > # to match binary package name.
> > [ -d "/etc/sv/$name" ] && continue
> > [ -d "/etc/sv/$name-daemon" ] && continue
> > "$script" "$rcommand"
> > done
> >
> > Checking for /etc/sv/$name and skipping initscripts if those
> > directories exist is wrong for two reasons:
> >
> > 1. /etc/sv/$name may not be symlinked into /etc/service (false
> > positive);
>
> The runit service exists and is not enabled, so why one would want to
> start a sysv instance instead?
> To me 1. looks correct, can you make an example when it causes
> unexpected/buggy results?
Our expectations are apparently different. I would expect
/lib/runit/run_sysv_scripts to do what it says on the tin: run sysv scripts.
The only reason to skip a script (as far as I'm concerned) is that running it
would conflict with a runit service.
It's not just about starting services either: if /etc/sv/$name exists but the
service is not managed by runit (that is, /etc/service/$name doesn't exist),
and I start the service manually via the initscript, run_sysv_scripts will also
fail to stop it.
I understand that you're thinking of /etc/sv/ as "configuration", but in this
instance I would prefer configuration to be more explicit; if I want to disable
a service I'll make sure it can't be started (e.g. by modifying its
/etc/default file), not just refrain from creating a /etc/service/ symlink for
it.
If I just want to disable automatic startups, I'll create
/etc/service/servicename/down.
> > 2. /etc/service may contain a symlink to a service directory for this
> > service that is elsewhere in the filesystem, not in /etc/sv (false
> > negative).
Example:
lrwxrwxrwx 1 root root 34 Feb 9 2009 /etc/service/atd ->
/var/lib/svn-checkout/services/atd
This isn't in /etc/sv, but it still means atd(8) is managed by runit.
> > As a minimum, I suggest the following: instead of /etc/sv/$name, check for
> > /etc/service/$name (and $name-daemon if necessary), and not with "-d" but
> > "-L" (because when running rcS.d, the target of the symlink may only appear
> > later, for example when a new filesystem is mounted).
> >
> > This is still imperfect during boot because /etc/service may point to some
> > directory that is not the one we'll switch to with runsvdir in stage 2. I
> > don't know what the best way of handling this (likely rare) case is, but
> > the following solutions come to mind:
>
> 2. is an issue, especially because I'm thinking of moving the runtime
> directory form /etc/sv/ --> /run/runit/sv/ : this move requires a
> long transition period where both the old and the new path are
> supported as runtime directories..
Uh, what runtime directory? /etc/sv is currently a repository for
package-supplied and admin-provided service directories. Why would you move
that to /run, which is volatile?
> On the other hand I don't know if with systemd or Sysvinit is even possible
> to boot the system with a custom path for services; I don't want to make it
> unnecessary hard to do it with runit, but I think it's reasonable to expect
> some effort on admin side for such setup.
I'm sorry, you lost me completely (or maybe I lost you; see my example symlink
above).
> > 1. have a /etc/runit/override-init.d/ directory. If $name exists in it,
> > don't invoke the initscript in /lib/runit/run_sysv_scripts. This places the
> > entire administration/configuration burden on the admin but is very simple
> > to do, and easy enough for the admin to automate (e.g. your own service
> > scripts can just create these files when they're first run).
>
> I'm ok with adding this, but it's unclear to me if the above is theoretical
> reasoning or you have an actual problem with your setup: in case of the
> latter please add more detail to avoid the unhappy case where the fix that i
> push doesn't solve your issue
Yes.
For example, I have an atd service whose service directory is
/var/lib/svn-checkout/services/atd. This is symlinked into /etc/service.
run_sysv_scritps doesn't detect it as a runit-supervised service, because the
directory is different from /etc/sv/atd, and starts another instance via the
initscript.
I have many such services. I keep my runit service directories in Subversion
and have a checkout of the repository on all systems. I just symlink the
appropriate directory from the checkout into /etc/service if I want to run a
service.
I use /etc/sv to instantiate services that I have templates for; for example, I
have an openvpn runit service template, so I'll create /etc/sv/openvpn-foobar
and create a
Bug#1022837: /lib/runit/run_sysv_scripts uses wrong test to skip initscripts
Package: runit
Version: 2.1.2-50
Severity: normal
Hi,
/lib/runit/run_sysv_scripts has this:
for script in "$initdir/$rX"* ; do
[ ! -x "$script" ] && continue
path=$(realpath "$script")
name=${path##*/}
# Special case for wicd. Runscript is called "wicd-daemon",
# to match binary package name.
[ -d "/etc/sv/$name" ] && continue
[ -d "/etc/sv/$name-daemon" ] && continue
"$script" "$rcommand"
done
Checking for /etc/sv/$name and skipping initscripts if those directories exist
is wrong for two reasons:
1. /etc/sv/$name may not be symlinked into /etc/service (false positive);
2. /etc/service may contain a symlink to a service directory for this service
that is elsewhere in the filesystem, not in /etc/sv (false negative).
As a minimum, I suggest the following: instead of /etc/sv/$name, check for
/etc/service/$name (and $name-daemon if necessary), and not with "-d" but "-L"
(because when running rcS.d, the target of the symlink may only appear later,
for example when a new filesystem is mounted).
This is still imperfect during boot because /etc/service may point to some
directory that is not the one we'll switch to with runsvdir in stage 2. I don't
know what the best way of handling this (likely rare) case is, but the
following solutions come to mind:
1. have a /etc/runit/override-init.d/ directory. If $name exists in it, don't
invoke the initscript in /lib/runit/run_sysv_scripts. This places the entire
administration/configuration burden on the admin but is very simple to do, and
easy enough for the admin to automate (e.g. your own service scripts can just
create these files when they're first run).
2. pass the name of the /etc/runit/runsv directory that we expect to be used
to /lib/runit/run_sysv_scripts somehow (for example, in an environment
variable). This looks brittle (riddled with race conditions) and complicated to
me, but it would require no effort from the admin.
3. invoke runsvchdir earlier during boot. This is problematic on systems where
/ is read-only before some initscripts are run.
4. [other kludges]
András
--
Reality is merely an illusion, albeit a very persistent one.
Bug#1022814: /etc/runit/1 could be more readable
Package: runit Version: 2.1.2-50 Severity: minor Tags: patch Hi, I'm not satisfied with this bit from /etc/runit/1: --- 8< --- if [ -f /etc/runit/native.boot.run ] || [ -n "$bootrun" ]; then bootrun=1 fi if [ -d /etc/runit/boot-run ] && [ ! -z $bootrun ]; then for f in /etc/runit/boot-run/*.sh; do [ -r "$f" ] && . "$f" done else /lib/runit/run_sysv_scripts '/etc/rcS.d' fi --- >8 --- On the one hand, '-z $bootrun' looks like an accident waiting to happen due to the missing quotes around "$bootrun". On the other, '[ ! -z "$bootrun" ]' and '[ -n "$bootrun ]' mean the same thing, so why do it two different ways within five lines? Furthermore, the two ifs seem redundant; I think the code would be more succinct and more readable the following way: --- 8< --- if [ -f /etc/runit/native.boot.run -o -n "$bootrun" ] && [ -d /etc/runit/boot-run ]; then bootrun=1 # set this because sourced scripts might use it, I guess (although they wouldn't get run if bootrun weren't set, so setting bootrun=1 looks completely superfluous) for f in /etc/runit/boot-run/*.sh; do [ -r "$f" ] && . "$f" done else /lib/runit/run_sysv_scripts '/etc/rcS.d' fi --- >8 --- I think this is equivalent with the exception that it only sets bootrun=1 if the /etc/runit/boot-run directory exists; but since nothing in the original script uses $bootrun, this doesn't seem to matter (and, as noted above, setting bootrun=1 seems completely redundant). András -- A conclusion is where you got tired of thinking.
Bug#1022103: gdisk: sgdisk produces only errors
Hi, unfortunately the bug is still not fixed despite the NMU; while sgdisk doesn't print errors anymore, it also doesn't actually perform the requested operations. See e.g. # sgdisk --zap-all /dev/sda Creating new GPT entries in memory. GPT data structures destroyed! You may now partition the disk using fdisk or other utilities. Looks good, but no partition table has actually been created: # parted -s /dev/sda print Error: /dev/sda: unrecognised disk label Model: VMware Virtual disk (scsi) Disk /dev/sda: 10.7GB Sector size (logical/physical): 512B/512B Partition Table: unknown Disk Flags: So let's create a partition table with parted and verify that it's there: # parted -s /dev/sda mklabel gpt # parted -s /dev/sda print Model: VMware Virtual disk (scsi) Disk /dev/sda: 10.7GB Sector size (logical/physical): 512B/512B Partition Table: gpt Disk Flags: Number Start End Size File system Name Flags Now let's try to create a partition with sgdisk: # sgdisk --set-alignment=1 --new=1:0:4M --typecode=1:EF02 --change-name=1:grub No error message, but the partition isn't there: # parted -s /dev/sda print Model: VMware Virtual disk (scsi) Disk /dev/sda: 10.7GB Sector size (logical/physical): 512B/512B Partition Table: gpt Disk Flags: Number Start End Size File system Name Flags Best regards, András -- Money can't buy friends, but you can afford a better class of enemy.
Bug#1022172: /lib/modprobe.d/50-nfs.conf causes initramfs-tools to stop including sunrpc module for nfs
On Fri, Oct 21, 2022 at 03:11:27PM +0200, Marco d'Itri wrote: Hi, > > I thought --ignore-install was completely broken, but no, because without > > it, the output contains *more* "install" lines: > What you are actually seeing is that --ignore-install is applied only to > the nfs module (the one which you have requested to load) but not to its > own dependencies: Yes, and this is in fact in agreement with the documentation: -i, --ignore-install, --ignore-remove This option causes modprobe to ignore install and remove commands in the configuration file (if any) *for the module specified on the command line (any dependent modules are still subject to commands set for them in the configuration file)*. This doesn't look like useful behaviour to me, but I don't pretend to be aware of all use-cases (the only one I *am* aware of is the one in mkinitramfs, which this behaviour breaks). Unfortunately the current output can't, as I see it, be parsed to obtain a list of dependencies, because the 'install' commands can be arbitrary command lines with arbitrary side effects, any of which might be loading a module that isn't even named in the command line. > No matter what happens to --ignore-install I suggest that nfs-kernel-server > will replace the modprobe configuration with some udev rules like this one > (untested): > > ACTION=="add", SUBSYSTEM=="module", KERNEL=="sunrpc", RUN+="/sbin/sysctl -q > --pattern sunrpc --system" I see several ways forward: 1. packages that obfuscate module dependencies by supplying 'install' commands for modules that other modules may depend on should be required to include initramfs (and dracut?) hooks that install all dependencies in the initramfs if a depending module is installed in it. This is arguably the correct solution; in the case of nfs-kernel-server, for example, the 'install' command wants to invoke sysctl --pattern, but the busybox sysctl installed in the initramfs by default doesn't support --pattern. So the package would need to force initramfs to include the /sbin/sysctl from procps, and maybe also any pertinent files from /etc/sysctl.d. 2. in addition to looking at modprobe output, mkinitramfs should also look at the depends: line in modinfo(8) output to find dependencies, and transitively close the set of modules it includes. This seems like a relatively easy workaround but it's not correct in that it won't cause /sbin/sysctl to be included even if an 'install' command calls it (or whatever other binary and configuration may be needed). 3. Debian could forbid including 'install' commands for modules that other modules depend on and that may (frequently?) need to be included in an initramfs (requiring, for example, the kind of udev rule Marco proposed). András -- The bride got a new name and a dress.
Bug#1022172: /lib/modprobe.d/50-nfs.conf causes initramfs-tools to stop including sunrpc module for nfs
Package: kmod
Version: 30+20220905-1
Severity: important
Hi,
I noticed that the sunrpc module was strangely absent from my initramfs, which
resulted in a failure to netboot (which is my justification for the severity).
Upon examination, it turns out that the way module dependencies are worked out
for initramfs generation depend on the output of this command:
# /sbin/modprobe --all --set-version="6.0.0-1-amd64" --ignore-install --quiet
--show-depends nfs
insmod /lib/modules/6.0.0-1-amd64/kernel/fs/netfs/netfs.ko
insmod /lib/modules/6.0.0-1-amd64/kernel/fs/fscache/fscache.ko
insmod /lib/modules/6.0.0-1-amd64/kernel/net/sunrpc/sunrpc.ko
insmod /lib/modules/6.0.0-1-amd64/kernel/fs/nfs_common/grace.ko
insmod /lib/modules/6.0.0-1-amd64/kernel/fs/lockd/lockd.ko
insmod /lib/modules/6.0.0-1-amd64/kernel/fs/nfs/nfs.ko
This, above, is what the output looked like with versions of nfs-kernel-server
before 1:2.6.2-1+b1, which didn't ship /lib/modprobe.d/50-nfs.conf.
With the new version of nfs-kernel-server, the output becomes:
# /sbin/modprobe --all --set-version="6.0.0-1-amd64" --ignore-install --quiet
--show-depends nfs
insmod /lib/modules/6.0.0-1-amd64/kernel/fs/netfs/netfs.ko
insmod /lib/modules/6.0.0-1-amd64/kernel/fs/fscache/fscache.ko
install /sbin/modprobe --ignore-install sunrpc $CMDLINE_OPTS && { /sbin/sysctl
-q --pattern sunrpc --system; exit 0; }
insmod /lib/modules/6.0.0-1-amd64/kernel/fs/nfs_common/grace.ko
install /sbin/modprobe --ignore-install lockd $CMDLINE_OPTS && { /sbin/sysctl
-q --pattern fs.nfs.n[sl]m --system; exit 0; }
insmod /lib/modules/6.0.0-1-amd64/kernel/fs/nfs/nfs.ko
This confuses manual_add_modules() from
/usr/share/initramfs-tools/hook-functions, which expects to only see insmod
lines, not install lines here.
I thought --ignore-install was completely broken, but no, because without it,
the output contains *more* "install" lines:
# /sbin/modprobe --all --set-version="6.0.0-1-amd64" --quiet --show-depends nfs
insmod /lib/modules/6.0.0-1-amd64/kernel/fs/netfs/netfs.ko
insmod /lib/modules/6.0.0-1-amd64/kernel/fs/fscache/fscache.ko
install /sbin/modprobe --ignore-install sunrpc $CMDLINE_OPTS && { /sbin/sysctl
-q --pattern sunrpc --system; exit 0; }
insmod /lib/modules/6.0.0-1-amd64/kernel/fs/nfs_common/grace.ko
install /sbin/modprobe --ignore-install lockd $CMDLINE_OPTS && { /sbin/sysctl
-q --pattern fs.nfs.n[sl]m --system; exit 0; }
install /sbin/modprobe --ignore-install nfs $CMDLINE_OPTS && { /sbin/sysctl -q
--pattern fs.nfs --system; exit 0; }
If the /lib/modprobe.d/50-nfs.conf shipped by nfs-kernel-server is valid, then
modprobe --ignore-install doesn't handle it correctly; if it's invalid, then I
suppose modprobe should print an error. There seems to be a problem with
modprobe either way, unless initramfs-tools misunderstands the purpose of
--ignore-install.
Best regards,
András
-- System Information:
Debian Release: bookworm/sid
APT prefers stable-security
APT policy: (500, 'stable-security'), (350, 'unstable'), (1, 'experimental')
merged-usr: no
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.17.15-caeeng (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=hu_HU.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8
Shell: /bin/sh linked to /bin/dash
Init: runit (via /run/runit.stopit)
LSM: AppArmor: enabled
--
Perl: The only language that looks the same before and after RSA encryption.
Bug#1016553: Recently (since early 2022?), broken terminal handling in LXC consoles (lxc-attach inside screen or tmux)
Package: joe Version: 4.6-1+b1 Severity: important Hi, as of recently, if I start screen (or tmux, doesn't seem to matter) on a Linux host, then use lxc-attach to enter a running LXC container, and start joe inside that container, the terminal behaves in a hard to describe, but completely broken way, making the editor essentially unusable. Some examples: 1. Subsequent lines appear concatenated and then broken at an off-by-one location. A file that contains <<< # # foo >>> would be rendered as <<< # [... spaces up to the end of the terminal line ... ] # foo >>> CTRL-R has no apparent effect. Enabling syntax highlighting seems to make it worse (mangling more lines), but not always. 2. When typing, the cursor keeps jumping back to column 2 or 3, and the typed characters are hidden, as if they were off-screen to the left. Pressing CTRL-R fixes this problem temporarily. After pressing CTRL-R, pressing END (but not ^E) repeatedly moves the cursor to somewhere around colum 40, but the column display in the upper right corner displays the correct position even after the first END press (or ^E press). 3. Similar to #2, but happens especially when editing a new file, or an empty line: instead of echoing the typed characters, either spaces echo, or the cursor stays at the leftmost position. If you can suggest a way for me to record what I see on the screen and the keys I press concurrently, I suppose I can produce a "movie" of the breakage. Other editors are unaffected (I tried vim, mcedit and nano). I can't reproduce the problem without screen or tmux (ssh host, lxc-attach container, joe works). I can't reproduce the problem if I start the container's joe binary by chrooting into the container's filesystem from the host. I can't reproduce the problem if I ssh into the container instead of entering it via lxc-attach, not even if I subsequently start screen inside the container and joe inside screen. I experimented with downgrading screen, ncurses, and joe itself, but either I wasn't systematic enough or it really didn't help. I experimented with using different terminal applications to ssh into the LXC host (xterm, konsole), and it seemed to make no difference. I *can* reproduce the problem by starting screen(1) locally, then ssh'ing into the LXC host, using lxc-attach, then starting joe inside the container. screen(1) sets my TERM to screen.xterm-256color. Setting TERM to just "screen" apparently fixes problem #1 but not the others. In tmux (whether started locally or on the LXC host doesn't matter), which sets TERM to "screen-256color", breakage #1 is less pronounced and slightly different: some lines are just visually missing their first character, but it's not rendered at the end of the previous line. The other two problems are just as in screen(1). If I start tmux locally, then ssh into the LXC host and start screen there, TERM is set to just "screen" but after lxc-attach, problem #1 is present again. As a demonstration, I opened a 150x47 terminal, reproduced problem #1, and used the X clipboard to copy and paste the contents of the window (with /etc/login.defs opened in joe) into this message below, disabling automatic line breaks: --- 8< --- IW /etc/login.defs Row 45 Col 1 Enable display of unknown usernames when login failures are recorded. # # WARNING: Unknown usernames may become world readable. # See #290803 and #298773 for details about how this could become a security # concern LOG_UNKFAIL_ENABno # # Enable logging of successful logins # LOG_OK_LOGINS no # # Enable "syslog" logging of su activity - in addition to sulog file logging. # SYSLOG_SG_ENAB does the same for newgrp and sg. # SYSLOG_SU_ENAB yes SYSLOG_SG_ENAB yes # # If defined, all su activity is logged to this file. #
Bug#1003225: on resume, tries to openat() mountpoint of remote nfs mounts that are not yet available, thus delaying network configuration
On Mon, Jul 11, 2022 at 10:47:26AM +0300, Martin-Éric Racine wrote: > On Thu, 6 Jan 2022 18:38:47 +0100 Michael Biebl wrote: > > On 06.01.22 17:26, Andras Korn wrote: > > > Package: systemd-timesyncd > > > Version: 249.7-1 > > > Severity: normal > > > Tags: upstream > > > > > > Hi, > > > > > > I noticed that it took a while for the network to become available after > > > my > > > laptop wakes up from suspend. > > > > > > I traced the problem to systemd-timesyncd. > > > > > > I use dhcpcd5, which ships /lib/dhcpcd/dhcpcd-hooks/64-timesyncd.conf, > which > > > contains the line "systemctl try-restart systemd-timesyncd.service || :". > > > > That file is not shipped by systemd. Why does it restart timesyncd? > > Why does it so blockingly? Why does it restart timesyncd when the > > network is still down? > > This is dhcpcd's attempt at adding the NTP servers received via DHCP options > to > timesyncd's configuration and restarting timesyncd to use them. This should > only happen once the network has been raised, though, since this is an exit > hook. Is there any particular reason you can't invoke systemctl with --no-block here? András -- Buy an atlas and see the world.
Bug#1014876: Please make it possible to override /etc/tmpreaper.conf from a user configfile
Package: tmpreaper Version: 1.6.17 Severity: wishlist Hi, I think you should add something like [ -r /etc/default/tmpreaper ] && . /etc/default/tmpreaper at the bottom of /etc/tmpreaper.conf. Currently, every upgrade that adds some new setting to tmpreaper.conf requires the user to re-edit the file if they had modified it -- either to re-add SHOWWARNING=false, or to add the new option (in the most recent case, RUNFROMCRON=true) to it. I happen to want to set SHOWWARNING=false AND RUNFROMCRON=true, and the suggested modification would make my life easier without, I think, breaking anything. Thanks András -- System Information: Debian Release: bookworm/sid APT prefers stable-security APT policy: (500, 'stable-security'), (350, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.17.15 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=hu_HU.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 Shell: /bin/sh linked to /bin/dash Init: runit (via /run/runit.stopit) LSM: AppArmor: enabled Versions of packages tmpreaper depends on: ii debconf [debconf-2.0] 1.5.79 ii libc6 2.33-7 ii libmount1 2.38-4devuan1 tmpreaper recommends no packages. tmpreaper suggests no packages. -- Configuration Files: /etc/tmpreaper.conf changed [not included] -- debconf information excluded -- Healthy people live longer - but they spend more time jogging.
Bug#1007205: Please consider (re)including my start-stop-daemon.runit script
On Thu, Mar 24, 2022 at 01:05:34AM +0100, Lorenzo wrote: > [1] I'll deal with this in a separate bug, but just to give you an idea: > why divert start-stop-daemon is better than diverting invoke-rc.d > and update-rc.d? Or, another example, why not abuse the ancient > policy-rc.d hack? I think it's better because start-stop-daemon is the common denominator. Diverting it will do the right thing even if someone invokes /etc/init.d/foo manually; the other solutions only affect well-written maintainer scripts. András -- Birthdays are good for you - the more you have the longer you live.
Bug#1007205: Please consider (re)including my start-stop-daemon.runit script
Sorry, naturally I found a typo in the script just after sending it: Index: start-stop-daemon.runit === --- start-stop-daemon.runit (revision 1347) +++ start-stop-daemon.runit (working copy) @@ -71,7 +71,7 @@ read -A cmdline
Bug#1007205: Please consider (re)including my start-stop-daemon.runit script
Package: runit
Version: 2.1.2-45
Severity: wishlist
Hi,
Back in 2012 I sent Gerrit a start-stop-daemon.runit script (see
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=678985) that could be used
as a drop-in replacement for the real start-stop-daemon. It's a fairly
feature complete wrapper around the real start-stop-daemon that manages
runit services if they are present and passes calls to the real
start-stop-daemon if they are not.
I dpkg-divert /sbin/start-stop-daemon to /sbin/start-stop-daemon.real on all
my systems and install this script as /sbin/start-stop-daemon.
This way, initscript work transparently whether a service is managed by
runit or not. Without this script, care must be taken to avoid the real
start-stop-daemon starting daemons like e.g. ntpd or smartd alongside a
runit-managed instance.
The script used to be included in runit under /usr/share/doc until Dmitry
removed in 2016 because it was "unused".
I think it can be useful even if the package doesn't use it explicitly, but
a case could be made for runit to perform this diversion on install and ship
my script as /sbin/start-stop-daemon.
The only drawback (that I can see) is that this would introduce a dependency
on zsh, because that's what I wrote the script in. Maybe Suggests: zsh, make
installing my script both optional and contingent on zsh being present? (Of
course, people could still shoot themselves in the foot by removing zsh
afterwards. Can dpkg run a trigger when zsh is uninstalled?)
I'm attaching the current version of the script, which contains some
improvements over the 2012 version.
András
--
Government corruption is always reported in the past tense.
#!/bin/zsh
#
# This script is intended to wrap start-stop-daemon. It will call the
# original start-stop-daemon with the supplied arguments unless the daemon
# to be started appears to exist as a runit service, in which case it will
# map the start-stop-daemon call to an sv(8) call.
#
# Copyright 2012-2022 András Korn.
#
# Licensed under the GPL v3, or, at your option, under the same license as
# the runit package.
# If called by non-root user, fall back to original start-stop-daemon
# unconditionally
[[ $UID -gt 0 ]] && exec /sbin/start-stop-daemon.real $@
set -A args $@
SVDIR=${SVDIR:-/etc/service}
unset mode signal exec timeout startas testmode oknodo quiet verbose command
svstat candidates
oknodo=0
quiet=0
typeset -U candidates
while [[ -n "$1" ]]; do
case "$1" in
-S|--start) mode=start;;
-K|--stop) mode=stop;;
-T|--status)mode=status;;
-H|--help|-V|--version) exec /sbin/start-stop-daemon.real
$args;;
-x|--exec) shift; exec="$1";
candidates=($candidates ${1:t});;
-s|--signal)shift; signal=$1;;
--signal=*) signal="${1/--signal=/}";;
-R|--retry) shift; timeout="$1";;
--retry=*) timeout="${1/--retry=/}";;
-a|--startas) shift; startas="$1"
candidates=($acndidates ${1:t});;
-t|--test) testmode=1;;
-o|--oknodo)oknodo=1;;
-q|--quiet) quiet=1; exec >/dev/null;;
-v|--verbose) verbose=1;;
-m|--make-pidfile) make_pidfile=1;;
--remove-pidfile) remove_pidfile=1;;
-n|--name) shift;
candidates=($candidates $1);;
-p|--pidfile) shift; pidfile="$1";
candidates=($candidates ${1:t:r});;
--pidfile=*)pidfile="${1#--pidfile=}";
candidates=($candidates ${1:t:r});;
-u|--user|-g|--group|--pid|--ppid|-c|--chuid|-r|--chroot|-d|--chdir|-O|--output|-N|--nicelevel|-P|--procsched|-I|--iosched|-k|--umask)
shift;; # ignored
-b|--background|--nicelevel=*|--procsched=*|--iosched=*|--umask=*|-C|--no-close)
:;; # ignored
--notify-wait) echo "Warning: this version of
start-stop-daemon.runit ignores --notify-wait." >&2;;
--notify-timeout) echo "Warning: this version of
start-stop-daemon.runit ignores --notify-timeout." >&2;;
--) break;; # What follows is args to the
daemon. Avoid parsing those accidentally.
*) command="$1"; break;; # Assume the
previous was the last option; the rest is the name of the daemon plus args, of
which we only care about the daemon.
esac
shift
done
# returns success if $1 appears to be the name of a runit service
function issvname() {
[[ -d "$SVDIR/$1/supervise/." ]] && return 0
# 'supervise' could still be a symlink to a directory that doesn't
exist yet
[[ -L
Bug#983726: runsv(8) incorrect regarding control/[dx]
On Thu, Feb 24, 2022 at 12:26:51PM +0100, Lorenzo wrote: > > However, if there were a natural-language explanation or flowchart, I > > think I could summarize it succinctly in a manner appropriate for the > > man page, within a day. > > > > Alas, that's all the help I can offer at the moment. > > > > András > > > > an attempt to fully explain the actual behavior is ( only for d, the > same goes for x) So I suggest the following: --- 8< --- CUSTOMIZE CONTROL For each control character c except "d" and "x" sent to the control pipe, runsv first checks if service/control/c exists and is executable. If so, it starts service/control/c and waits for it to terminate, before interpreting the command. If the program exits with return code 0, runsv refrains from sending the service the corresponding signal. The command o is always considered as command u. On command d first service/control/t is checked, and then service/control/d. On command x first service/control/t is checked, and then service/control/x. Specifically: If the service is running or paused, control characters "d" and "x" are handled as follows: 1. runsv checks whether control/t exists and is executable and runs it if yes. 2. If control/t exits nonzero, or is not executable or doesn't exist, runsv sends the service a TERM signal. 3. runsv sends the service a CONT signal, disregarding control/c even if it exists and is executable. 4. Runsv checks whether control/d (or control/x) exists and is executable and runs it if yes. Its exit status is ignored. The control of the optional log service cannot be customized. --- >8 --- I believe this is clear; I don't know if it's accurate. András -- Depression is merely anger without enthusiasm.
Bug#983726: runsv(8) incorrect regarding control/[dx]
On Tue, Feb 22, 2022 at 02:36:23PM +0100, Lorenzo wrote: > > On Mon, 19 Apr 2021 09:45:53 +0200 > > Andras Korn wrote: > > > > > Additionally, the documentation as it is now is clear and > > > straightforward, with few special cases; while the actual behaviour > > > of runsv, while I agree it can make sense, is more difficult to > > > explain clearly. > > --- ./runsv.8-orig 2022-01-03 03:00:49.0 +0100 > +++ ./runsv.8 2022-02-22 01:12:29.438824451 +0100 > @@ -185,16 +185,18 @@ > .IR u . > On command > .I d > -first > +first the service receives the TERM signal, subject to the > .I service\fR/control/t > -is checked, and then > -.I service\fR/control/d. > +check, then the service receives a CONT signal and finally > +.I service\fR/control/d > +is checked. > On command > .I x > -first > +first the service receives the TERM signal, subject to the > .I service\fR/control/t > -is checked, and then > -.I service\fR/control/x. > +check, then the service receives a CONT signal and finally > +.I service\fR/control/x > +is checked. > The control of the optional log service cannot be customized. > .SH SIGNALS > If > > > I'm not fully satisfied but it should at least make clear that you > can't prevent a TERM with control/[dx].. > Still doesn't tell that control/c is disregarded and that for > control/[dx] checked only means exists and is executable. Thanks for keeping tabs on this! Unfortunately it's been so long that I have trouble reconstructing what the actual behaviour (as opposed to the documented one) is, and I don't have time to reread the source code just now. However, if there were a natural-language explanation or flowchart, I think I could summarize it succinctly in a manner appropriate for the man page, within a day. Alas, that's all the help I can offer at the moment. András -- Well, to be Frank, I'd have to change my name.
Bug#665774: Messes up $PATH
FWIW, this is now fixed in the latest upstream master: https://github.com/dell/dkms/pull/193/commits/775a3389ebbafb4fb5d59747667e604cf4f4d903 András -- Crime is merely politics without the excuses.
Bug#1003225: on resume, tries to openat() mountpoint of remote nfs mounts that are not yet available, thus delaying network configuration
Package: systemd-timesyncd
Version: 249.7-1
Severity: normal
Tags: upstream
Hi,
I noticed that it took a while for the network to become available after my
laptop wakes up from suspend.
I traced the problem to systemd-timesyncd.
I use dhcpcd5, which ships /lib/dhcpcd/dhcpcd-hooks/64-timesyncd.conf, which
contains the line "systemctl try-restart systemd-timesyncd.service || :".
During this try-restart operation, a timesyncd process is started and hangs
for several seconds in D state for each nfs mountpoint that is unreachable.
(I'm attaching an strace log; the nfs server also exports
nfs-mountpoint-2/subdir to this client separately, so technically that's
nfs-mountpoint-3.)
dhcpcd5 doesn't continue setting up the network before the hook script
returns, but without the network, the hook script takes a long time to
finish.
I don't see why timesyncd has to try to openat() a directory on every
mountpoint. I assume this is due to some generic code it pulls in from maybe
libsystemd; if it can't be avoided, perhaps timesyncd should be started in a
restricted mount namespace that doesn't contain anything but the (local)
mountpoints it absolutely needs to function. (This would be desirable anyway
from a security perspective.) I'm not sure if this can also be done for
try-restart, though.
András
-- System Information:
Debian Release: bookworm/sid
APT prefers stable-security
APT policy: (500, 'stable-security'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.14.15-pf8-luna (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=hu_HU.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8
Shell: /bin/sh linked to /usr/bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
--
Good documentation is not written to satisfy a quota specified in cubic feet.
read(3, "REDACTED"..., 1024) = 1024 <0.20>
read(3, "REDACTED"..., 1024) = 1024 <0.22>
read(3, "REDACTED", 1024) = 18 <0.06>
read(3, "REDACTED", 1024) = 0 <0.06>
openat(AT_FDCWD, "/run/systemd/unit-root/run/credentials",
O_RDONLY|O_NOFOLLOW|O_CLOEXEC|O_PATH) =
4 <0.18>
mount(NULL, "/proc/self/fd/4", NULL,
MS_RDONLY|MS_NOSUID|MS_NODEV|MS_NOEXEC|MS_REMOUNT|MS_BIND, NULL) = 0 <0.11>
close(4) = 0 <0.08>
lseek(3, 0, SEEK_SET) = 0 <0.06>
read(3, "REDACTED"..., 1024) = 1024 <0.29>
lstat("/proc", {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0 <0.08>
lstat("/proc/self", {st_mode=S_IFLNK|0777, st_size=0, ...}) = 0 <0.06>
readlink("/proc/self", "63713", 4095) = 5 <0.06>
lstat("/proc/63713", {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0 <0.06>
lstat("/proc/63713/mountinfo", {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
<0.05>
read(3, "REDACTED"..., 1024) = 1024 <0.17>
read(3, "REDACTED"..., 1024) = 1024 <0.17>
read(3, "REDACTED"..., 1024) = 1024 <0.23>
read(3, "REDACTED"..., 1024) = 1024 <0.25>
read(3, "REDACTED"..., 1024) = 1024 <0.17>
read(3, "REDACTED"..., 1024) = 1024 <0.18>
read(3, "REDACTED"..., 1024) = 1024 <0.14>
read(3, "REDACTED"..., 1024) = 1024 <0.15>
read(3, "REDACTED"..., 1024) = 1024 <0.16>
read(3, "REDACTED"..., 1024) = 1024 <0.12>
read(3, "REDACTED"..., 1024) = 1024 <0.15>
read(3, "REDACTED"..., 1024) = 1024 <0.13>
read(3, "REDACTED"..., 1024) = 1024 <0.12>
read(3, "REDACTED"..., 1024) = 1024 <0.14>
read(3, "REDACTED", 1024) = 18 <0.05>
read(3, "REDACTED", 1024) = 0 <0.05>
lseek(3, 0, SEEK_SET) = 0 <0.05>
read(3, "REDACTED"..., 1024) = 1024 <0.18>
lstat("/proc", {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0 <0.06>
lstat("/proc/self", {st_mode=S_IFLNK|0777, st_size=0, ...}) = 0 <0.05>
readlink("/proc/self", "63713", 4095) = 5 <0.06>
lstat("/proc/63713", {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0 <0.06>
lstat("/proc/63713/mountinfo", {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
<0.05>
read(3, "REDACTED"..., 1024) = 1024 <0.20>
read(3, "REDACTED"..., 1024) = 1024 <0.15>
read(3, "REDACTED"..., 1024) = 1024 <0.16>
read(3, "REDACTED"..., 1024) = 1024 <0.17>
read(3, "REDACTED"..., 1024) = 1024 <0.13>
read(3, "REDACTED"..., 1024) = 1024 <0.15>
read(3, "REDACTED"..., 1024) = 1024 <0.14>
read(3, "REDACTED"..., 1024) = 1024 <0.15>
read(3, "REDACTED"..., 1024) = 1024 <0.16>
read(3, "REDACTED"..., 1024) = 1024 <0.11>
read(3, "REDACTED"..., 1024) = 1024 <0.14>
read(3, "REDACTED"..., 1024) = 1024 <0.12>
read(3, "REDACTED"..., 1024) = 1024 <0.12>
read(3, "REDACTED"..., 1024) = 1024 <0.14>
read(3, "REDACTED", 1024) = 18 <0.05>
read(3, "REDACTED", 1024) = 0 <0.05>
openat(AT_FDCWD, "/run/systemd/unit-root/run/systemd/incoming",
O_RDONLY|O_NOFOLLOW|O_CLOEXEC|O_PATH) =
4 <0.08>
mount(NULL, "/proc/self/fd/4", NULL,
MS_RDONLY|MS_NOSUID|MS_NODEV|MS_NOEXEC|MS_REMOUNT|MS_BIND, NULL)
Bug#1002733: Improve /sbin/runlevel for runlevels 0 and 6
On Thu, Jan 06, 2022 at 01:07:01AM +0100, lorenzo wrote: Hi, > > You now have two flag files and unconditinally use > > /lib/runit.runlevel.6 first if it exists, even if > > /lib/runit.runlevel.0 also exists and is newer. > > Please look at > https://salsa.debian.org/debian/runit/-/commit/2c56dadf15fef1bc809c00aec903970617aeb948 Yes, that's what I was looking at. > The flag file is /run/runit.runlevel.$LAST and /run is mounted as tmpfs > in Debian by default, so it's not persistent across reboots. > Am I loosing something relevant? Yes; I think you place too much faith in things being nice and clean and standard everywhere. :) In reality, I think people will have systems where /run isn't a tmpfs; they'll have homebrew scripts that muck around with the runit flag files in strange and wonderful ways; they'll initiate a reboot, then change their minds and try to shut down; they'll restore the contents of /run from a backup that accidentally included it; they'll syncrhonize it with another computer; etc. etc. Some computers are left running for years without rebooting, and may see a dozen new runit package versions being installed in the meantime (I'd be willing to bet there are still running runit instances that will look for /etc/runit/stopit instead of /run/runit.stopit). It's really impossible to anticipate all the kinds of messy environment your code will be expected to run in. Considering that 1. runit's philosphoy is to try to avoid race conditions and fragiliy arising from e.g. the use of PID files; and that 2. it's not terribly hard to get it right(er) by using the flag file that is most recent, I think it's worthwhile to do so. It certainly doesn't seem like a good idea to me to explicitly implement fragility (depending on /run being "clean"). > > (FWIW, I think the technically correct solution would be to have a > > "runit runlevel daemon": a simple process that provides a fifo to > > read the current runlevel from, and another fifo to write into when > > the runlevel changes; but this is overkill as the concept of a > > 'runlevel' is very rarely needed.) > > I see it in a different way: the proper solution here would have to have > a native set of runit boot and shutdown scripts, and drop most of the > Sysv compatibility. That's the high-maintenance solution, yes. However, in this particular case I think it's possible and worthwhile to achieve a limited but sufficient degree of compatibility (and to make it as robust in the face of unexpected messes as is possible without making it too complex). > I don't have time to maintain such set of scripts right now, so my > second best option is to use initscripts and keep some minimum level of > Sysv compatibility. Glad we're on the same page. :) András -- Dave, put down those Windows disks. Dave, please. DAVE! - HAL 9000
Bug#1002733: Improve /sbin/runlevel for runlevels 0 and 6
On Sun, Jan 02, 2022 at 11:45:27PM +0100, Lorenzo wrote: Hi, > > I'd argue that introducing stricter requirements on the existence and > > correct mode of /run/runit.reboot that apply over the whole uptime of > > the system is a more dangerous and invasive change than introducing a > > new control file with semantics that are obvious and well defined > > from the beginning. > > > >[ ...] > > The problem with this is that runit hasn't so far cared about the > > mode of runit.reboot before stage 3, and people may set runit.reboot > > to mode 100 early, for example out of a desire to make sure a box > > will reboot instead of shut down if pid 1 were to receive a CONT > > signal for any reason. > > Didn't thought about that: I'm not sure is a good idea but I'll > let the local admin have that call. > So I'm going with flag files, runit.runlevel.$LAST as you suggested > in your first message. Thanks, but that's not quite what I suggested. :) You now have two flag files and unconditinally use /lib/runit.runlevel.6 first if it exists, even if /lib/runit.runlevel.0 also exists and is newer. If you want one flag file per runlevel, I'd suggest something like #!/bin/sh ls -t /lib/runit.runlevel.[0-9] 2>/dev/null \ | sed 's@.*/@@g;s/^runit\.runlevel\.//;/^[0-9S]$/!d' \ | while read level; do exec printf "N $level" done exec printf 'N 2' (The ugly sed command makes sure we only print numbers even if some joker creates a file called literally '/lib/runit.runlevel.[0-9]'. The while loop makes sure we only execute the first printf if there was actually something to read.) I'm not sure this is better than using the first character of the contents of /lib/runit.runlevel, or making it a symlink instead of a file and using the first character of its target (we can also implement the former without depending on head(1)). (FWIW, I think the technically correct solution would be to have a "runit runlevel daemon": a simple process that provides a fifo to read the current runlevel from, and another fifo to write into when the runlevel changes; but this is overkill as the concept of a 'runlevel' is very rarely needed.) Best regards, András -- Aunt Em. Hate Kansas. Hate you. Took dog. Dorothy.
Bug#1002733: Improve /sbin/runlevel for runlevels 0 and 6
On Thu, Dec 30, 2021 at 10:02:55AM +0100, Andras Korn wrote: > On Wed, Dec 29, 2021 at 03:07:38AM +0100, Lorenzo wrote: > > > I'm going to accept a fix for this issue, but I prefer to not have to > > parse a file and also to not add another flag file only for this, if > > it's possible. > > Well, getting the first character from a file and printing it verbatim is > hardly "parsing". :) I gave this more thought. I hadn't considered that even /etc/runit/3 depends on /run/runit.reboot being present and having the correct mode. I checked the source of runit-init and it creates /run/runit.reboot if it doesn't exist, not just sets its mode. Thus, purely for the purpose of rebooting via kexec, depending on /run/runit.reboot existing and having the correct mode at the time /etc/runit/3 is executed seems adequate (even if technically racy). I still worry that by changing the behaviour of runlevel(8) so it depends on /run/runit.reboot will break something for someone somewhere, but I suppose you can say they broke it for themselves by fiddling with /run/runit.reboot. I can think of more convoluted ways of keeping track of the runlevel and reporting it, but I'll spare you. :) (Avoiding race conditions completely is not possible since no matter what we do, "check runlevel"; "do something based on runlevel" will never be an atomic operation in the kexec initscript. While technically correct is the best kind of correct, it's probably not worth it to aim for perfection in this instance.) András -- In the context of marriage, a moral victory is something you'll invariably end up celebrating on your own.
Bug#1002733: Improve /sbin/runlevel for runlevels 0 and 6
On Wed, Dec 29, 2021 at 03:07:38AM +0100, Lorenzo wrote: > I'm going to accept a fix for this issue, but I prefer to not have to > parse a file and also to not add another flag file only for this, if > it's possible. Well, getting the first character from a file and printing it verbatim is hardly "parsing". :) > > #!/bin/sh > > # /etc/runit/3 should update /run/runit.runlevel before starting stop > > scripts unset CURLEVEL > > CURLEVEL="$(head -c 1 /run/runit.runlevel 2>/dev/null)" > > if [ -z "$CURLEVEL" ]; then > > CURLEVEL=2 > > fi > > exec printf "N $CURLEVEL" > > > > Because of #1000867 I'm going to create /run/runit.reboot in stage1, > so can't we just use stat in runlevel script (at least for runlevel 6)? I thought of that, but I don't think it's quite this foolproof. kexec can be critical (for example, if you have an HP raid controller in a non-HP server, recent firmware versions hang during POST depending on BIOS settings, even before entering the BIOS setup, so kexec may be the only way to reboot without taking the computer apart first). You create /run/runit.reboot once at reboot, which could have been years ago; anything might have befallen that file in the meantime. For example, it may not exist anymore, and 'init 6' won't create it, just set its mode if it exists. So far nothing depended on runit.reboot existing and having a "correct" mode outside of runit stage 3. We have no idea what else (other than kexec) depends on the output of runlevel(8) and how. I'd argue that introducing stricter requirements on the existence and correct mode of /run/runit.reboot that apply over the whole uptime of the system is a more dangerous and invasive change than introducing a new control file with semantics that are obvious and well defined from the beginning. But, it's mostly your show: if that's how you want to do it, you obviously can. It'll work for me. > Something like > #!/bin/sh > if [ $(stat -c %a /run/runit.reboot) = 100 ]; then > exec printf 'N 6' > else > exec printf 'N 2' > fi The problem with this is that runit hasn't so far cared about the mode of runit.reboot before stage 3, and people may set runit.reboot to mode 100 early, for example out of a desire to make sure a box will reboot instead of shut down if pid 1 were to receive a CONT signal for any reason. Like I said, I think making the meaning of the mode bits of runit.reboot meaningful in a broader context is dangerous. > Will it work for kexec? It should. (You'll want a 2>/dev/null on the stat(1) invocation for cases where the file doesn't exist, /run isn't mounted etc.) > Also, do we have to cover the 'N 0' shutdown case because of some > other init scripts that you know of? I'm not aware of any, but then I didn't know about kexec a week ago, so this doesn't necessarily mean anything. :) András -- What if the lottery was just invented by the government to capture time travelers?
Bug#1002733: Improve /sbin/runlevel for runlevels 0 and 6
On Tue, Dec 28, 2021 at 03:16:30PM +0100, Andras Korn wrote: > If /sbin/runlevel looked like this instead: > > #!/bin/sh > # This only does anything useful if /etc/runit/3 updates /run/runit.runlevel > before starting stop scripts > if [ -s /run/runit.runlevel ]; then > CURLEVEL="$(head -c 1 /run/runit.runlevel)" > else > CURLEVEL=2 > fi > exec printf "N $CURLEVEL" It just occurred to me that technically the above is racy; a non-racy but less readable solution would be something like #!/bin/sh # /etc/runit/3 should update /run/runit.runlevel before starting stop scripts unset CURLEVEL CURLEVEL="$(head -c 1 /run/runit.runlevel 2>/dev/null)" if [ -z "$CURLEVEL" ]; then CURLEVEL=2 fi exec printf "N $CURLEVEL" András -- Expect disappointment and you won't be disappointed.
Bug#1002733: Improve /sbin/runlevel for runlevels 0 and 6
Package: runit-init
Version: 2.1.2-43
Severity: normal
Tags: patch upstream
Hi,
currently /sbin/runlevel always prints "2 N", which is fine most of the time.
However, runit can invoke initscripts that change behaviour based on
runlevel; for example, the kexec initscript from the kexec package has this:
if [ -d /run/systemd/system ]; then
systemctl list-jobs systemd-kexec.service | grep -q
systemd-kexec.service
if [ $? -ne 0 ]; then
exit 0
fi
else if [ -x /sbin/runlevel -a "$(runlevel | awk '{ print $2 }')" != "6" ];
then
exit 0
fi
fi
This means that when /etc/runit/3 invokes /etc/rc6.d/K??kexec, the
initscript will just exit instead of performing a kexec(8) and you end up with
a plain reboot.
If /sbin/runlevel looked like this instead:
#!/bin/sh
# This only does anything useful if /etc/runit/3 updates /run/runit.runlevel
before starting stop scripts
if [ -s /run/runit.runlevel ]; then
CURLEVEL="$(head -c 1 /run/runit.runlevel)"
else
CURLEVEL=2
fi
exec printf "N $CURLEVEL"
And the following patch were applied to /etc/runit/3:
--- a/3 2021-12-28 15:03:01.179691038 +0100
+++ b/3 2021-12-28 15:03:30.266943564 +0100
@@ -9,6 +9,7 @@
# executable bit set on 'noexec' filesystem as executable, and /run
# often is mounted as 'noexec'.
[ $(stat -c %a /run/runit.reboot) = 100 ] && LAST=6
+printf "$LAST" >/run/runit.runlevel
echo 'Waiting for services to stop...'
sv force-stop /etc/service/*
Then the kexec package would work.
If you're willing to accept this patch I can also update the runlevel(8)
manpage.
I'm also fine with /etc/runit/3 creating /run/runit.runlevel.$LAST and
/sbin/runlevel checking for those in some order (this would avoid calling
head(1) in /sbin/runlevel), if you prefer.
András
Ps. incidentally, happy new year!
-- System Information:
Architecture: amd64 (x86_64)
Init: runit (via /run/runit.stopit)
--
I'm sure if Vimes were to say 'Jump!', Detritus would say 'What colour?'
Bug#993602: /etc/runit/nosync should not have been moved to /run
On Sat, Sep 04, 2021 at 05:38:50PM +0200, lorenzo wrote: > > Not wanting to invoke sync() on shutdown is a permanent property of a > > system, not an ephemeral one. Thus, the flag file for this behaviour > > should be in a permanent location (like /etc/runit, where it > > originally was), not under /run, where it would need to be created on > > every boot. > > The only issue with reverting to /etc is that as long as /etc is mounted > readonly it will not be possible to write this file: but as the use > case is a container I guess the file will be written during the > container setup, before runtime, right? Exactly. This isn't something you need to change at runtime, ever. A case could even be made for runit to automatically skip sync in containers, but considering runit's minimalist design, that'd be creeping featurism. Best regards, András -- Ha a vasutallomas az, ahol a vasut megall, akkor a munkaallomas...
Bug#942382: A living fork of dstat seems to be available
Package: dstat Version: 0.7.4-6.1 Followup-For: Bug #942382 Hi, there seems to be a fork of dstat called dool, with some recent commits indicating that it's still being developed: https://github.com/scottchiefbaker/dool While unfortunately, #942382 is still present in it, maybe Debian could switch to this fork from the archived original dstat codebase? Best regards, András -- System Information: Debian Release: 11.0 APT prefers unstable APT policy: (350, 'unstable'), (350, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-8-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=hu_HU.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 Shell: /bin/sh linked to /bin/bash Init: runit (via /run/runit.stopit) LSM: AppArmor: enabled Versions of packages dstat depends on: ii python3 3.9.2-3 ii python3-six 1.16.0-2 dstat recommends no packages. dstat suggests no packages. -- no debconf information -- My cold is better this morning; I've been practising all night.
Bug#993602: /etc/runit/nosync should not have been moved to /run
Package: runit Version: 2.1.2-42 Severity: normal Hi, I'm the guy who originally submitted the patch to support a 'nosync' flag file to avoid syncing on shutdown. I noted with some amazement in the changelog for version 2.1.2-42 that this file had been moved to /run sometime in the past, with no mention in the changelog. I think this change should be reverted. The use case of the nosync flag file is when running runit in a container like LXC or linux-vserver. When you stop one of these (or hundreds of these simultaneously), you don't want them to sync() because the host itself isn't stopping, so there is neither a need nor a benefit to invoking sync(). Not wanting to invoke sync() on shutdown is a permanent property of a system, not an ephemeral one. Thus, the flag file for this behaviour should be in a permanent location (like /etc/runit, where it originally was), not under /run, where it would need to be created on every boot. Best regards, András -- System Information: Debian Release: 11.0 APT prefers unstable APT policy: (350, 'unstable'), (350, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-8-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=hu_HU.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 Shell: /bin/sh linked to /bin/bash Init: runit (via /run/runit.stopit) LSM: AppArmor: enabled -- A computer's attention span is as long as it's power cord.
Bug#991896: New upstream version 2.1.0 available
Package: zfs-dkms Version: 2.0.3-9 Severity: wishlist Hi, https://github.com/openzfs/zfs/releases/tag/zfs-2.1.0 has been out for more than a month. It would be great if it could be packaged for Debian because it contains many interesting new features. Thanks! -- System Information: Debian Release: 11.0 APT prefers unstable APT policy: (350, 'unstable'), (350, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-6-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=hu_HU.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 Shell: /bin/sh linked to /bin/bash Init: runit (via /run/runit.stopit) LSM: AppArmor: enabled
Bug#978065: lxc: After upgrade lxc to 4.0.5-1, cannot start with lxc.cap.drop sys_admin
On Fri, Jun 11, 2021 at 09:59:51PM +0200, Pierre-Elliott Bécue wrote: Hi, > > FWIW, both host and guest use runit, so systemd is not involved; runit > > doesn't interfere with cgroups or capabilities on its own in any way. > > It's not possible if the init in the container is systemd, as far as I > know. That's as may be, but my systems don't use systemd; like I said above, it's all runit. I'm still hitting the issue. András -- Mary had a little lamb, she tied it to a pylon. A thousand volts went up its ass and turned it into Nylon.
Bug#987266: preinst check for kernel release > 255 may no longer be needed
Package: libc6 Version: 2.31-11 Severity: normal Hi, due to https://salsa.debian.org/glibc-team/glibc/-/commit/6ddfa57577af0d96df9ddd7be401f5ce9a9bcc0f (a commit from 2004) the preinst script for glibc checks whether the "z" in the "x.y.z" of the kernel version is less than 255. If yes, the package refuses to install. I hit this problem on a box with a custom 4.9.266 kernel. Based on this lkml thread: https://lore.kernel.org/lkml/7pR0YCctzN9phpuEChlL7_SS6auHOM80bZBcGBTZPuMkc6XjKw7HUXf9vZUPi-IaV2gTtsRVXgywQbja8xpzjGRDGWJsVYSGQN5sNuX1yaQ=@protonmail.com/T/, the check is no longer needed because the kernel caps the version code it reports to 255, even if uname prints a higher number. Of course, you could conceivably still hit the problem with earlier kernels, so I suppose the logic of the check should be modified, not removed entirely, to be technically correct. If forced at gunpoint to make a guess, I would guess, though, that removing the check would have very little actual impact; it also doesn't protect the user from installing a kernel with an unsupported version number after having installed glibc. Best regards, András -- A ham sandwich is better than nothing. Nothing is better than eternal happiness. So a ham sandwich is better than eternal happiness.
Bug#983726: runsv(8) incorrect regarding control/[dx]
On Sat, Apr 10, 2021 at 11:11:05PM +0200, Lorenzo wrote: Hi, > > runsv(8) says: > > > > CUSTOMIZE CONTROL > >For each control character c sent to the control pipe, runsv > > first checks if service/control/c exists and is executable. If so, it > >starts service/control/c and waits for it to terminate, before > >interpreting the command. If the program exits with return > > code 0, runsv refrains from sending the service the corresponding > > signal. The command o is always considered as command u. On command d > > first service/control/t is checked, and then service/control/d. On > > command x first service/control/t is checked, and then > > service/control/x. The control of the optional log service cannot be > > customized. > > > > This is, however, not what the code actually does. > > > > [ ... ] > > > > i.e. the control/d or control/x script is only run after runsv sent > > its child a SIGTERM, not before as the manpage suggests. > > Right. Also it looks that with control/[dx] an override on the CONT > signal is disregarded. It's reasonable but it should be documented too. > > > > > I would suggest that the code should be changed to reflect the > > documented behaviour, not vice versa. > > Ideally Gerrit Pape should make a call on this, but it's not > happening, so: > Could you elaborate more on why you want to update the code instead of > fixing the manpage? > > If you add an override for the TERM signal it would be run before [dx], > so what you want is a way to do a custom action that is not run when > the service receives a plain TERM signal but is run only when runsv is > told to set the service down or to exit. > Do you have an example/use case for this? Nothing specific; I was basing my recommendation on the following: * this code and documentation has been around for a long time; * this part of the code is relatively rarely used; * there are likely setups that were created on the assumption that the documentation was correct, but not tested extensively (I know I'm guilty of this). (I have, of course, no idea how many setups exist that rely on the existing but undocumented behaviour.) Additionally, the documentation as it is now is clear and straightforward, with few special cases; while the actual behaviour of runsv, while I agree it can make sense, is more difficult to explain clearly. In the case of runsv, I suppose I see the manpage as a specification for, not an explanation of, what the code does. All of these arguments are weak. The main point is that the documentation should accurately reflect what the code does; I realize that fixing the documentation is easier. I also see the merit in your arguments. > > Credits to https://serverfault.com/users/135556/keith for pointing > > the bug out. > > I can only see some info about the reporter profile, do you have a link > where I can read what was the reporter complaining of? Sure. In https://serverfault.com/questions/612458/runit-does-not-kill-process-on-sv-stop-or-sv-reload/625822, someone was looking for a way to stop child processes of a runit-supervised service on service shutdown. I suggested a custom 'd' script, and "Keith" pointed out the discrepancy between the documentation and the code in a his comment https://serverfault.com/questions/612458/runit-does-not-kill-process-on-sv-stop-or-sv-reload/625822#comment1375192_625822. (It's also true that in this specific case, the poster would need a 't' script in addition to the 'd' script even if the documentation were correct; otherwise 'sv t' would still leave his sub-processes around.) Best regards, András -- To whom the gods destroy, they first teach Windows...
Bug#983726: runsv(8) incorrect regarding control/[dx]
Package: runit
Version: 2.1.2-39.1
Severity: normal
Tags: upstream
Hi,
runsv(8) says:
CUSTOMIZE CONTROL
For each control character c sent to the control pipe, runsv first
checks if service/control/c exists and is executable. If so, it
starts service/control/c and waits for it to terminate, before
interpreting the command. If the program exits with return code 0,
runsv refrains from sending the service the corresponding signal. The
command o is always considered as command u. On command d first
service/control/t is checked, and then service/control/d. On command
x first service/control/t is checked, and then service/control/x. The
control of the optional log service cannot be customized.
This is, however, not what the code actually does.
For the 'd' control character
(https://github.com/vulk-archive/runit/blob/master/src/runsv.c#L324):
case 'd': /* down */
s->want =W_DOWN;
update_status(s);
if (s->state == S_RUN) stopservice(s);
break;
'x' is handled analogously.
The stopservice() function
(https://github.com/vulk-archive/runit/blob/master/src/runsv.c#L246) looks like
this:
void stopservice(struct svdir *s) {
if (s->pid && ! custom(s, 't')) {
kill(s->pid, SIGTERM);
s->ctrl |=C_TERM;
update_status(s);
}
if (s->want == W_DOWN) {
kill(s->pid, SIGCONT);
custom(s, 'd'); return;
}
if (s->want == W_EXIT) {
kill(s->pid, SIGCONT);
custom(s, 'x');
}
}
i.e. the control/d or control/x script is only run after runsv sent its child a
SIGTERM, not before as the manpage suggests.
I would suggest that the code should be changed to reflect the documented
behaviour, not vice versa. Perhaps the following code would work (but I have
not tested it):
void stopservice(struct svdir *s) {
if (s->pid) {
if (s->want == W_DOWN) {
kill(s->pid, SIGCONT);
if (custom(s, 'd')) return;
}
if (s->want == W_EXIT) {
kill(s->pid, SIGCONT);
if (custom(s, 'x')) return;
}
if (! custom(s, 't')) {
kill(s->pid, SIGTERM);
s->ctrl |=C_TERM;
update_status(s);
}
}
}
Credits to https://serverfault.com/users/135556/keith for pointing the bug out.
Best regards,
András
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable
APT policy: (350, 'unstable'), (350, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.10.0-3-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=hu_HU.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8
Shell: /bin/sh linked to /bin/bash
Init: runit (via /run/runit.stopit)
LSM: AppArmor: enabled
Versions of packages runit depends on:
ii libc6 2.31-9
ii sysuser-helper 1.3.5.1
Versions of packages runit recommends:
ii runit-init 2.1.2-39.1
Versions of packages runit suggests:
ii socklog 2.1.0+repack-4+b1
-- Configuration Files:
/etc/runit/1 changed [not included]
/etc/runit/2 changed [not included]
/etc/runit/3 changed [not included]
-- no debconf information
--
Laughing stock: cattle with a sense of humour.
Bug#978065: lxc: After upgrade lxc to 4.0.5-1, cannot start with lxc.cap.drop sys_admin
Hi,
I hit the same issue.
I upgraded from 1:4.0.4-6 to 1:4.0.5-2, and from kernel 5.9.0-4-amd64 to
5.10.0-2-amd64, and some of my containers that used to work before don't work
anyomre. The ones that still work don't drop sys_admin.
stracing lxc-start I see this:
openat2(33, "/sys/fs/cgroup",
{flags=O_RDONLY|O_CLOEXEC|O_PATH,
resolve=RESOLVE_NO_XDEV|RESOLVE_NO_MAGICLINKS|RESOLVE_NO_SYMLINKS|RESOLVE_BENEATH},
24) = -1 EXDEV (Invalid cross-device link)
The corresponding message from lxc-start with loglevel debug is:
lxc-start unifiadmin 20210125231743.129 ERRORconf -
conf.c:lxc_mount_auto_mounts:727 - Invalid cross-device link - Failed to mount
"/sys/fs/cgroup"
Some context from lxc-start log output:
lxc-start unifiadmin 20210125231742.854 INFO start - start.c:lxc_init:837 -
Container "unifiadmin" is initialized
lxc-start unifiadmin 20210125231742.876 WARN cgfsng -
cgroups/cgfsng.c:mkdir_eexist_on_last:1152 - File exists - Failed to create
directory "/sys/fs/cgroup/cpuset//lxc.monitor.unifiadmin"
lxc-start unifiadmin 20210125231742.886 INFO cgfsng -
cgroups/cgfsng.c:cgfsng_monitor_create:1368 - The monitor process uses
"lxc.monitor.unifiadmin" as cgroup
lxc-start unifiadmin 20210125231742.904 WARN cgfsng -
cgroups/cgfsng.c:mkdir_eexist_on_last:1152 - File exists - Failed to create
directory "/sys/fs/cgroup/cpuset//lxc.payload.unifiadmin"
lxc-start unifiadmin 20210125231742.916 INFO cgfsng -
cgroups/cgfsng.c:cgfsng_payload_create:1471 - The container process uses
"lxc.payload.unifiadmin" as cgroup
lxc-start unifiadmin 20210125231742.944 INFO start - start.c:lxc_spawn:1700
- Cloned CLONE_NEWNS
lxc-start unifiadmin 20210125231742.944 INFO start - start.c:lxc_spawn:1700
- Cloned CLONE_NEWPID
lxc-start unifiadmin 20210125231742.945 INFO start - start.c:lxc_spawn:1700
- Cloned CLONE_NEWUTS
lxc-start unifiadmin 20210125231742.945 INFO start - start.c:lxc_spawn:1700
- Cloned CLONE_NEWIPC
lxc-start unifiadmin 20210125231742.945 INFO start - start.c:lxc_spawn:1700
- Cloned CLONE_NEWNET
lxc-start unifiadmin 20210125231742.945 DEBUGstart -
start.c:lxc_try_preserve_namespaces:166 - Preserved mnt namespace via fd 31
lxc-start unifiadmin 20210125231742.945 DEBUGstart -
start.c:lxc_try_preserve_namespaces:166 - Preserved pid namespace via fd 32
lxc-start unifiadmin 20210125231742.946 DEBUGstart -
start.c:lxc_try_preserve_namespaces:166 - Preserved uts namespace via fd 33
lxc-start unifiadmin 20210125231742.946 DEBUGstart -
start.c:lxc_try_preserve_namespaces:166 - Preserved ipc namespace via fd 34
lxc-start unifiadmin 20210125231742.946 DEBUGstart -
start.c:lxc_try_preserve_namespaces:166 - Preserved net namespace via fd 35
lxc-start unifiadmin 20210125231742.949 INFO cgfsng -
cgroups/cgfsng.c:cgfsng_setup_limits_legacy:2881 - Limits for the legacy cgroup
hierarchies have been setup
lxc-start unifiadmin 20210125231742.955 WARN cgfsng -
cgroups/cgfsng.c:cgfsng_setup_limits:2942 - Invalid argument - Ignoring cgroup2
limits on legacy cgroup system
lxc-start unifiadmin 20210125231743.315 INFO network -
network.c:instantiate_veth:285 - Retrieved mtu 1500 from intra
lxc-start unifiadmin 20210125231743.666 INFO network -
network.c:instantiate_veth:333 - Attached "veth-unifi" to bridge "intra"
lxc-start unifiadmin 20210125231743.687 DEBUGnetwork -
network.c:instantiate_veth:449 - Instantiated veth tunnel "veth-unifi <-->
vethv7jzuF"
lxc-start unifiadmin 20210125231743.699 WARN start - start.c:do_start:1166
- Using /dev/null from the host for container init's standard file descriptors.
Migration will not work
lxc-start unifiadmin 20210125231743.704 INFO start - start.c:do_start:1198
- Unshared CLONE_NEWCGROUP
lxc-start unifiadmin 20210125231743.731 DEBUGstorage -
storage/storage.c:get_storage_by_name:211 - Detected rootfs type "dir"
lxc-start unifiadmin 20210125231743.734 DEBUGconf -
conf.c:lxc_mount_rootfs:1259 - Mounted rootfs "/var/lib/lxc/unifiadmin/rootfs"
onto "/usr/lib/x86_64-linux-gnu/lxc/rootfs" with options "(null)"
lxc-start unifiadmin 20210125231743.738 INFO conf -
conf.c:setup_utsname:751 - Set hostname to "unifiadmin"
lxc-start unifiadmin 20210125231743.740 DEBUGnetwork -
network.c:lxc_network_setup_in_child_namespaces_common:3510 - Network device ""
has been setup
lxc-start unifiadmin 20210125231743.977 DEBUGnetwork -
network.c:setup_hw_addr:3360 - Mac address "00:16:3e:11:22:33" on "eth0" has
been setup
lxc-start unifiadmin 20210125231743.103 DEBUGnetwork -
network.c:lxc_network_setup_in_child_namespaces_common:3510 - Network device
"eth0" has been setup
lxc-start unifiadmin 20210125231743.103 INFO network -
network.c:lxc_setup_network_in_child_namespaces:3532 - Network has been setup
lxc-start unifiadmin 20210125231743.116 DEBUGconf - conf.c:mount_entry:1943
- Remounting "/shared/cache/apt/lists" on
Bug#979995: There should be a sensible compile time default for the location of the file that contains trusted CA certificates
On Wed, Jan 13, 2021 at 05:12:39PM -0800, Ryan Tandy wrote: Hi, > > Can you somehow make the library complain very loudly when an attempt is > > made to use CACERTDIR, but the setting is ignored? > > This is not sarcastic, but a good faith question: if it had printed > something to stderr, would you have seen it? Yes. I have sssd logging to stderr and use svlogd to write the messages to files. Whatever the library printed on stderr would have appeared among the sssd log messages. > I don't think I have any way to > make something appear in (for example) sssd's own log file. Probably not. The realistic alternatives are stderr and syslog. > In fact, it does already log a warning, but I suppose most applications > using the library probably don't enable any log level. Exactly. I had to use an (at the time) undocumented setting to turn up libldap debugging in sssd to see what was going on. > https://git.openldap.org/openldap/openldap/-/blob/OPENLDAP_REL_ENG_2_4/libraries/libldap/tls_g.c#L187-190 Yes, this is the warning I eventually saw, once I knew where to look. Since a configuration where no CA certificates are trusted and you still try to use TLS is unlikely to be useful, I think a loud warning to stderr would be appropriate in this case. > On Wed, Jan 13, 2021 at 01:44:07PM +0100, Andras Korn wrote: > > OK, looking further, part of the problem is that I didn't have > > libldap-common installed, thus no /etc/ldap/ldap.conf. > > > > Since this (and the accompanying manpage) is all that libldap-common > > contains: what's the rationale for having these in a separate package? > > Policy 8.2: "If your package contains files whose names do not change with > each change in the library shared object version, you must not put them in > the shared library package." Okay, that makes sense. :( I'm not sure what a good solution would be. It doesn't seem appropriate to Depends on libldap-common, because libldap can definitely be used without it; on the other hand, Debian does have sensible defaults for CAECERT & co, but those are only enabled when the user installs a package that's merely Recommended and thus easily missed. As a user, my expectation would be not to have to configure CACERT* for distribution packages, because the distribution has a well-known location for system-wide trusted CA certificates; I would expect all packages to default to using that. The status quo appears to violate the principle of least surprise. > > The libldap package only Recommends libldap-common (which is why I didn't > > have it); however, it is libldap-common that enables the sensible defaults. > > > > Why shouldn't libldap come with the sensible defaults itself? > > It's your decision whether to install Recommends or not, but AFAIK it's > generally not considered a bug if some feature or behaviour is missing when > Recommends are not installed. I don't think it's worthwhile to debate whether this is technically a bug or not; it's an unfortunate situation, and I hope there is some way we (well, mostly you and the other maintainers) can improve it. > Why isn't the default in the code of libldap → this is upstream's decision, > and I won't introduce a Debian-local change to override it, sorry. In fact, it seems wrong that these defaults (and configuration) should be specific to libldap; to me it would seem appropriate for Debian to ship libgnutls so that by default it uses the CA certificate store of the distribution. The upstream default of not trusting any certificates by default makes sense for the upstream project, but not, IMO, for a distribution that's expected to be integrated and self-consistent. András -- Optimist: Someone who doesn't know all the facts yet.
Bug#979995: There should be a sensible compile time default for the location of the file that contains trusted CA certificates
On Tue, Jan 12, 2021 at 10:47:22AM -0800, Ryan Tandy wrote: > > On 2021-01-12 Andras Korn wrote: > > > I think I shouldn't need to specify `ldap_tls_cacert = > > > /etc/ssl/certs/ca-certificates.crt` when using a Debian package, since > > > this is the default location of trusted CA certificates in Debian. > > > Configuration should only be necessary for non-default setups. > > The libldap-common package ships a default /etc/ldap/ldap.conf which > contains exactly this default TLS_CACERT value. It should be picked up > automatically by programs using the library. If sssd does something to > override that, I don't think libldap can be blamed. OK, looking further, part of the problem is that I didn't have libldap-common installed, thus no /etc/ldap/ldap.conf. Since this (and the accompanying manpage) is all that libldap-common contains: what's the rationale for having these in a separate package? The libldap package only Recommends libldap-common (which is why I didn't have it); however, it is libldap-common that enables the sensible defaults. Why shouldn't libldap come with the sensible defaults itself? András -- For Sale: parachute, used once, never opened, small stain.
Bug#979995: There should be a sensible compile time default for the location of the file that contains trusted CA certificates
On Tue, Jan 12, 2021 at 10:47:22AM -0800, Ryan Tandy wrote: Hi, thanks for clearing up some misunderstandings. > On Tue, Jan 12, 2021 at 07:04:41PM +0100, Andreas Metzler wrote: > > On 2021-01-12 Andras Korn wrote: > > > I think I shouldn't need to specify `ldap_tls_cacert = > > > /etc/ssl/certs/ca-certificates.crt` when using a Debian package, since > > > this is the default location of trusted CA certificates in Debian. > > > Configuration should only be necessary for non-default setups. > > The libldap-common package ships a default /etc/ldap/ldap.conf which > contains exactly this default TLS_CACERT value. It should be picked up > automatically by programs using the library. If sssd does something to > override that, I don't think libldap can be blamed. > > > GnuTLS offers a sane compile default for the trust store (See > > gnutls_x509_trust_list_add_system_trust()), which can be used by the > > application. - I have therefore retitled the bug. > > > > From the upstream bug report: > > 2021-01-12 17:52:00.657730500 [be[ldap]] [sss_ldap_debug] (0x4000): > > libldap: TLS: warning: cacertdir not implemented for gnutls > > > > GnuTLS has supported using a directory instead of a file since version > > 3.3.6 (released 2014-07-23), so it looks like a missing thing in libldap. > > There are two things here: > > 1. libldap 2.4.x indeed does not support TLS_CACERTDIR when linked with > GnuTLS. This is fixed in the 2.5 branch. (ITS#8155) > > 2. It is intentional by upstream that *no* CA certificates are used when > there is no explicit TLS_CACERT or TLS_CACERTDIR configured. There's some > discussion about this in ITS#5582. (Bearing in mind that in Debian we *do* > configure a default TLS_CACERT in ldap.conf). > > <https://bugs.openldap.org/show_bug.cgi?id=5582> > > Is there still something you think needs to be changed or fixed in the > libldap package? I'm not sure. Can you somehow make the library complain very loudly when an attempt is made to use CACERTDIR, but the setting is ignored? The sssd issue was very hard to trobuleshoot because initially all I saw after a dist-upgrade was "unknown error". András -- If debugging is removing bugs, then programming must be putting them in.
Bug#979995: There should be a sensible compile time default for the location of the file that contains trusted CA certificates
Package: libgnutls30 Version: 3.7.0-3 Severity: wishlist Hi, I was just bitten by https://github.com/SSSD/sssd/issues/5444. Briefly: * sssd relies on libldap to query LDAP servers. * libldap can be linked against libssl (openssl) or gnutls for SSL/TLS support. * libssl supports an ldap_tls_cacertdir option; you can point it to /etc/ssl/certs and it'll trust all CA certificates that are in this directory. * gnutls doesn't have this cacertdir mechanism and needs `ldap_tls_cacert = /etc/ssl/certs/ca-certificates.crt` instead. * my sssd.conf only had ldap_tls_cacertdir, not ldap_tls_cacert; thus, gnutls didn't know which CA certificates to trust and failed to validate my LDAP server certificates. * The root cause of the problem only became visible after enabling LDAP library debugging in sssd.conf. I think I shouldn't need to specify `ldap_tls_cacert = /etc/ssl/certs/ca-certificates.crt` when using a Debian package, since this is the default location of trusted CA certificates in Debian. Configuration should only be necessary for non-default setups. Best regards, András -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (350, 'unstable'), (350, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Init: runit (via /run/runit.stopit) -- no debconf information
Bug#977600: Please don't conflict with other log daemons
Package: socklog Version: 2.1.0-8.1 Severity: normal Hi, it's entirely valid and possible to run socklog to handle locally generated logs and e.g. syslog-ng to handle remote syslog clients. The new Conflicts: in the socklog package makes this unnecessarily hard in an attempt to prevent people from shooting themselves in the foot. Please also see #506173 and #893882. At the extreme, there could be a socklog-bin package that only provides the binaries with no configuration, no automatic service startup; and a socklog package which retains the Conflicts and Depends on socklog-bin. Thanks! András -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (350, 'unstable'), (350, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.4.244-vs2.3.9.9 (SMP w/8 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=hu_HU.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 Shell: /bin/sh linked to /bin/bash Init: runit (via /run/runit.stopit) Versions of packages socklog depends on: ii adduser 3.118 ii libc62.31-4 Versions of packages socklog recommends: ii ipsvd1.0.0-3.1+b1 ii runit2.1.2-36 pn socklog-run socklog suggests no packages. -- no debconf information
Bug#975437: Regression: no longer accepts '--splitting process' or '--secure-splitting'
Package: clsync
Version: 0.4.5-1
Severity: normal
Hi,
with clsync 0.4.2-1, the documented "--splitting process" or
"--splitting=process" argument worked.
In the current version, it gives the error message
Error: argument "process" can't be parsed as a number
Error: Unable to process option "splitting" (with argument: "process") from
"cli_arguments"
Similarly, --secure-splitting is not recognized:
clsync: unrecognized option '--secure-splitting'
However, the manpage documents it:
SECURITY OPTIONS
--secure-splitting
Implies "--splitting=process --check-execvp-arguments
--seccomp-filter --forbid-devices"
Confusingly, --splitting *will* accept a numerical argument, but it's unclear
what it'll do.
Looking through the changelog, I think it's disabling seccomp support that
broke these options. Indeed, the source confirms it, at least for
secure-splitting:
# ifdef SECCOMP_SUPPORT
{"secure-splitting",no_argument,NULL,
SECURESPLITTING},
# endif
Can't you disable seccomp support only for the architectures where it's not
usable?
Thanks and best regards,
András
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable
APT policy: (350, 'unstable'), (350, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.4.244-vs2.3.9.9 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=hu_HU.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8
Shell: /bin/sh linked to /bin/bash
Init: runit (via /run/runit.stopit)
Versions of packages clsync depends on:
ii init-system-helpers 1.58+devuan1
ii libc62.31-4
ii libcgroup1 0.41-10
ii libglib2.0-0 2.66.3-1
ii lsb-base 11.1.0
Versions of packages clsync recommends:
ii rsync 3.2.3-2
clsync suggests no packages.
-- no debconf information
--
Life is complex. It consists of real and imaginary parts.
Bug#954343: Error message 'Unable to parse package file (1)' unhelpful
On Sat, Mar 21, 2020 at 10:34:24AM +0100, David Kalnischkies wrote: > On Fri, Mar 20, 2020 at 03:41:06PM +0100, Andras Korn wrote: > > with the sources.list entry: > > > > deb http://winswitch.org/beta/ buster main > > While the error message certainly doesn't help much, I have to highlight > that this repository is currently broken. Looks like a mistake in their > transition from python2 to python3 guessing by all the "b'…'" currently in > https://winswitch.org/beta/buster/Release > > apt refuses such a Release file by default as insecure (missing Date, > missing all hashes, … due to the incorrect field names), have you > perhaps forced it to go along anyhow? I did. I don't doubt that the repository is broken (even though it happens to work with older apt); I think the messages apt prints for broken repositories should make it easier to diagnose the problem. In this case, apt did complain about weak security (I don't have the exact wording anymore, and the repository seems fixed), but that's not so unusual for 3rd party repositories. Best regards, András -- A soldier who survived mustard gas and pepper spray is a seasoned veteran.
Bug#954343: Error message 'Unable to parse package file (1)' unhelpful
Package: apt Version: 2.0.0 Severity: normal Hi, with the sources.list entry: deb http://winswitch.org/beta/ buster main apt-get as of 2.0 update prints the unhelpful error message: E: Unable to parse package file (1) apt 1.8.4 has no problem with this repository. I could only find out which sources.list entry was causing the issue by way of successive elimination. I would suggest the following: 1. identify the type of file in the message (e.g. Packages file, Release file, whatever); 'package file' is vague. 2. in the message, identify the sources.list entry the problematic file is related to. 3. the message should say why the file in question could not be parsed; at the very least, print the number of the line where the problem was encountered. Thanks! András -- There will be a rain dance Friday, weather permitting. -- System Information: Debian Release: bullseye/sid Architecture: amd64 (x86_64) Foreign Architectures: i386 Locale: LANG=en_US.UTF-8, LC_CTYPE=hu_HU.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: runit (via /run/runit.stopit)
Bug#945442: Possible to backspace past beginning of string, which appears to be identical to having pressed Enter immediately, without any backspace
On Mon, Mar 02, 2020 at 01:45:26PM -0500, Marvin Renich wrote: Hi, > I don't have a github account, and do not wish to get one for this. > Will someone (Debian maintainer for neomutt, or someone else interested > in this bug) please file this with upstream as a separate bug, pointing > out that the other github issue is not the same as this bug, even though > some of the same code may be involved. I filed https://github.com/neomutt/neomutt/issues/2161. Best regards, András -- Microsoft follows standards the same way fish follow migrating caribou.
Bug#945442: Possible to backspace past beginning of string, which appears to be identical to having pressed Enter immediately, without any backspace
On Mon, Mar 02, 2020 at 03:18:54PM +0100, Andreas Henriksson wrote: > > Your rationale for downgrading the severity of an issue like this is that it > > doesn't bother you personally? > > My rationale, if you must know, is that if this is an important issue, > then the people who consider it an important issue will ofcourse work on > getting it fixed. I'm curious -- what exactly do you have in mind? How should the users bothered by this bug "work on it"? What would you consider a reasonable, acceptable level of effort? > There's nothing in debian policy (the document who defines the severity > levels for the bug tracking system) that says 'If you raise the severity > of a bug report then "someone else" has to do the work for you'. Nobody "has" to "do the work". It's just that if the work is not done, the issue stays open. If it meets the definition of a "grave" bug, then it stays grave. You're right in that if it's important enough for *the right people*, then it'll get fixed eventually. It's entirely possible that the the users affected by a bug are not the right ones to effect a fix. You can argue with the severity, but I don't think you should downgrade it for frivolous reasons like "I'm not interested in fixing it", or "I don't like the attitude of a commenter; I think they're being lazy." > Scratch your own itch. Sorry, no, that's not how this works. I'll scratch my own itch if/when I can, and also the itches of others if/when I can. This is not a bug I can realistically fix, but that doesn't affect either its severity or its existence. You don't get to downgrade a bug that meets the criteria for being "grave" just because you aren't personally affected by it, or because the user who reported it (or someone who commented on it) is unable or unwilling to fix it himself/herself. I'm sure you don't need me to tell you that. > The previously provided suggestion that this might lead to data loss is > a bit far fetched if you ask me. That's a valid argument. FWIW, I have no opinion. I filed the bug with a normal priority and won't insist on it being grave. If you think you can downgrade it for the right reasons, go ahead (as far as I'm concerned). Best regards, András -- Get married and share the problems you didn't know you had.
Bug#945442: Possible to backspace past beginning of string, which appears to be identical to having pressed Enter immediately, without any backspace
On Mon, Mar 02, 2020 at 02:22:44PM +0100, Andreas Henriksson wrote: Hi, > > when mutt prompts for something (e.g. To: address, Subject etc.) it > > previously was possible to just keep pressing backspace until whatever > > default text was there disappeared. > > > > As of this version, it's possible to keep erasing back beyond the first > > character of the string; > [...] > > On Fri, Feb 14, 2020 at 11:31:53AM -0500, Marvin Renich wrote: > > Control: -1 severity grave > > > > I'm increasing the severity of this bug, as it can cause unintended > [...] > > I just NMUed a new upstream version of neomutt, 20191207+dfsg.1-1, > which fixes the two other outstanding RC bugs. > It seems I can still reproduce this issue however (with the first prompt > I get which is the imap password prompt for me). > > This seems somewhat like a possible UX design fail. This is done > upstream and not in debian. Do you know if there's already been any > discussion regarding this upstream? If not could you please file an > upstream bug report about this? https://github.com/neomutt/neomutt/issues/2002 > The behaviour hasn't really bothered me and I probably wouldn't even > have noticed it if it wasn't for this bug showing up on the RC bug radar > while doing my NMU, so I'm quite tempted to downgrade severity again. Your rationale for downgrading the severity of an issue like this is that it doesn't bother you personally? Best regards, András -- My wife said I needed to grow up. I was speechless. It's hard to say anything when you have 45 gummy bears in your mouth.
Bug#951841: New upstream version available
Package: rawtherapee Version: 5.7-1 Severity: wishlist Hi, 5.8 was released on February 4. Please package it. No packaging changes seem necessary from 5.7 (at first glance). Thanks! András -- System Information: Init: runit (via /run/runit.stopit)
Bug#951457: Please ship gdbm module
Package: zsh Version: 5.7.1-1+b1 Severity: wishlist Hi, zshmodules(1) mentions the "zsh/db/gdbm" module, but it's not actually shipped by the package: % zmodload zsh/db/gdbm zsh: failed to load module `zsh/db/gdbm': /usr/lib/x86_64-linux-gnu/zsh/5.7.1/zsh/db/gdbm.so: cannot open shared object file: No such file or directory I suppose (paraphrasing xkcd) this module is like a blockchain or a grappling hook: if you encounter a situation where it's the right solution, it's very cool, but it happens rarely. :) I think I have just found such a situation and was disappointed to see that the gdbm module wasn't available. Thanks András -- Package-specific info: Packages which depend, recommend, suggest or enhance a zsh package and hence may provide code meant to be sourced in .zshrc: Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-==---=== ii grml-etc-core 0.16.1 all core etcetera files for the Grml system ii grml-scripts 2.9.0amd64Collection of little tools The following files were modified: /etc/minimal-shellrc -- System Information: Debian Release: 10.0 APT prefers unstable Architecture: amd64 (x86_64) Foreign Architectures: i386 Init: runit (via /run/runit.stopit) Versions of packages zsh depends on: ii libc6 2.29-3 ii libcap2 1:2.27-1 ii libtinfo6 6.1+20191019-1 ii zsh-common 5.7.1-1 Versions of packages zsh recommends: ii libc6 2.29-3 ii libncursesw6 6.1+20191019-1 ii libpcre3 2:8.39-12+b1 Versions of packages zsh suggests: pn zsh-doc -- no debconf information
Bug#951192: Missing German localization
Package: trac Version: 1.2.3+dfsg-1 Severity: normal Tags: l10n Hi, trac 1.2 contained /usr/lib/python2.7/dist-packages/trac/locale/de, but trac 1.2.3+dfsg-1 no longer does. This, naturally, breaks German localization. The cause is likely this (happens during package build): catalog trac/locale/de/LC_MESSAGES/tracini.po is marked as fuzzy, skipping catalog trac/locale/de/LC_MESSAGES/messages-js.po is marked as fuzzy, skipping catalog trac/locale/de/LC_MESSAGES/messages.po is marked as fuzzy, skipping Wouldn't a fuzzy catalog be better than no catalog? András -- System Information: Init: runit (via /run/runit.stopit)
Bug#951061: linux_vserver detection broken, easy fix
Package: virt-what
Version: 1.19-1
Severity: normal
Tags: patch
Hi,
This is broken in two ways:
# Check for Linux-VServer
if test -e "${root}/proc/self/status" \
&& cat "${root}/proc/self/status" | grep -q "VxID: [0-9]*"; then
echo linux_vserver
if grep -q "VxID: 0$" "${root}/proc/self/status"; then
echo linux_vserver-host
else
echo linux_vserver-guest
fi
fi
1. The regex should be "VxID:[[:space:]]+[1-9][0-9]*" (and use egrep), since
different versions of the linux-vserver patch may use different amounts and
kinds of whitespace in /proc/self/status.
2. linux_vserver-host should never be printed. The host is not running
virtualized; printing that virtualization is available just confuses scripts
that need to detect whether they're running on bare metal or not. When not
running virtualized, the script should print nothing.
It's also inconsistent: the script (naturally) doesn't print anything if the
box would be capable of running kvm guests (whether it's currently running
any or not).
Thus, the code above should be changed to this:
# Check for Linux-VServer
if test -e "${root}/proc/self/status" \
&& egrep -q "VxID:[[:space:]]+[1-9][0-9]*"; then
echo linux_vserver-guest
fi
Best regards,
András
-- System Information:
Debian Release: 10.0
APT prefers unstable
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.4.206-vs2.3.9.8 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=hu_HU.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: runit (via /run/runit.stopit)
Versions of packages virt-what depends on:
ii dmidecode 3.2-2
ii libc6 2.29-3
virt-what recommends no packages.
virt-what suggests no packages.
-- no debconf information
--
Help Wanted: Telepath. You know where to apply.
Bug#947952: dpkg-repack compatibility: (optionally?) remove deleted files from /var/lib/dpkg/pkgname.list
Package: localepurge Version: 0.7.3.8 Severity: wishlist Hi, dpkg-repack fails when localepurge is in use (see #947951). If dpkg-repack doesn't get fixed, a possible workaround would be to have localepurge remove entries from /var/lib/dpkg/pkgname.list as it deletes the files. I'm not sure how that would work with --path-exclude. Thanks! András -- System Information: Debian Release: 10.0 APT prefers stable APT policy: (350, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.4.207-vs2.3.9.8 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=hu_HU.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: runit (via /run/runit.stopit) Versions of packages localepurge depends on: ii debconf [debconf-2.0] 1.5.73 ii locales2.29-6 ii perl 5.30.0-9 ii procps 2:3.3.12-3+devuan2.1 ii ucf3.0038+nmu1 localepurge recommends no packages. Versions of packages localepurge suggests: pn bleachbit ii debfoster 2.7-2.1+b1 ii deborphan 1.7.32 -- debconf information excluded -- Always address your elders with respect; they could leave you a fortune.
Bug#947951: Fails if packages pruned by localepurge
Package: dpkg-repack
Version: 1.46
Severity: normal
Hi,
the localepurge package can be used to automatically remove unneeded locale
files (and thereby conserve disk space as well as inodes).
dpkg-repack used to just print warnings for non-existent files, but
currently it fails on such packages and only prints a vague warning, e.g.:
dpkg-repack: warning: problems found processing kde-style-breeze, the package
may be broken
In fact, no actual .deb is generated at all; the dpkg build directory is
missing DEBIAN/control.
Please do one or more of the following:
1. turn this error into a warning again (in line 248, replace 'error("cannot
find file '$fn'")' with 'warning("cannot find file '$fn'")').
2. make sure the actual error message is printed, in addition to the vague
warning; also, make it clear that no .deb was generated and that dpkg-repack
exits unsuccessfully.
3. make this behaviour depend on a command line option; e.g.
--ignore-missing-files, or --ignore-missing-locale, or --fail-on-missing-files
or whatever.
I would argue that if files are missing, the generated .deb should just not
contain them. After all, dpkg-repack's description says "dpkg-repack creates
a .deb file out of a package that has already been installed. If any changes
have been made to the package while it was unpacked (i.e. files in /etc were
modified), the new package will inherit the changes.
This utility can make it easy to copy packages from one computer to another,
or to recreate packages that are installed on your system, but no longer
available elsewhere, or to store the current state of a package before you
upgrade it."
Removing files represents "changes made to the package" that dpkg-repack
should preserve.
Whether the .list file should include the missing files or not is an
interesting question, but irrelevant for my use case (backup before
upgrade); I think it would be better to include them if possible, because
then if you install the generated .deb, it's still obvious that those files
are missing from it.
Best regards,
András
-- System Information:
Debian Release: 10.0
APT prefers stable
APT policy: (350, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.4.207-vs2.3.9.8 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=hu_HU.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: runit (via /run/runit.stopit)
Versions of packages dpkg-repack depends on:
ii libdpkg-perl 1.19.7
ii perl 5.30.0-9
dpkg-repack recommends no packages.
Versions of packages dpkg-repack suggests:
ii fakeroot 1.24-1
-- no debconf information
--
The important thing is that we are moving forward - never mind the direction.
Bug#945442: Possible to backspace past beginning of string, which appears to be identical to having pressed Enter immediately, without any backspace
Package: neomutt
Version: 2019+dfsg.1-1
Severity: normal
Hi,
when mutt prompts for something (e.g. To: address, Subject etc.) it
previously was possibly to just keep pressing backspace until whatever
default text was there disappeared.
As of this version, it's possible to keep erasing back beyond the first
character of the string; for example, when composing mail, backspacing
beyond the beginning of the offered Subject brings up the editor
with the message being composed; saving and exiting shows that the Subject
is in fact not empty but the default (e.g. "Re: original subject").
Backspacing beyond the beginning of the To: prompt likewise confirms the
default To: address and goes to the Subject prompt.
This behaviour is completely counter-intuitive and hopefully not
intentional.
I can reproduce it with mutt -F /dev/null, leading me to beleive it's not a
problem with my configuration.
Andras
-- Package-specific info:
NeoMutt 2019
Copyright (C) 1996-2016 Michael R. Elkins and others.
NeoMutt comes with ABSOLUTELY NO WARRANTY; for details type 'neomutt -vv'.
NeoMutt is free software, and you are welcome to redistribute it
under certain conditions; type 'neomutt -vv' for details.
System: Linux 4.4.185-vs2.3.9.8+uksm (x86_64)
ncurses: ncurses 6.1.20191019 (compiled with 6.1.20191019)
libidn: 1.33 (compiled with 1.33)
GPGme: 1.13.1-unknown
hcache backends: tokyocabinet
Compiler:
Using built-in specs.
COLLECT_GCC=cc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/9/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:hsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 9.2.1-19'
--with-bugurl=file:///usr/share/doc/gcc-9/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,gm2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-9
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib
--with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch
--disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none,hsa --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 9.2.1 20191109 (Debian 9.2.1-19)
Configure options: --build=x86_64-linux-gnu --prefix=/usr
{--includedir=${prefix}/include} {--mandir=${prefix}/share/man}
{--infodir=${prefix}/share/info} --sysconfdir=/etc --localstatedir=/var
--disable-silent-rules {--libdir=${prefix}/lib/x86_64-linux-gnu}
{--libexecdir=${prefix}/lib/x86_64-linux-gnu} --disable-maintainer-mode
--disable-dependency-tracking --mandir=/usr/share/man --libexecdir=/usr/libexec
--with-mailpath=/var/mail --gpgme --lua --notmuch --with-ui --gnutls --gss
--idn --mixmaster --sasl --tokyocabinet
Compilation CFLAGS: -g -O2
-fdebug-prefix-map=/build/neomutt-jdVSn8/neomutt-2019+dfsg.1=.
-fstack-protector-strong -Wformat -Werror=format-security -std=c99
-D_ALL_SOURCE=1 -D_GNU_SOURCE=1 -D__EXTENSIONS__ -I/usr/include
-I/usr/include/lua5.3 -DNCURSES_WIDECHAR -isystem /usr/include/mit-krb5
Default options:
+attach_headers_color +compose_to_sender +compress +cond_date +debug
+encrypt_to_self +forgotten_attachments +forwref +ifdef +imap +index_color
+initials +limit_current_thread +multiple_fcc +nested_if +new_mail +nntp +pop
+progress +quasi_delete +regcomp +reply_with_xorig +sensible_browser +sidebar
+skip_quoted +smtp +status_color +timeout +tls_sni +trash
Compile options:
-autocrypt +bkgdset +color +curs_set +fcntl -flock -fmemopen +futimens
+getaddrinfo +gnutls +gpgme +gss +hcache -homespool +idn +inotify
-locales_hack +lua +meta +mixmaster +nls +notmuch -openssl +pgp +sasl +smime
-sqlite +start_color +sun_attachment +typeahead
MAILPATH="/var/mail"
MIXMASTER="mixmaster"
PKGDATADIR="/usr/share/neomutt"
SENDMAIL="/usr/sbin/sendmail"
SYSCONFDIR="/etc"
To learn more about NeoMutt, visit: https://neomutt.org
If you find a bug in NeoMutt, please raise an issue at:
https://github.com/neomutt/neomutt/issues
or send an email to:
-- System Information:
Debian Release: 10.0
APT prefers unstable
APT policy: (350, 'unstable'), (350, 'stable'), (98, 'eoan-updates'), (98,
'eoan-security'), (98, 'eoan-proposed'), (98, 'eoan-backports'), (98, 'eoan'),
(1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.4.185-vs2.3.9.8+uksm (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=hu_HU.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Bug#930869: Please keep pm-utils
Hi, I just stumbled on this bugreport. I'm a happy pm-utils user and would like the package to stick around. I use it on dozens of computers ranging from servers to desktops to laptops. >From reading the bugreport, there doesn't appear to be any identifiable, specific, actionable reason for removing it, does there? Thanks! András -- Days since last off-by-one incident: -1
Bug#248496: missing font 8x16
Hi, I just encountered the same problem. I'm fairly certain the root cause is that the game assumes some specific named font is available, and fails when it isn't (i.e. missing dependency). I looked at it using xtruss (https://www.chiark.greenend.org.uk/~sgtatham/xtruss/) and it seems to try to use a font called "8x16": OpenFont(fid=f#0463, name="8x16") ChangeGC(gc=g#0462, foreground=0x, background=0x, font=f#0463) ChangeWindowAttributes(window=w#0461, event-mask=Exposure) ConfigureWindow(window=w#0461, stack-mode=Above) MapWindow(window=w#0461) ... OpenFont(fid=f#0463, name="8x16") = BadName ... ChangeGC(gc=g#0462, foreground=0x, background=0x, font=f#0463) = BadFont(font=f#) --- Expose(window=w#0461, x=0, y=0, width=1, height=1, count=0) X Error of failed request: BadName (named color or font does not exist) Major opcode of failed request: 45 (X_OpenFont) Serial number of failed request: 27 Current serial number in output stream: 31 I have no idea how to provide the game with the required font; the xfonts-base package, which contains /usr/share/fonts/X11/misc/8x16.pcf.gz, is installed, fwiw. HTH. Andras -- The trouble with political humor is that so many jokes are elected.
Bug#930803: new program: runcached
On Wed, Jun 26, 2019 at 12:18:25PM +0200, Andras Korn wrote: > > > I just wrote this script: > > > https://gist.github.com/akorn/51ee2fe7d36fa139723c851d87e56096 and thought > > > it might be a good addition to moreutils. > > > > > > It caches the stdout, stderr and exit status of arbitrary commands for a > > > configurable length of time, returning data from cache on subsequent > > > invocations if the cache is still fresh. > > > > thanks for your suggestion; I think it's quite an interesting idea! > > And you made me curious: which commands are you running through > > 'runcached'? All programs I thought of have their basic functionality > > based on side-effects as file system or network access. > > Examples: > > * I have a Makefile to regenerate the data.cdb file for tinydns whenever >any of the local source files changed. Part of the process is downloading >some remote DNS zones with axfr-get, which is relatively slow. The remote >zones don't change frequently; I don't want to download them each time, >but I do want to download them at least once every eight hours or so. So >I run axfr-get via runcached, with a cache ttl of 8 hours. > > * Some monitoring systems like Zabbix and Munin need to run data-gathering >stuff that is time-consuming; it sometimes happens that several plugins >need to run the same thing, but extract different data from its output. >Instead of having separate, ad-hoc caching in all such plugins, it's >better to have a generic caching solution. > > * When looking for space hogs in the filesystem, I often use >'du -hscx * .* | sort -h' and then dig down further. Without runcached >I would have to either save the output separately, or keep opening new >sessions in screen(1), or wait for the same output to be generated again, >when I go up to the higher level directory again. With runcached, `du` is >cheap the 2nd time, and I don't care if the numbers are slightly off when >they come from the cache. > > * Same for ad-hoc log analysis sessions: I may grep through a bunch of >logs, then grep for something else, then grep for the same thing again. >With runcached, I don't need to worry about saving output I may need >again, because runcached does it for me. * Oh, and ldapsearch. I have some scheduled scripts that each do something to members of the same group; before, I had an ad-hoc cache for group members, but with runcached I can just re-run ldapsearch with the same arguments and get cached results. András -- Win any staring contest: slowly go in for a kiss without breaking eye contact.
Bug#930803: new program: runcached
On Tue, Jun 25, 2019 at 08:22:12PM +0200, Nicolas Schier wrote: Hi, > > I just wrote this script: > > https://gist.github.com/akorn/51ee2fe7d36fa139723c851d87e56096 and thought > > it might be a good addition to moreutils. > > > > It caches the stdout, stderr and exit status of arbitrary commands for a > > configurable length of time, returning data from cache on subsequent > > invocations if the cache is still fresh. > > thanks for your suggestion; I think it's quite an interesting idea! > And you made me curious: which commands are you running through > 'runcached'? All programs I thought of have their basic functionality > based on side-effects as file system or network access. Examples: * I have a Makefile to regenerate the data.cdb file for tinydns whenever any of the local source files changed. Part of the process is downloading some remote DNS zones with axfr-get, which is relatively slow. The remote zones don't change frequently; I don't want to download them each time, but I do want to download them at least once every eight hours or so. So I run axfr-get via runcached, with a cache ttl of 8 hours. * Some monitoring systems like Zabbix and Munin need to run data-gathering stuff that is time-consuming; it sometimes happens that several plugins need to run the same thing, but extract different data from its output. Instead of having separate, ad-hoc caching in all such plugins, it's better to have a generic caching solution. * When looking for space hogs in the filesystem, I often use 'du -hscx * .* | sort -h' and then dig down further. Without runcached I would have to either save the output separately, or keep opening new sessions in screen(1), or wait for the same output to be generated again, when I go up to the higher level directory again. With runcached, `du` is cheap the 2nd time, and I don't care if the numbers are slightly off when they come from the cache. * Same for ad-hoc log analysis sessions: I may grep through a bunch of logs, then grep for something else, then grep for the same thing again. With runcached, I don't need to worry about saving output I may need again, because runcached does it for me. > > It currently has semi-esoteric dependencies: it's written in zsh and uses > > chpst from the runit package for locking. If you're willing to include the > > script I can change it to use flock(1) instead, but I'm not rewriting it in > > POSIX sh. > > Adding new scripts to the moreutils collection is usually done by > forwarding to the upstream maintainer (Joey Hess ) and > asking for script inclusion. But, as Joey keeps more than just one eye > on cross platform compatibility, I expect non-POSIX implementations to > be rejected. Do you keep your non-POSIX statement? I modified it to use zsh's system module for locking, but I'm sticking with zsh; I have no interest in rewriting it in plain Bourne sh. zsh isn't much less cross-platform than, say, perl or Python. The --prune-cache functionality probably depends on GNU find(1). I'm offering the script in the belief that it might be useful to others, but getting it into moreutils is no priority for me. > Did you think about the license you want to stick it to? GPL2+? I was thinking GPLv3+, but if the rest of moreutils is GPL2+, I'm fine with that too. András -- A synonym is a word you use when you can't spell the other one.
Bug#930803: new program: runcached
Package: moreutils Version: 0.62-1 Severity: wishlist Hi, I just wrote this script: https://gist.github.com/akorn/51ee2fe7d36fa139723c851d87e56096 and thought it might be a good addition to moreutils. It caches the stdout, stderr and exit status of arbitrary commands for a configurable length of time, returning data from cache on subsequent invocations if the cache is still fresh. It currently has semi-esoteric dependencies: it's written in zsh and uses chpst from the runit package for locking. If you're willing to include the script I can change it to use flock(1) instead, but I'm not rewriting it in POSIX sh. Best regards, András -- Want to make using your computer? hold shift and press '4' four times.
Bug#927480: Performance: if an fs reports EOPNOTSUPP for xattr/acl calls, don't keep trying
Package: rsync Version: 3.1.3-6 Severity: wishlist Tags: upstream Hi, according to strace -c, getxattr() and similar calls can take up a lot of runtime (around ten percent) if there are many files to be synced and other stuff (I/O, network) is reasonably fast. It would make sense for rsync to skip such calls for files on a filesystem that replied with EOPNOTSUPP and save some time. The stat() family of calls tell rsync which fs the file is on, so that you just need to wrap the ACL/xattr calls in a wrapper that checks whether the fs in question is known to not support ACLs/xattrs before calling the actual syscall/library function. Counterarguments: 1. "don't call rsync with -AX if your fs doesn't support ACLs/xattrs". Apparently valid, but maybe I'm syncing a huge tree with more than one mountpoint, and some of the mounted filesystems support ACLs/xattrs while others don't. 2. it's possible for an fs to be remounted with ACL/xattr support while rsync is running; if my suggestion were implemented, rsync could miss some ACLs/xattrs. My response to that is "don't do that then". :) András -- I spilled spot remover on my dog, and now he's gone!
Bug#919699: Please support -w switch to halt(8)
On Tue, Mar 12, 2019 at 06:37:45PM +, Dmitry Bogatov wrote:
Hi,
> [2019-03-11 16:24] Lorenzo Puliti
> > Package: runit-init
> > Version: 2.1.2-25helpers1
> > Followup-For: Bug #919699
> >
> > Hi,
> >
> > >I am okay with accepting patch to implement writing `wtmp' entry, if it
> > >is reasonably small, but I would prefer to delegate it to external
> > >implementation, like https://git.suckless.org/utmp (not sure it is
> > >applicable).
> >
> > Just in case you don't know, there is already a 'sac' package that include a
> > 'writetmp - write special wtmp entries to a wtmp file.' program.
> >
> > https://packages.debian.org/sid/sac
> >
> > The only thing is that last sac release is dated around Dec 2004 and last
> > update of the Debian sac package is from Dec 2011, otherwise it looks the
> > right external tool.
>
> Just noticed, that bin:runit too provides tool for wtmp -- utmpset(8).
> But it expects 'line' argument, and I do not know, what is correct value
> for it.
>
> halt.c from src:sysvinit pass '~~' as line, but utmpset(8) rejects such
> usage. Any advice?
Indeed, sysvinit's halt.c does this:
write_wtmp("shutdown", "~~", 0, RUN_LVL, "~~");
and write_wtmp looks like this (some irrelevant lines omitted, some
commentary added):
void write_wtmp(
char *user, /* name of user */
char *id, /* inittab ID */
int pid,/* PID of process */
int type, /* TYPE of entry */
char *line) /* Which line is this */
{
int fd;
struct utmp utmp;
struct utsname uname_buf;
struct timeval tv;
/* [...] */
memset(, 0, sizeof(utmp));
#if defined(__GLIBC__)
gettimeofday(, NULL);
utmp.ut_tv.tv_sec = tv.tv_sec;
utmp.ut_tv.tv_usec = tv.tv_usec;
#else
time(_time);
#endif
utmp.ut_pid = pid;
utmp.ut_type = type;
strncpy(utmp.ut_name, user, sizeof(utmp.ut_name));
strncpy(utmp.ut_id , id , sizeof(utmp.ut_id ));
strncpy(utmp.ut_line, line, sizeof(utmp.ut_line));
/* Put the OS version in place of the hostname */
if (uname(_buf) == 0)
strncpy(utmp.ut_host, uname_buf.release, sizeof(utmp.ut_host));
#if HAVE_UPDWTMP
updwtmp(WTMP_FILE, ); /* Linux, NetBSD, Solaris etc. have updwtmp
*/
#else
write(fd, (char *), sizeof(utmp)); /* fallback */
#endif
close(fd);
}
In contrast, utmpset.c from runit does:
/* [...] */
if (utmp_logout(*argv) == -1)
strerr_die4x(111, WARNING, "unable to logout line ", *argv,
" in utmp: no such entry");
if (wtmp)
if (wtmp_logout(*argv) == -1)
strerr_die4sys(111, WARNING,
"unable to logout line ", *argv, " in wtmp: ");
utmp_logout() tries to find a matching login entry, and since there is none,
it returns an error; thus, wtmp_logout is never called.
I tried to put the wtmp_logout() call above the utmp_logout() call, and
stepped through the wtmp_logout() function with gdb; it succeeds and writes
a record to wtmp, but it's in the wrong format.
Examining the code in wtmp_logout(), it seems it sets ut_type to
DEAD_PROCESS unconditionally, but it would need to be RUN_LVL; also, it
doesn't set ut_user or ut_id.
I have to conclude that utmpset is incapable of generating a shutdown
record.
I think that, as a minimum, 'halt -w' should become a no-op and exit
successfully immediately. Ideally, it should generate a valid
shutdown/reboot record the way halt.c from sysvinit does.
If you're short on time, I would suggest that you immediately change your
shutdown.c to just exit cleanly if '-w' is passed on the command line (as
per your existing patch), and wait for someone to send a patch to generate a
valid shutdown record. Since, as you can see above, the code to do that is
minimal, I'm not sure it makes sense to call an external program for it,
adding a dependency.
András
--
God heals, but always someone else wants a fee.
Bug#923924: Please review and apply attached patch to support shutdown on SIGPWR
On Mon, Mar 11, 2019 at 06:12:06PM +, Dmitry Bogatov wrote:
> > On Fri, Mar 08, 2019 at 02:39:47PM +, Dmitry Bogatov wrote:
> > > [2019-03-07 12:57] Andras Korn
> > > > part 1 text/plain 218
> > > > Sorry, I sent an earlier version of the patch by mistake.
> > > >
> > > > I'm attaching the correct one, which I tested and which works for me.
> > > > [...]
> > > > - if (sigc && (stat(STOPIT, ) != -1) && (s.st_mode & S_IXUSR)) {
> > > > + if ((sigp) || (sigc && (stat(STOPIT, ) != -1) && (s.st_mode &
> > > > S_IXUSR))) {
> > >
> > > As far as I can tell by glance on patch, you want SIGPWR trigger reboot.
> > > If so, why don't you create REBOOT file in, say, /etc/rc.local and make
> > > lxc controller to send SIGCONT?
> >
> > No -- I want SIGPWR to trigger a halt.
> >
> > For the purposes of LXC, any signal will do; I just need for a signal to
> > trigger a shutdown regardless of the permissions on runit.stopit and
> > runit.reboot.
>
> Halt. Fine. But why can't you pre-provision you container with apporiate
> `stop.*' file with apporiate permissions?
Because that adds complexity elsewhere -- /etc/runit/1 as shipped creates
/run/runit.stopit with mode 0, so either all containers would need ot have a
custom /etc/runit/1, or run a custom script to chmod 100 /run/runit.stopit
on every boot, or have an immutable /run/runit.stopit.
It's not just about me; this affects everyone who wants to use runit inside
an lxc container.
My goal is to make using runit as hassle-free as possible, without
sacrificing any of its core values.
> > > By the way, SIGPWR is not in POSIX, according to signal(7).
> >
> > You're right; in that case, maybe we can use SIGQUIT?
>
> SIGTERM feels better, imho. TERM is graceful termination, while SIGQUIT
> creates coredump. By default.
SIGPWR would be nice to use as the halt signal because it's the lxc default,
so that runit could be a drop-in replacement for sysvinit in LXC containers.
If we're not going to use SIGPWR it's pretty much all the same which signal
we use, because it will need to be configured explicitly in LXC (but that's
acceptable -- POSIX is important enough).
> But this naming only matters if you explain to me, how solution not
> involving changing C code does not suffice. Two lines for convenience in
> this case, three there -- and we all know where it ends.
I'm sorry, I don't buy the slippery slope argument. I'm not adding a DNS
resolver, a DHCP client or a QR encoder, merely making the user interface a
tiny bit more similar to sysvinit's, to make integration easier. This is
entirely in line with The Unix Way: making one program a drop-in replacement
for another such that other programs interfacing with them don't see a
difference unless they need to. It's why bzip2 and gzip take most of the
same switches etc.
Since you apparently don't agree that this is a good idea, should I take the
patch to Gerrit instead?
András
--
Warranty is void in case of nuclear war, whether caused by the program or not.
Bug#923924: Please review and apply attached patch to support shutdown on SIGPWR
On Fri, Mar 08, 2019 at 02:39:47PM +, Dmitry Bogatov wrote:
Hi,
> [2019-03-07 12:57] Andras Korn
> > part 1 text/plain 218
> > Sorry, I sent an earlier version of the patch by mistake.
> >
> > I'm attaching the correct one, which I tested and which works for me.
> > [...]
> > - if (sigc && (stat(STOPIT, ) != -1) && (s.st_mode & S_IXUSR)) {
> > + if ((sigp) || (sigc && (stat(STOPIT, ) != -1) && (s.st_mode &
> > S_IXUSR))) {
>
> As far as I can tell by glance on patch, you want SIGPWR trigger reboot.
> If so, why don't you create REBOOT file in, say, /etc/rc.local and make
> lxc controller to send SIGCONT?
No -- I want SIGPWR to trigger a halt.
For the purposes of LXC, any signal will do; I just need for a signal to
trigger a shutdown regardless of the permissions on runit.stopit and
runit.reboot.
> By the way, SIGPWR is not in POSIX, according to signal(7).
You're right; in that case, maybe we can use SIGQUIT?
I suppose the other option is to wrap all changes in #ifdefs so the new bits
are only built on Linux (since it's currently only relevant for Linux, this
might be appropriate), but I think that would make the code
disproportionately ugly.
András
--
How to lose a guy in 10 days? Buy him a computer.
Bug#923957: /lib/runit/run_sysv_scripts shouldn't use 'sh -e'
Package: runit-init Version: 2.1.2-22 Severity: critical Hi, The supplied "/etc/runit/1" calls "/lib/runit/run_sysv_scripts /etc/rcS.d" during boot. /lib/runit/run_sysv_scripts runs under "sh -eu", which has the effect that if any initscript exits unsuccesfully, all subsequent scripts are skipped. This can lead to, for example, the "networking" initscript not being started, which then results in no connectivity for the box and thus no way to log in remotely. (This is my justification for the 'critical' severity: "breaks the entire system".) I think runit-init should do what /etc/init.d/rc does: log failures and continue. Thanks, András -- It's not enough to have no opinion. You must also be unable to express it.
Bug#923924: Please review and apply attached patch to support shutdown on SIGPWR
Sorry, I sent an earlier version of the patch by mistake.
I'm attaching the correct one, which I tested and which works for me.
András
--
Reality is that which, when you stop believing in it, doesn't go away.
diff --git a/runit-2.1.2/man/runit.8 b/runit-2.1.2/man/runit.8
index 6c07cf8..d597fdd 100644
--- a/runit-2.1.2/man/runit.8
+++ b/runit-2.1.2/man/runit.8
@@ -75,6 +75,12 @@ exists and has the execute by owner permission set,
.B runit
is told to shutdown the system.
.P
+If
+.B runit
+receives a PWR signal,
+.B runit
+is told to shutdown the system.
+.P
if
.B runit
receives an INT signal, a ctrl-alt-del keyboard request is triggered.
diff --git a/runit-2.1.2/src/runit.c b/runit-2.1.2/src/runit.c
index 2bb4794..35cda0a 100644
--- a/runit-2.1.2/src/runit.c
+++ b/runit-2.1.2/src/runit.c
@@ -30,6 +30,7 @@ const char * const stage[3] ={
int selfpipe[2];
int sigc =0;
int sigi =0;
+int sigp =0;
void sig_cont_handler (void) {
sigc++;
@@ -39,6 +40,10 @@ void sig_int_handler (void) {
sigi++;
write(selfpipe[1], "", 1);
}
+void sig_pwr_handler (void) {
+ sigp++;
+ write(selfpipe[1], "", 1);
+}
void sig_child_handler (void) { write(selfpipe[1], "", 1); }
void sync_if_needed() {
@@ -71,6 +76,8 @@ int main (int argc, const char * const *argv, char * const *envp) {
sig_block(sig_hangup);
sig_block(sig_int);
sig_catch(sig_int, sig_int_handler);
+ sig_block(sig_pwr);
+ sig_catch(sig_pwr, sig_pwr_handler);
sig_block(sig_pipe);
sig_block(sig_term);
@@ -150,6 +157,7 @@ int main (int argc, const char * const *argv, char * const *envp) {
sig_unblock(sig_child);
sig_unblock(sig_cont);
sig_unblock(sig_int);
+ sig_unblock(sig_pwr);
#ifdef IOPAUSE_POLL
poll(, 1, 14000);
#else
@@ -161,6 +169,7 @@ int main (int argc, const char * const *argv, char * const *envp) {
sig_block(sig_cont);
sig_block(sig_child);
sig_block(sig_int);
+ sig_block(sig_pwr);
while (read(selfpipe[0], , 1) == 1) {}
while ((child =wait_nohang()) > 0)
@@ -211,7 +220,7 @@ int main (int argc, const char * const *argv, char * const *envp) {
}
/* sig? */
- if (!sigc && !sigi) {
+ if (!sigc && !sigi && !sigp) {
#ifdef DEBUG
strerr_warn2(WARNING, "poll: ", _sys);
#endif
@@ -244,7 +253,7 @@ int main (int argc, const char * const *argv, char * const *envp) {
sigi =0;
sigc++;
}
- if (sigc && (stat(STOPIT, ) != -1) && (s.st_mode & S_IXUSR)) {
+ if ((sigp) || (sigc && (stat(STOPIT, ) != -1) && (s.st_mode & S_IXUSR))) {
int i;
/* unlink(STOPIT); */
chmod(STOPIT, 0);
@@ -286,7 +295,7 @@ int main (int argc, const char * const *argv, char * const *envp) {
/* enter stage 3 */
break;
}
- sigc =sigi =0;
+ sigc =sigi =sigp =0;
#ifdef DEBUG
strerr_warn2(WARNING, "no request.", 0);
#endif
@@ -308,7 +317,7 @@ int main (int argc, const char * const *argv, char * const *envp) {
switch (pid) {
case 0:
case -1:
- if ((stat(REBOOT, ) != -1) && (s.st_mode & S_IXUSR)) {
+ if ((!sigp) && ((stat(REBOOT, ) != -1) && (s.st_mode & S_IXUSR))) {
strerr_warn2(INFO, "system reboot.", 0);
sync_if_needed();
reboot_system(RB_AUTOBOOT);
diff --git a/runit-2.1.2/src/sig.c b/runit-2.1.2/src/sig.c
index 423d18e..9d9d69b 100644
--- a/runit-2.1.2/src/sig.c
+++ b/runit-2.1.2/src/sig.c
@@ -9,6 +9,7 @@ int sig_cont = SIGCONT;
int sig_hangup = SIGHUP;
int sig_int = SIGINT;
int sig_pipe = SIGPIPE;
+int sig_pwr = SIGPWR;
int sig_term = SIGTERM;
void (*sig_defaulthandler)() = SIG_DFL;
diff --git a/runit-2.1.2/src/sig.h b/runit-2.1.2/src/sig.h
index 2a3c780..0ced62d 100644
--- a/runit-2.1.2/src/sig.h
+++ b/runit-2.1.2/src/sig.h
@@ -9,6 +9,7 @@ extern int sig_cont;
extern int sig_hangup;
extern int sig_int;
extern int sig_pipe;
+extern int sig_pwr;
extern int sig_term;
extern void (*sig_defaulthandler)();
Bug#923924: Please review and apply attached patch to support shutdown on SIGPWR
Package: runit
Version: 2.1.2-22
Severity: wishlist
Tags: upstream
Hi,
currently lxc can't cleanly shutdown a container running runit as its init
system, because all it can do to bring about a shutdown is send signals to
init (sigpwr by default), and runit requires additional steps to initiate a
shutdown.
I wrote a trivial patch that should add sigpwr support to runit. Please
review it and if you think it's OK, apply it and perhaps submit it to Gerrit
for inclusion.
Thanks!
András
--
Enter any 11-digit prime number to continue.
diff --git a/runit-2.1.2/man/runit.8 b/runit-2.1.2/man/runit.8
index 6c07cf8..d597fdd 100644
--- a/runit-2.1.2/man/runit.8
+++ b/runit-2.1.2/man/runit.8
@@ -75,6 +75,12 @@ exists and has the execute by owner permission set,
.B runit
is told to shutdown the system.
.P
+If
+.B runit
+receives a PWR signal,
+.B runit
+is told to shutdown the system.
+.P
if
.B runit
receives an INT signal, a ctrl-alt-del keyboard request is triggered.
diff --git a/runit-2.1.2/src/runit.c b/runit-2.1.2/src/runit.c
index 2bb4794..584207a 100644
--- a/runit-2.1.2/src/runit.c
+++ b/runit-2.1.2/src/runit.c
@@ -30,6 +30,7 @@ const char * const stage[3] ={
int selfpipe[2];
int sigc =0;
int sigi =0;
+int sigp =0;
void sig_cont_handler (void) {
sigc++;
@@ -39,6 +40,10 @@ void sig_int_handler (void) {
sigi++;
write(selfpipe[1], "", 1);
}
+void sig_pwr_handler (void) {
+ sigp++;
+ write(selfpipe[1], "", 1);
+}
void sig_child_handler (void) { write(selfpipe[1], "", 1); }
void sync_if_needed() {
@@ -71,6 +76,7 @@ int main (int argc, const char * const *argv, char * const *envp) {
sig_block(sig_hangup);
sig_block(sig_int);
sig_catch(sig_int, sig_int_handler);
+ sig_catch(sig_pwr, sig_pwr_handler);
sig_block(sig_pipe);
sig_block(sig_term);
@@ -244,7 +250,7 @@ int main (int argc, const char * const *argv, char * const *envp) {
sigi =0;
sigc++;
}
- if (sigc && (stat(STOPIT, ) != -1) && (s.st_mode & S_IXUSR)) {
+ if ((sigp) || (sigc && (stat(STOPIT, ) != -1) && (s.st_mode & S_IXUSR))) {
int i;
/* unlink(STOPIT); */
chmod(STOPIT, 0);
@@ -308,7 +314,7 @@ int main (int argc, const char * const *argv, char * const *envp) {
switch (pid) {
case 0:
case -1:
- if ((stat(REBOOT, ) != -1) && (s.st_mode & S_IXUSR)) {
+ if ((!sigp) && ((stat(REBOOT, ) != -1) && (s.st_mode & S_IXUSR))) {
strerr_warn2(INFO, "system reboot.", 0);
sync_if_needed();
reboot_system(RB_AUTOBOOT);
diff --git a/runit-2.1.2/src/sig.c b/runit-2.1.2/src/sig.c
index 423d18e..9d9d69b 100644
--- a/runit-2.1.2/src/sig.c
+++ b/runit-2.1.2/src/sig.c
@@ -9,6 +9,7 @@ int sig_cont = SIGCONT;
int sig_hangup = SIGHUP;
int sig_int = SIGINT;
int sig_pipe = SIGPIPE;
+int sig_pwr = SIGPWR;
int sig_term = SIGTERM;
void (*sig_defaulthandler)() = SIG_DFL;
diff --git a/runit-2.1.2/src/sig.h b/runit-2.1.2/src/sig.h
index 2a3c780..0ced62d 100644
--- a/runit-2.1.2/src/sig.h
+++ b/runit-2.1.2/src/sig.h
@@ -9,6 +9,7 @@ extern int sig_cont;
extern int sig_hangup;
extern int sig_int;
extern int sig_pipe;
+extern int sig_pwr;
extern int sig_term;
extern void (*sig_defaulthandler)();
Bug#920977: Breaks loading of db backends in Trac
On Sat, Feb 02, 2019 at 11:00:30AM +0100, Julien Cristau wrote:
Hi,
> > as long as mercurial-common is installed, the postgres and sqlite db
> > backend driver of Trac won't load:
> >
> > 2019-01-31 08:58:49,372 Trac[loader] ERROR: Skipping "trac.db.postgres =
> > trac.db.postgres_backend":
> > Traceback (most recent call last):
> > File "/usr/lib/python2.7/dist-packages/trac/loader.py", line 77, in
> > _load_eggs
> > entry.load(require=True)
> > File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line
> > 2346, in load
> > return self.resolve()
> > File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line
> > 2352, in resolve
> > module = __import__(self.module_name, fromlist=['__name__'], level=0)
> > File
> > "/usr/lib/python2.7/dist-packages/hgdemandimport/demandimportpy2.py", line
> > 172, in _demandimport
> > return _hgextimport(_origimport, name, globals, locals, fromlist, level)
> > File
> > "/usr/lib/python2.7/dist-packages/hgdemandimport/demandimportpy2.py", line
> > 43, in _hgextimport
> > return importfunc(name, globals, *args, **kwargs)
> > File "/usr/lib/python2.7/dist-packages/trac/db/postgres_backend.py", line
> > 46, in
> > psycopg2_version = get_pkginfo(psycopg).get('version',
> > File "/usr/lib/python2.7/dist-packages/trac/util/__init__.py", line 806,
> > in get_pkginfo
> > metadata = 'METADATA' if dist.has_metadata('METADATA') else 'PKG-INFO'
> > File
> > "/usr/lib/python2.7/dist-packages/hgdemandimport/demandimportpy2.py", line
> > 151, in __getattr__
> > return getattr(self._module, attr)
> > AttributeError: 'module' object has no attribute 'has_metadata'
> > 2019-01-31 08:58:49,372 Trac[loader] DEBUG: Loading plugin "trac.db.sqlite"
> > from "/usr/lib/python2.7/dist-packages"
> > 2019-01-31 08:58:49,374 Trac[loader] ERROR: Skipping "trac.db.sqlite =
> > trac.db.sqlite_backend":
> > Traceback (most recent call last):
> > File "/usr/lib/python2.7/dist-packages/trac/loader.py", line 77, in
> > _load_eggs
> > entry.load(require=True)
> > File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line
> > 2346, in load
> > return self.resolve()
> > File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line
> > 2352, in resolve
> > module = __import__(self.module_name, fromlist=['__name__'], level=0)
> > File
> > "/usr/lib/python2.7/dist-packages/hgdemandimport/demandimportpy2.py", line
> > 172, in _demandimport
> > return _hgextimport(_origimport, name, globals, locals, fromlist, level)
> > File
> > "/usr/lib/python2.7/dist-packages/hgdemandimport/demandimportpy2.py", line
> > 43, in _hgextimport
> > return importfunc(name, globals, *args, **kwargs)
> > File "/usr/lib/python2.7/dist-packages/trac/db/sqlite_backend.py", line
> > 45, in
> > pysqlite_version_string = get_pkginfo(sqlite).get('version',
> > File "/usr/lib/python2.7/dist-packages/trac/util/__init__.py", line 806,
> > in get_pkginfo
> > metadata = 'METADATA' if dist.has_metadata('METADATA') else 'PKG-INFO'
> > File
> > "/usr/lib/python2.7/dist-packages/hgdemandimport/demandimportpy2.py", line
> > 151, in __getattr__
> > return getattr(self._module, attr)
> > AttributeError: 'module' object has no attribute 'has_metadata'
> >
> > I don't understand what the connection is, but removing mercurial-common
> > (which ships
> > /usr/lib/python2.7/dist-packages/hgdemandimport/demandimportpy2.py) helps.
> >
> As far as I can tell for this to happen something must have called
> hgdemandimport.enable(). Can you track down what that is?
I'm afraid not; not only do I have almost no idea how, I also lack the time
to do it in the short term.
András
--
Politics: Poly = many, Tics = Blood sucking parasites.
Bug#914788: Please don't enable getty services for tty devices that don't exist
On Wed, Jan 30, 2019 at 08:48:34PM +, Dmitry Bogatov wrote:
> > > What is so bad about cluttering environment of daemon?
> >
> > Normally you'd want to avoid passing unnecessary environment variables to
> > daemons. Maybe they'll affect its operation in some way; maybe they'll
> > affect a child process of the daemon that inherits them. It's relying on
> > undefined behaviour.
>
> I do not buy this argument. For ages we started daemons with
> /etc/init.d/{foo} scripts from root shell (and even with sudo), with all
> kind of environment variables, including rather nasty ones, like GREP or
> LESS, and we are still fine.
No we're not. :) Leaking shell envvars (stuff like LC_* and LD_* especially)
into daemon environments is one of the reasons initscripts are a bad idea.
Daemons should be called with a minimal required set of environment
variables.
> But probably executing services with `env -0' is good idea, thank you.
'env -0' will just modify the regular output of env(1), and will have no
effect if you use env to call a program; are you sure that's what you meant?
> > > > (But then /etc/default/foo would have to take precedence over
> > > > sv/foo/conf,
> > > > because the /etc/default/foo variables would be lost during the exec
> > > > since
> > > > we want to avoid exporting them.)
> > >
> > > This too. I want daemontools-style take precedence over sysvinit style.
> >
> > FWIW, I think the whole thing is creeping featurism,
>
> One extra source of variables, implemented with 3 lines of shell? Well,
> your definition of 'featurism' is much stricter then mine.
I meant the entire shebang of having a funky shellscript as an interpreter
for 'run' scripts just so we can avoid 3 lines of shell code in each to set
environment variables is creeping featurism. The idea is original and
certainly has hack value; but I think the benefits don't warrant the added
complexity/abstraction.
However, since using it is entirely optional, it's probably not worth
arguing over; I write most of my run scripts in zsh anyway, so I won't even
be tempted to use the new interpreter.
> > > And what if there were no tty on installation time, and after that they
> > > appeared? (No idea, why, never dealt with devices without tty.)
> >
> > That's a pathological hypothetical case; I'd say we wait until it happens,
> > and then deal with it. (You might also ask: what about hypothetical systems
> > where /dev/tty* devices keep disappearing and reappearing in a rhythm that
> > always prevents getty from starting?)
>
> Okay. I buy it. I will unconditionally include this code:
>
> if ! test -c /dev/@TTY@ ; then
> rm /etc/service/getty-@TTY@
> exit 0
> fi
>
> and upload to experimental. Should there be no report of that
> pathological case, I will merge these changes into unstable after
> Buster. Will it do for you?
Most of the time, yes, thank you. (It won't work when the service directory
isn't /etc/service, but that's rare.)
András
--
"Meow" ...splat... "Aarf" ...splat... (raining cats and dogs)
Bug#920977: Breaks loading of db backends in Trac
Package: mercurial-common
Version: 4.8.2-1
Severity: important
Hi,
as long as mercurial-common is installed, the postgres and sqlite db backend
driver of Trac won't load:
2019-01-31 08:58:49,372 Trac[loader] ERROR: Skipping "trac.db.postgres =
trac.db.postgres_backend":
Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/trac/loader.py", line 77, in _load_eggs
entry.load(require=True)
File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 2346,
in load
return self.resolve()
File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 2352,
in resolve
module = __import__(self.module_name, fromlist=['__name__'], level=0)
File "/usr/lib/python2.7/dist-packages/hgdemandimport/demandimportpy2.py",
line 172, in _demandimport
return _hgextimport(_origimport, name, globals, locals, fromlist, level)
File "/usr/lib/python2.7/dist-packages/hgdemandimport/demandimportpy2.py",
line 43, in _hgextimport
return importfunc(name, globals, *args, **kwargs)
File "/usr/lib/python2.7/dist-packages/trac/db/postgres_backend.py", line 46,
in
psycopg2_version = get_pkginfo(psycopg).get('version',
File "/usr/lib/python2.7/dist-packages/trac/util/__init__.py", line 806, in
get_pkginfo
metadata = 'METADATA' if dist.has_metadata('METADATA') else 'PKG-INFO'
File "/usr/lib/python2.7/dist-packages/hgdemandimport/demandimportpy2.py",
line 151, in __getattr__
return getattr(self._module, attr)
AttributeError: 'module' object has no attribute 'has_metadata'
2019-01-31 08:58:49,372 Trac[loader] DEBUG: Loading plugin "trac.db.sqlite"
from "/usr/lib/python2.7/dist-packages"
2019-01-31 08:58:49,374 Trac[loader] ERROR: Skipping "trac.db.sqlite =
trac.db.sqlite_backend":
Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/trac/loader.py", line 77, in _load_eggs
entry.load(require=True)
File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 2346,
in load
return self.resolve()
File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 2352,
in resolve
module = __import__(self.module_name, fromlist=['__name__'], level=0)
File "/usr/lib/python2.7/dist-packages/hgdemandimport/demandimportpy2.py",
line 172, in _demandimport
return _hgextimport(_origimport, name, globals, locals, fromlist, level)
File "/usr/lib/python2.7/dist-packages/hgdemandimport/demandimportpy2.py",
line 43, in _hgextimport
return importfunc(name, globals, *args, **kwargs)
File "/usr/lib/python2.7/dist-packages/trac/db/sqlite_backend.py", line 45,
in
pysqlite_version_string = get_pkginfo(sqlite).get('version',
File "/usr/lib/python2.7/dist-packages/trac/util/__init__.py", line 806, in
get_pkginfo
metadata = 'METADATA' if dist.has_metadata('METADATA') else 'PKG-INFO'
File "/usr/lib/python2.7/dist-packages/hgdemandimport/demandimportpy2.py",
line 151, in __getattr__
return getattr(self._module, attr)
AttributeError: 'module' object has no attribute 'has_metadata'
I don't understand what the connection is, but removing mercurial-common
(which ships
/usr/lib/python2.7/dist-packages/hgdemandimport/demandimportpy2.py) helps.
Justification for severity important: breaks unrelated packages.
András
-- System Information:
Debian Release: 10
APT prefers unstable
APT policy: (350, 'unstable'), (350, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.4.169-vs2.3.9.8-caeeng (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=hu_HU.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: runit (via /run/runit.stopit)
Versions of packages mercurial-common depends on:
ii python 2.7.15-4
Versions of packages mercurial-common recommends:
ii ca-certificates 20190110
ii mercurial4.8.2-1
ii sensible-utils 0.0.12
Versions of packages mercurial-common suggests:
pn python-mysqldb
pn python-openssl
ii python-pygments 2.3.1+dfsg-1
pn tk [wish]
-- debconf-show failed
--
With my luck, even suicide would only be a temporary solution.
Bug#914788: Please don't enable getty services for tty devices that don't exist
On Sat, Jan 26, 2019 at 10:17:05AM +, Dmitry Bogatov wrote:
Hi,
> > I believe instead of
> >
> > rm /etc/service/getty-@TTY@
> >
> > you should do
> >
> > rm "$(pwd)"
> >
> > because then it won't matter what the service is called and where the
> > runsvdir root is (/etc/service or somewhere else).
> I find it unsafe. Explicit is better implicit.
Except when it doesn't work, because the service directory is somewhere
else... But whatever.
> > While invoke-run, as an interpreter, is an original idea, I'd make it a
> > scriptlet a run script can source via ". /lib/runit/invoke-run". Then it
> > wouldn't be necessary to export all variables the configuration sets and
> > thereby clutter the environment of the daemon.
> >
> > The envdir bit could be handled by a construct like
> >
> > if [ -z "$1" ]; then
> > SVDIR="$(dirname $(readlink -f "$0")"
> > if [ -e "$SVDIR/conf" ]; then
> > exec chpst -e "$SVDIR/conf" -- "$0" "envdir-done"
> > fi
>
> Complicated. And depends on $0 trickery. We, at sysvinit team, had
> problems with $0 trickery.
How is this trickery? We're just obtaining the name of the script being
executed, and its path.
> What is so bad about cluttering environment of daemon?
Normally you'd want to avoid passing unnecessary environment variables to
daemons. Maybe they'll affect its operation in some way; maybe they'll
affect a child process of the daemon that inherits them. It's relying on
undefined behaviour.
> > (But then /etc/default/foo would have to take precedence over sv/foo/conf,
> > because the /etc/default/foo variables would be lost during the exec since
> > we want to avoid exporting them.)
>
> This too. I want daemontools-style take precedence over sysvinit style.
FWIW, I think the whole thing is creeping featurism, but if you think you
must do it, I'd prefer it being done sensibly -- i.e. not depending on
undefined behaviour, not leaking environment variables. I think this is a
stronger argument than personal preference (yours or mine).
> > > Please,
> > >
> > > * build it (it will build runit-2.1.2-22, sorry for version havoc)
> > > * install bin:runit
> > > * install bin:getty-run
> > > * write "yes" into /etc/getty-tty1/conf/GIVE_UP_ON_MISSING_TTY file
> >
> > While this would work, it doesn't improve my situation: you're making me
> > jump through hoops to get sensible behaviour. Creating these files isn't
> > less effort than deleting the getty services on installation, so it just
> > adds complexity and abstraction with no real benefit.
>
> Not exactly. You mentioned that option to pre-seed debconf would help
> you.
Yes; I already preseed debconf with much other stuff. Adding one more
preseed response doesn't add appreciable complexity.
> I provide you with way to pre-provision system -- create
> /etc/default/getty-tty{1..6} before installing runit.
But this is a different mechanism than debconf. Like I said, it would work,
but it's not easier or more comfortable than removing the /service/getty*
symlinks after runit install. It adds complexity to the package without
improving the use-case it is aimed at.
> > I still think the postinst modification I suggested (not installing
> > getty services for non-existing tty devices) would be the cleanest
> > solution.
>
> And what if there were no tty on installation time, and after that they
> appeared? (No idea, why, never dealt with devices without tty.)
That's a pathological hypothetical case; I'd say we wait until it happens,
and then deal with it. (You might also ask: what about hypothetical systems
where /dev/tty* devices keep disappearing and reappearing in a rhythm that
always prevents getty from starting?)
If you're so worried about providing a way to log in even in pathological
cases, you could start a getty on, say, tty7 from /etc/runit/1. (I have at
least one system where I do that.)
> As you can understand, I am wary about defaulting on behavior, that can
> leave user without means to login.
I understand and approve in general, but I think in this case you're taking
it too far, to cover a corner case that doesn't exist.
András
--
Quantum Mechanics: The dreams stuff is made of.
Bug#914788: Please don't enable getty services for tty devices that don't exist
On Tue, Jan 22, 2019 at 07:16:43PM +, Dmitry Bogatov wrote: Hi, > > (Alternatively, the getty run scripts could start with something like this: > > > > [ -c /dev/ttyX ] || rm /etc/service/getty-ttyX > > > > and /etc/runit/1 could re-create these symlinks, just to be absolutely sure. > > > > I don't like this approach; there is too much going on automatically.) > > I believe I found quite decent solution. Take a look at `bugfix/914788' > branch. Thanks for looking into this! I believe instead of rm /etc/service/getty-@TTY@ you should do rm "$(pwd)" because then it won't matter what the service is called and where the runsvdir root is (/etc/service or somewhere else). Also, this seems redundant: #!/usr/bin/env /lib/runit/invoke-run why not just "#!/lib/runit/invoke-run"? While invoke-run, as an interpreter, is an original idea, I'd make it a scriptlet a run script can source via ". /lib/runit/invoke-run". Then it wouldn't be necessary to export all variables the configuration sets and thereby clutter the environment of the daemon. The envdir bit could be handled by a construct like if [ -z "$1" ]; then SVDIR="$(dirname $(readlink -f "$0")" if [ -e "$SVDIR/conf" ]; then exec chpst -e "$SVDIR/conf" -- "$0" "envdir-done" fi (But then /etc/default/foo would have to take precedence over sv/foo/conf, because the /etc/default/foo variables would be lost during the exec since we want to avoid exporting them.) > Please, > > * build it (it will build runit-2.1.2-22, sorry for version havoc) > * install bin:runit > * install bin:getty-run > * write "yes" into /etc/getty-tty1/conf/GIVE_UP_ON_MISSING_TTY file While this would work, it doesn't improve my situation: you're making me jump through hoops to get sensible behaviour. Creating these files isn't less effort than deleting the getty services on installation, so it just adds complexity and abstraction with no real benefit. I still think the postinst modification I suggested (not installing getty services for non-existing tty devices) would be the cleanest solution. András -- No pixels were harmed in the creation of this program.
Bug#914788: Please don't enable getty services for tty devices that don't exist
On Wed, Nov 28, 2018 at 06:47:59PM +, Dmitry Bogatov wrote:
Hi,
sorry, didn't look at bug mail for a while.
> > However, whenever the getty-run package is installed in a vserver, I have to
> > manually remove the /service/getty-tty* symlinks.
> >
> > Can you please modify the postinst script so it only installs getty services
> > for /dev/tty* devices that are actually there?
>
> I do not like maintainer scripts. They are pain to get right. I can
> propose you to pre-provision your servers with
> `/etc/sv/getty{1-6}-run/down' file. See runsv(8).
That would still leave the runsv processes around and clutter the output of
"sv status /service/*".
The following postinst snippet should work:
export NAME='getty-tty1'
if [ -c /dev/tty1 ]; then
export ENABLE='yes'
else
export ENABLE='no'
fi
# Unlike postrm, I can be sure, that runit-helper is present on
# postinst.
/lib/runit-helper/runit-helper postinst "$@"
... and so on for the other ttys. (A lesser man would have used a for loop. :)
(Alternatively, the getty run scripts could start with something like this:
[ -c /dev/ttyX ] || rm /etc/service/getty-ttyX
and /etc/runit/1 could re-create these symlinks, just to be absolutely sure.
I don't like this approach; there is too much going on automatically.)
Or, you could add a debconf question with low priority, defaulting to "yes",
on whether to add the getty service symlinks. I could pre-seed debconf in
vservers with "no".
> > Or can we come up with a way to help people avoid shooting themselves in the
> > foot while not requiring me to install getty-run in vservers? For example,
> > runit-init could depend on "getty-run | some-way-to-log-in-interactively",
> > and "some-way-to-log-in-interactively" could be provided by an empty
> > "runit-no-getty" package as well as an "ssh-run" package that sets up a
> > runit service for ssh.
>
> If it would help you, I can add dependency on 'getty-run | access-run'.
> You are free to provide `access-run' in whatever way you like.
That would work for me if you also build a "runit-no-getty" or similar
(empty) package that provides "access-run". It should be in Debian; we
shouldn't force every container user to build their own fake empty
"access-run" package.
> I am fine with `bin:unsafe-no-tty-run' package too, but not now. I do not
> want to get stuck in NEW before freeze.
Sure, it can wait until the freeze starts. (I almost always use sid anyway.)
Thanks!
András
--
What is life but a sexually transmitted disease with a 100% mortality rate?
Bug#919699: Please support -w switch to halt(8)
Package: runit-init Version: 2.1.2-22 Severity: wishlist Tags: upstream Hi, the initscripts package ships /etc/init.d/umountnfs.sh, which is started on shutdown and invokes "halt -w", which writes a shutdown record to /var/log/wtmp. The halt(8) binary shipped with runit-init, however, ignores the option and tries to initiate a shutdown, waiting for it to complete, but a shutdown is already in progress, waiting for /etc/init.d/umountnfs.sh to exit, which is waiting for halt(8), which is waiting ... I think as a minimum, halt -w and --wtmp-only should be a no-op and exit immediately; but the clean solution would be to actually write that shutdown record to wtmp. András -- System Information: Debian Release: 10 APT prefers unstable APT policy: (350, 'unstable'), (350, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.4.169-vs2.3.9.8-caeeng (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=hu_HU.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: runit (via /run/runit.stopit) Versions of packages runit-init depends on: ii getty-run 2.1.2-19 ii initscripts 2.92~beta-2+devuan1.1 ii libc6 2.28-3 ii runit 2.1.2-22 ii runit-helper2.7.3 ii sysuser-helper 1.3.3 ii sysv-rc 2.92~beta-2+devuan1.1 runit-init recommends no packages. runit-init suggests no packages. -- no debconf information -- Hit ESC once to quit, or twice to save your data.
Bug#914788: Please don't enable getty services for tty devices that don't exist
Package: getty-run Version: 2.1.2-18 Severity: wishlist Hi, I use runit as init extensively in linux-vserver guests which don't have console devices and thus can't run getty. Ideally, I wouldn't even have to install the getty-run package, but I understand it's there to help avoid people shooting themselves in the foot by installing runit and then not having any way to log in. However, whenever the getty-run package is installed in a vserver, I have to manually remove the /service/getty-tty* symlinks. Can you please modify the postinst script so it only installs getty services for /dev/tty* devices that are actually there? Or can we come up with a way to help people avoid shooting themselves in the foot while not requiring me to install getty-run in vservers? For example, runit-init could depend on "getty-run | some-way-to-log-in-interactively", and "some-way-to-log-in-interactively" could be provided by an empty "runit-no-getty" package as well as an "ssh-run" package that sets up a runit service for ssh. András -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (350, 'unstable'), (350, 'stable'), (98, 'bionic'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Versions of packages getty-run depends on: ii runit 2.1.2-18 ii runit-helper 2.7.3 Versions of packages getty-run recommends: ii fgetty 0.7-3 -- Sure, drinking kills brain cells, but only the weak ones.
Bug#913876: PATH set in /etc/runit/2 doesn't contain /usr/local/bin and /usr/local/sbin, breaking existing run scripts
Package: runit-init Version: 2.1.2-18 Severity: normal Hi, sometime in the past year or so, you changed /etc/runit/2 so it sets a PATH that no longer contains /usr/local/sbin and /usr/local/bin. I think this is wrong; those are standard locations for locally installed binaries, and they should occur in the PATH *before* their distribution-managed counterparts, to allow locally installed software to override whatever the distribution ships. In my case, the change caused actual breakage when rebooting after the upgrade, because some of my run scripts called stuff from /usr/local, which was suddenly no longer in the PATH. Of course, it would be possible to explcitily set the PATH in all run scripts, but I'd prefer them to inherit a sane default. Best regards, András -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (350, 'unstable'), (350, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Versions of packages runit-init depends on: ii getty-run 2.1.2-18 ii initscripts 2.88dsf-59.9+devuan3 ii libc6 2.27-8 ii runit 2.1.2-18 ii runit-helper 2.7.3 ii sysv-rc 2.88dsf-59.9+devuan3 runit-init recommends no packages. runit-init suggests no packages. -- no debconf information -- Back to Nature - but not on foot.
