Bug#1063758: spamd: /etc/init.d/spamd still uses --name instead of --exec
On Wed 24/Apr/2024 18:47:42 +0200 Noah Meyerhans wrote: On Wed, Apr 24, 2024 at 10:02:47AM +0200, Alessandro Vesely wrote: Stopping S.M.A.R.T. daemon smartd. Stopping SpamAssassin Mail Filter Daemon spamd. start-stop-daemon: warning: this system is not able to track process names longer than 15 characters. please use --exec instead of --name. Next it hangs there for several seconds (~30). The next string says: Asking all remaining processes to terminate...done. Is it not SpamAssassin causing that warning? If it is, it doesn't do it on Debian. Even with sysvinit, though, the stop jobs during shutdown run in parallel, so that message may be coming from somewhere else. If you manually stop spamassassin with `/etc/init.d/spamd stop`, do you get the same warning? Good question! No, I don't. It stops cleanly and quickly. You may need to stop/start each service individually to find the culprit. We can reassign this bug accordingly when you do. Hm... I tried the two immediately preceding (K57)smartd, which happen to be smartmontools and rpcbind, and they also work well. I have /etc/init.d/.legacy-bootordering, so scripts should run one at a time. Is it possible that the start/ stop functions work differently when many daemons have been stopped? BTW, there are several scripts using --name; I have: # grep -l -- --name /etc/init.d/* | wc -l 21 # grep -l -- --exec /etc/init.d/* | wc -l 37 Best Ale
Bug#1063758: spamd: /etc/init.d/spamd still uses --name instead of --exec
On Tue 23/Apr/2024 18:39:00 +0200 Noah Meyerhans wrote: On Sun, Apr 14, 2024 at 02:09:05PM +0200, Alessandro Vesely wrote: Sorry for the delay. Today a new kernel image was loaded, so I had to reboot. I attach a screenshot of the closing session. Near the bottom, it says: Stopping S.M.A.R.T. daemon smartd. Stopping SpamAssassin Mail Filter Daemon spamd. start-stop-daemon: warning: this system is not able to track process names longer than 15 characters. please use --exec instead of --name. Next it hangs there for several seconds (~30). The next string says: Asking all remaining processes to terminate...done. Is it not SpamAssassin causing that warning? If it is, it doesn't do it on Debian. Even with sysvinit, though, the stop jobs during shutdown run in parallel, so that message may be coming from somewhere else. If you manually stop spamassassin with `/etc/init.d/spamd stop`, do you get the same warning? Good question! No, I don't. It stops cleanly and quickly. Sorry for the noise. Ale
Bug#1069596: xscreensaver does not ask password on first key hit
Hi, I'm afraid I won't try next screensaver version. The bug has been showing on a server which I don't want to reboot. After the logged event I'm using slock. Best Ale On 21/04/2024 16:52, Tormod Volden wrote: Thanks for your report. It would be worthwhile to check if this is a bug that is already fixed in the newer version of xscreensaver 6.08 that is available in Debian unstable. Can you please try installing the 6.08 version from Debian unstable? If the binaries don't install as-is, the package can be safely rebuilt without changes on your Debian stable system. (Hopefully we can get 6.08 into bookworm-backports later.) Regards, Tormod
Bug#1069596: xscreensaver does not ask password on first key hit
Package: xscreensaver
Version: 6.06+dfsg1-3
Severity: important
Dear Maintainer,
after the last system update (6.1.0-20-amd64)
accessing the system became really hard. Today
it took a quarter of an hour of random key hits
before I got a request to authenticate.
I attach a log file, starting on the first key hit.
Best
Ale
-- System Information:
Debian Release: 12.0
merged-usr: no
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.1.0-20-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)
Versions of packages xscreensaver depends on:
ii init-system-helpers 1.65.2devuan1
ii libatk1.0-0 2.46.0-5
ii libc62.36-9+deb12u4
ii libcrypt11:4.4.33-2
ii libelogind-compat [libsystemd0] 246.10-5
ii libglib2.0-0 2.74.6-2
ii libgtk-3-0 3.24.38-2~deb12u1
ii libpam0g 1.5.2-6+deb12u1
ii libx11-6 2:1.8.4-2+deb12u2
ii libxext6 2:1.3.4-1+b1
ii libxft2 2.3.6-1
ii libxi6 2:1.8-1+b1
ii libxinerama1 2:1.1.4-3
ii libxml2 2.9.14+dfsg-1.3~deb12u1
ii libxrandr2 2:1.5.2-2+b1
ii libxt6 1:1.2.1-1.1
ii libxxf86vm1 1:1.1.4-1+b2
ii xscreensaver-data6.06+dfsg1-3
Versions of packages xscreensaver recommends:
ii fonts-urw-base35 20200910-7
ii libjpeg-turbo-progs 1:2.1.5-2
ii perl 5.36.0-7+deb12u1
ii wamerican [wordlist] 2020.12.07-2
ii xfonts-100dpi 1:1.0.5
Versions of packages xscreensaver suggests:
ii epiphany-browser [www-browser] 43.1-1
ii firefox-esr [www-browser] 115.10.0esr-1~deb12u1
pn fortune
pn gdm3 | kdm-gdmcompat
ii lynx [www-browser] 2.9.0dev.12-1
pn qcam | streamer
ii w3m [www-browser] 0.5.3+git20230121-2
pn xdaliclock
pn xfishtank
pn xscreensaver-data-extra
pn xscreensaver-gl
pn xscreensaver-gl-extra
-- debconf-show failed
xscreensaver: 11:14:13: X11 KeyPress
xscreensaver: 11:14:13: checking init file
xscreensaver: 11:14:13: authorizing
xscreensaver: 11:14:13: grabbing mouse on 0x41a... GrabSuccess
xscreensaver: 11:14:13: pid 372: launched xscreensaver-auth --verbose
xscreensaver-auth: 11:14:13: pwnam: couldn't get password of "ale"
xscreensaver-auth: 11:14:13: initial effective uid/gid was root/staff (0/50)
xscreensaver-auth: 11:14:13: changed uid/gid to ale/staff (1000/50)
xscreensaver-auth: 11:14:13: running as user "ale"
xscreensaver-auth: 11:14:13: PAM: pam_start ("xscreensaver", "ale", ...) ==> 0
(Success)
xscreensaver-auth: 11:14:13: pam_set_item (p, PAM_TTY, ":0") ==> 0 (Success)
xscreensaver-auth: 11:14:13: pam_authenticate (...) ...
xscreensaver-auth: 11:14:13: pam_conversation (ECHO_OFF="Password: ") ...
xscreensaver-auth: 11:14:13: mouse is at 420,41 on monitor 0 1280x1024+0+0
"VGA-0"
xscreensaver-auth: 11:14:14: theme: default
xscreensaver-auth: 11:14:14: kbd layout: English (US)
xscreensaver-auth: 11:14:14: re-creating window: size changed
xscreensaver-auth: 11:14:23: XI RawKeyPress
xscreensaver-auth: 11:14:23: XI RawKeyRelease
xscreensaver-auth: 11:14:23: XI RawKeyPress
xscreensaver-auth: 11:14:23: XI RawKeyRelease
xscreensaver-auth: 11:14:23: XI RawKeyPress
xscreensaver-auth: 11:14:24: XI RawKeyRelease
xscreensaver-auth: 11:14:24: XI RawKeyPress
xscreensaver-auth: 11:14:24: XI RawKeyRelease
xscreensaver-auth: 11:14:24: XI RawKeyPress
xscreensaver-auth: 11:14:24: XI RawKeyRelease
xscreensaver-auth: 11:14:24: XI RawKeyPress
xscreensaver-auth: 11:14:24: XI RawKeyRelease
xscreensaver-auth: 11:14:24: XI RawKeyPress
xscreensaver-auth: 11:14:25: XI RawKeyRelease
xscreensaver-auth: 11:14:25: XI RawKeyPress
xscreensaver-auth: 11:14:25: XKB event 2
xscreensaver-auth: 11:14:25: kbd layout: English (US)
xscreensaver-auth: 11:14:25: XI RawKeyPress
xscreensaver-auth: 11:14:25: XKB event 2
xscreensaver-auth: 11:14:25: kbd layout: English (US)
xscreensaver-auth: 11:14:26: XI RawKeyPress
xscreensaver-auth: 11:14:26: XI RawKeyRelease
xscreensaver-auth: 11:14:26: XI RawKeyRelease
xscreensaver-auth: 11:14:26: XKB event 2
xscreensaver-auth: 11:14:26: kbd layout: English (US)
xscreensaver-auth: 11:14:26: XI RawKeyRelease
xscreensaver-auth: 11:14:26: XKB event 2
xscreensaver-auth: 11:14:26: kbd layout: English (US)
xscreensaver-auth: 11:14:27: XI RawKeyPress
xscreensaver-auth: 11:14:27: XKB event 2
xscreensaver-auth: 11:14:28: kbd layout: English (US)
xscreensaver-auth: 11:14:28: XI RawKeyPress
Bug#1067760: libc6: Curious behavior of inet_pton() on IPv4 mapped numbers
On Tue 26/Mar/2024 20:14:27 +0100 Aurelien Jarno wrote: On 2024-03-26 12:53, Alessandro Vesely wrote: Package: libc6 Version: 2.36-9+deb12u4 Severity: normal Tags: ipv6 Dear Maintainer, I compiled the example program given in the inet_pton(3) man page, and obtain the following: $ ./a.out i6 0:0:0::5:6:7:8 :::5:6:7:8 $ ./a.out i6 0:0:0::5.6.7.8 Not in presentation format $ ./a.out i6 0:0:0:0:0::5.6.7.8 :::5.6.7.8 Could you please tell me what do you find curious and what do you expect instead? Thanks. Yeah, sorry about that. I counted one word per tag, irrespective of it being hex or decimal. So, for the last case I though heck, 10 tag is 160-bit. I was so persuaded that, when Bastian told me the 8-word "0:0:0::5.6.7.8" is not valid I went to RFC 4291 and when I read there that the 10-tag IP 0:0:0:0:0:0:13.1.68.3 is valid, I started filling an errata against it. I copied the following passage with the idea of correcting it by removing a couple of "x"s. 3. An alternative form that is sometimes more convenient when dealing with a mixed environment of IPv4 and IPv6 nodes is x:x:x:x:x:x:d.d.d.d, where the 'x's are the hexadecimal values of the six high-order 16-bit pieces of the address, and the 'd's are the decimal values of the four low-order 8-bit pieces of the address (standard IPv4 representation). Only at that point I read the text carefully and realized how mistaken I was. I aborted the errata submission, of course. But for the bug report, which I had already sent, I can only apologize. Best Ale
Bug#1067760: libc6: Curious behavior of inet_pton() on IPv4 mapped numbers
On Tue 26/Mar/2024 17:34:20 +0100 Bastian Blank wrote: On Tue, Mar 26, 2024 at 12:53:42PM +0100, Alessandro Vesely wrote: I compiled the example program given in the inet_pton(3) man page, and obtain the following: $ ./a.out i6 0:0:0::5.6.7.8 Not in presentation format This is no valid IPv6 address. Oops, you're right. Sorry for the confusion. Where did you find that? We were discussing a regex to catch all (valid) IP addresses when someone noted that leading zeroes are valid, albeit not the RFC 5952 recommended format. It's overly tricky for me. Best Ale
Bug#1067760: libc6: Curious behavior of inet_pton() on IPv4 mapped numbers
Package: libc6 Version: 2.36-9+deb12u4 Severity: normal Tags: ipv6 Dear Maintainer, I compiled the example program given in the inet_pton(3) man page, and obtain the following: $ ./a.out i6 0:0:0::5:6:7:8 :::5:6:7:8 $ ./a.out i6 0:0:0::5.6.7.8 Not in presentation format $ ./a.out i6 0:0:0:0:0::5.6.7.8 :::5.6.7.8 Best Ale -- System Information: Debian Release: 12.0 merged-usr: no Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-18-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/bash Init: sysvinit (via /sbin/init) Versions of packages libc6 depends on: ii libgcc-s1 12.2.0-14 Versions of packages libc6 recommends: ii libidn2-0 2.3.3-1+b1 Versions of packages libc6 suggests: ii debconf [debconf-2.0] 1.5.82 ii glibc-doc 2.36-9+deb12u4 ii libc-l10n 2.36-9+deb12u4 ii libnss-nis 3.1-4 ii libnss-nisplus 1.3-4 ii locales2.36-9+deb12u4 -- debconf information excluded
Bug#1063758: spamd: /etc/init.d/spamd still uses --name instead of --exec
Package: spamd Version: 4.0.0-6 Severity: normal Dear Maintainer, /etc/init.d/spamd still uses --name instead of --exec. This is noticeable on shutdown, what the system waits for some time trying to kill spamd, and then complains something about its inability to track process names and suggests to use --exec injstead. Best Ale -- System Information: Debian Release: 12.0 merged-usr: no Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-18-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 Shell: /bin/sh linked to /bin/bash Init: sysvinit (via /sbin/init) Versions of packages spamd depends on: ii init-system-helpers 1.65.2devuan1 ii rsyslog [system-log-daemon] 8.2302.0-1devuan1 ii spamassassin 4.0.0-6 spamd recommends no packages. spamd suggests no packages. -- Configuration Files: /etc/default/spamd changed [not included] -- no debconf information
Bug#1052338: kea: /etc/init.d/kea-dhcp-ddns-server
Hi, On Wed 04/Oct/2023 23:07:49 +0200 Paride Legovini wrote: Control: severity -1 wishlist Hi Alessandro, Alessandro Vesely wrote on 20/09/2023: I installed kea on Devuan, but bugreport said kea is unforked. The server won't start, because DAEMON doesn't exist: 799-north:init.d# diff -u /tmp/kea-dhcp-ddns-server kea-dhcp-ddns-server --- /tmp/kea-dhcp-ddns-server 2023-09-20 19:39:20.0 +0200 +++ kea-dhcp-ddns-server2023-09-20 19:39:23.0 +0200 @@ -17,7 +17,7 @@ PATH=/sbin:/usr/sbin:/bin:/usr/bin DESC=kea-dhcp-ddns NAME=kea-dhcp-ddns -DAEMON=kea-dhcp-ddns +DAEMON=/usr/sbin/kea-dhcp-ddns DAEMON_ARGS="-c /etc/kea/kea-dhcp-ddns.conf" PIDFILE=/run/$NAME.pid SCRIPTNAME=/etc/init.d/$NAME In principle I'd like this to be tested on a Debian system, but the fix seems really straightforward. Would you be able to submit it as an MP against the Kea packaging repository [1]? Thanks! Nope. I tried to access via GitLab, then I tried to register, but haven't been able to. Best Ale [1] https://salsa.debian.org/debian/isc-kea/
Bug#1052338: kea: /etc/init.d/kea-dhcp-ddns-server
Package: kea Version: 2.2.0-6 Severity: normal Dear Maintainer, I installed kea on Devuan, but bugreport said kea is unforked. The server won't start, because DAEMON doesn't exist: 799-north:init.d# diff -u /tmp/kea-dhcp-ddns-server kea-dhcp-ddns-server --- /tmp/kea-dhcp-ddns-server 2023-09-20 19:39:20.0 +0200 +++ kea-dhcp-ddns-server2023-09-20 19:39:23.0 +0200 @@ -17,7 +17,7 @@ PATH=/sbin:/usr/sbin:/bin:/usr/bin DESC=kea-dhcp-ddns NAME=kea-dhcp-ddns -DAEMON=kea-dhcp-ddns +DAEMON=/usr/sbin/kea-dhcp-ddns DAEMON_ARGS="-c /etc/kea/kea-dhcp-ddns.conf" PIDFILE=/run/$NAME.pid SCRIPTNAME=/etc/init.d/$NAME -- System Information: Debian Release: 12.0 merged-usr: no Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-12-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/bash Init: sysvinit (via /sbin/init) Versions of packages kea depends on: ii kea-admin 2.2.0-6 ii kea-ctrl-agent2.2.0-6 ii kea-dhcp-ddns-server 2.2.0-6 ii kea-dhcp4-server 2.2.0-6 ii kea-dhcp6-server 2.2.0-6 kea recommends no packages. kea suggests no packages. -- no debconf information
Bug#1050039: traceroute: Exit code is not reliable nor documented
Package: traceroute
Version: 1:2.1.0-2+deb11u1
Severity: normal
Dear Maintainer,
I resend this from Devuan, because the package is not forked.
I've been using traceroute to monitor network state of the server for years.
It is called for each interface by a cron job running a few times per hour.
Since yesterday, an interface stopped working, but the job never noticed it.
Manually calling traceroute only shows the (natted) modem interface:
:~# ip addr show eth1r
3: eth1r: mtu 1500 qdisc pfifo_fast state UP
group default qlen 1000
link/ether 00:26:55:e0:d0:e8 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.254/24 brd 192.168.1.255 scope global eth1r
valid_lft forever preferred_lft forever
inet6 fe80::226:55ff:fee0:d0e8/64 scope link
valid_lft forever preferred_lft forever
:~# traceroute -4 -n -i eth1r -m 4 -s 192.168.1.254 185.204.135.186
traceroute to 185.204.135.186 (185.204.135.186), 4 hops max, 60 byte packets
1 192.168.1.1 0.235 ms 0.282 ms 0.289 ms
2 * * *
3 * * *
4 * * *
Exit code is 0. In fact recvmsg reports no error. The relevant calls are:
23495 sendto(14, "@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\\]^_", 32, 0, NULL, 0) = 32
23495 recvmsg(3, {msg_name={sa_family=AF_INET, sin_port=htons(33434),
sin_addr=inet_addr("185.204.135.186")}, msg_namelen=28->16,
msg_iov=[{iov_base="@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\\]^_", iov_len=1280}],
msg_iovlen=1, msg_control=[{cmsg_len=32, cmsg_level=SOL_SOCKET,
cmsg_type=SO_TIMESTAMP_OLD, cmsg_data={tv_sec=1692345052, tv_usec=96190}},
{cmsg_len=20, cmsg_level=SOL_IP, cmsg_type=IP_TTL, cmsg_data=[64]},
{cmsg_len=48, cmsg_level=SOL_IP, cmsg_type=IP_RECVERR, cmsg_data={ee_errno=113,
ee_origin=2, ee_type=11, ee_code=0, ee_info=0, ee_data=0,
offender={sa_family=AF_INET, sin_port=htons(0),
sin_addr=inet_addr("192.168.1.1")}}}], msg_controllen=104,
msg_flags=MSG_ERRQUEUE}, MSG_ERRQUEUE) = 32
23495 recvmsg(4, {msg_name={sa_family=AF_INET, sin_port=htons(33435),
sin_addr=inet_addr("185.204.135.186")}, msg_namelen=28->16,
msg_iov=[{iov_base="@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\\]^_", iov_len=1280}],
msg_iovlen=1, msg_control=[{cmsg_len=32, cmsg_level=SOL_SOCKET,
cmsg_type=SO_TIMESTAMP_OLD, cmsg_data={tv_sec=1692345052, tv_usec=96276}},
{cmsg_len=20, cmsg_level=SOL_IP, cmsg_type=IP_TTL, cmsg_data=[64]},
{cmsg_len=48, cmsg_level=SOL_IP, cmsg_type=IP_RECVERR, cmsg_data={ee_errno=113,
ee_origin=2, ee_type=11, ee_code=0, ee_info=0, ee_data=0,
offender={sa_family=AF_INET, sin_port=htons(0),
sin_addr=inet_addr("192.168.1.1")}}}], msg_controllen=104,
msg_flags=MSG_ERRQUEUE}, MSG_ERRQUEUE) = 32
23495 recvmsg(5, {msg_name={sa_family=AF_INET, sin_port=htons(33436),
sin_addr=inet_addr("185.204.135.186")}, msg_namelen=28->16,
msg_iov=[{iov_base="@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\\]^_", iov_len=1280}],
msg_iovlen=1, msg_control=[{cmsg_len=32, cmsg_level=SOL_SOCKET,
cmsg_type=SO_TIMESTAMP_OLD, cmsg_data={tv_sec=1692345052, tv_usec=96277}},
{cmsg_len=20, cmsg_level=SOL_IP, cmsg_type=IP_TTL, cmsg_data=[64]},
{cmsg_len=48, cmsg_level=SOL_IP, cmsg_type=IP_RECVERR, cmsg_data={ee_errno=113,
ee_origin=2, ee_type=11, ee_code=0, ee_info=0, ee_data=0,
offender={sa_family=AF_INET, sin_port=htons(0),
sin_addr=inet_addr("192.168.1.1")}}}], msg_controllen=104,
msg_flags=MSG_ERRQUEUE}, MSG_ERRQUEUE) = 32
23495 +++ exited with 0 +++
The modem obviously needs a reset. The point is that I was expecting
traceroute to detect that, since the interface doesn't work. If this
is not a bug in the code, it is in the documentation, tagged 11 October
2006, which doesn't mention exit code at all.
Thanks
Ale
-- System Information:
Debian Release: 11.1
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.10.0-24-amd64 (SMP w/8 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)
Versions of packages traceroute depends on:
ii libc6 2.31-13+deb11u6
traceroute recommends no packages.
traceroute suggests no packages.
-- no debconf information
Bug#966343: bug#498: libc6: Permission denied, intermittent in execve
On Mon, 27 Jul 2020 12:13:44 +0200 Samuel Thibault wrote: > Alessandro Vesely, le lun. 27 juil. 2020 11:47:34 +0200, a ecrit: > > So this turns out to be a documentation bug. The execve man page should > > mention that EACCESS can result as an (unforeseen) apparmor impediment. > > Well, basically all system calls would then need this... Yeah, likely. How many man pages have snippets like "[...] denied for one of the directories in the path [...]"? Yet, considering the following examples, they seem to have been written manually rather than resorting to some sort of script: EACCES The requested access to the file is not allowed, or search permission is denied for one of the directories in the path prefix of pathname, or the file did not exist yet and write access to the parent directory is not allowed. (See also path_resolution(7).) EACCES Search permission is denied on a component of the path prefix of filename or the name of a script interpreter. (See also path_resolution(7).) EACCES Write access to the directory containing newpath is denied, or search permission is denied for one of the directories in the path prefix of oldpath or newpath. (See also path_resolution(7).) EACCES Search permission is denied for a component of the path prefix, or the named file is not writable by the user. (See also path_resolution(7).) EACCES Search permission is denied on a component of the path prefix. (See also path_resolution(7).) Philip Couling commented that the man page /could/ mention security extensions since they are prevelent. See: https://unix.stackexchange.com/questions/600174/identical-execve-causes-permission-denied-for-one-program-but-not-another/600529#comment1121270_600529 For execve, for example, one could add that permissions are not derived from file flags only. For example: OLD: EACCES Execute permission is denied for the file or a script or ELF interpreter. NEW: EACCES Execute permission for the file or a script or ELF interpreter is denied either by flags or by security modules. Would that be correct? Do all "DENIED" operations result in EACCES? And what do other security modules do? Hmm... Starting to document that mess from the point of view of programs getting such failure codes would allow better logging and better troubleshooting. Best Ale
Bug#966343: bug#498: libc6: Permission denied, intermittent in execve
Hi Mark, On Mon 27/Jul/2020 11:14:01 +0200 Mark Hindley wrote: > On Mon, Jul 27, 2020 at 10:32:15AM +0200, Alessandro Vesely wrote: >> Package: libc6 >> Version: GNU C Library (Debian GLIBC 2.28-10) stable release version 2.28. >> Severity: normal >> >> in certain situations, execve fails setting errno to EACCESS. The same >> program, launched by the same user in different ways, succeeds or fails >> according to preceding actions. > > Thanks for this. As you have realised, libc6 is a Debian package that Devuan > uses directly without recompilation so this issue is correctly dealt with in > Debian's BTS. > > However, one thought that occurs to me is whether apparmor is causing this? > Does > disabling it[1] restore predictable behaviour? Bingo! Jul 27 09:47:25 pcale kernel: [ 1569.887279] audit: type=1400 audit(1595836045.642:33): apparmor="DENIED" operation="exec" profile="thunderbird" name="/opt/lib reoffice6.4/program/soffice" pid=5402 comm="gio-launch-desk" requested_mask="x" denied_mask="x" fsuid=1000 ouid=0 I dunno how come apparmor got installed. Probably it happened when I upgraded to Beowulf. After aa-teardown and purging apparmor, execve works as expected. So this turns out to be a documentation bug. The execve man page should mention that EACCESS can result as an (unforeseen) apparmor impediment. Thank you so much Ale
Bug#966343: libc6: Permission denied, intermittent in execve
Package: libc6 Version: GNU C Library (Debian GLIBC 2.28-10) stable release version 2.28. Severity: normal Forwarded Message Subject: libc6: Permission denied, intermittent in execve Date: Mon, 27 Jul 2020 10:25:27 +0200 From: Alessandro Vesely To: Devuan Bug Tracking System Dear Maintainer, in certain situations, execve fails setting errno to EACCESS. The same program, launched by the same user in different ways, succeeds or fails according to preceding actions. None of the failure conditions for EACCESS is met. The case at hand happens with an old version of Thunderbird and a LibreOffice attachment. After saving the attachment, Thunderbird execs gio-launch-desktop. The latter tries to exec libreoffice6.4 and fails. I strace'd the full arguments used in the failed execve(), and copied them to a simple C program which runs just that execve() call. When called from the command line, the program succeeds. Then I replaced the gio-launch-desktop executable with my straw men. When called from Thunderbird, the program fails. See also: https://unix.stackexchange.com/questions/600174/permission-denied-intermittent-in-execve -- System Information: Distributor ID: Debian Description:Devuan GNU/Linux 3 (beowulf) Release:3 Codename: beowulf Architecture: x86_64 Kernel: Linux 4.19.0-9-amd64 (SMP w/8 CPU cores) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), LANGUAGE=en_IE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash
Bug#965034: snmpd: Default not sourced, SNMPDOPTS not changed, 'ia_addr' error resurrected
Package: snmpd
Version: 5.7.3+dfsg-5
Severity: normal
Dear Debian Maintainer,
after upgrading to Beowulf, daemon.log gets filled with these:
Jul 14 18:31:46 31 north snmpd[27013]: error on subcontainer 'ia_addr' insert
(-1)
Jul 14 18:31:46 31 north snmpd[27013]: error on subcontainer 'ia_addr' insert
(-1)
Jul 14 18:31:46 31 north snmpd[27013]: error on subcontainer 'ia_addr' insert
(-1)
Jul 14 18:31:46 31 north snmpd[27013]: error on subcontainer 'ia_addr' insert
(-1)
Jul 14 18:31:46 31 north snmpd[27013]: error on subcontainer 'ia_addr' insert
(-1)
Jul 14 18:31:46 31 north snmpd[27013]: error on subcontainer 'ia_addr' insert
(-1)
Jul 14 18:31:46 31 north snmpd[27013]: error on subcontainer 'ia_addr' insert
(-1)
[...]
It is an old bug, with a known "solution" consisting in lowering the log level.
However, the original init.d/snmpd must have been changed, so that
/etc/default/snmpd
does not get sourced. Hence the logs.
I just changed /etc/init.d/snmpd (lazy me).
-- System Information:
Distributor ID: Debian
Description:Devuan GNU/Linux 3 (beowulf)
Release:3
Codename: beowulf
Architecture: x86_64
Kernel: Linux 4.19.0-9-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled
Versions of packages snmpd depends on:
ii adduser3.118
ii debconf [debconf-2.0] 1.5.71
ii libc6 2.28-10
ii libmariadb31:10.3.22-0+deb10u1
ii libsnmp-base 5.7.3+dfsg-5
ii libsnmp30 5.7.3+dfsg-5
ii libssl1.1 1.1.1d-0+deb10u3
ii lsb-base 10.2019051400
ii zlib1g 1:1.2.11.dfsg-1
snmpd recommends no packages.
Versions of packages snmpd suggests:
pn snmptrapd
-- Configuration Files:
/etc/default/snmpd changed:
export MIBS=
SNMPDRUN=yes
SNMPDOPTS='-LS6d -Lf /dev/null -u snmp -g snmp -I
-smux,mteTrigger,mteTriggerConf -p /run/snmpd.pid'
/etc/init.d/snmpd changed:
if [ true != "$INIT_D_SCRIPT_SOURCED" ] ; then
set "$0" "$@"; INIT_D_SCRIPT_SOURCED=true . /lib/init/init-d-script
fi
DESC="SNMP Services"
DAEMON=/usr/sbin/snmpd
PIDFILE="/run/snmpd.pid"
OLD_MIBS_DIR="/usr/share/mibs/site:/usr/share/snmp/mibs:/usr/share/mibs/iana:/usr/share/mibs/ietf:/usr/share/mibs/netsnmp"
MIBS_DIR="/usr/share/snmp/mibs:/usr/share/snmp/mibs/iana:/usr/share/snmp/mibs/ietf"
export MIBDIRS="$MIBS_DIR:$OLD_MIBS_DIR"
DEFAULT_SNMPDOPTS="-Ls6d -Lf /dev/null -u Debian-snmp -g Debian-snmp -I
-smux,mteTrigger,mteTriggerConf"
[ -z "$SNMPDOPTS" ] && SNMPDOPTS=$DEFAULT_SNMPDOPTS
DAEMON_ARGS="$SNMPDOPTS -p $PIDFILE"
do_start_prepare()
{
# remove old symlink with previous version
if [ -L /var/run/agentx ]; then
rm -f /var/run/agentx
fi
if [ ! -d /var/run/agentx ]; then
mkdir -p /var/run/agentx
fi
}
/etc/snmp/snmpd.conf [Errno 13] Permission denied: '/etc/snmp/snmpd.conf'
/etc/snmp/snmptrapd.conf [Errno 13] Permission denied:
'/etc/snmp/snmptrapd.conf'
-- debconf information:
snmpd/upgradefrom36:
snmpd/upgradefrom521:
Bug#930154: inkscape: extension-error-log complaint. An improper .inx file?
On Fri 21/Jun/2019 15:53:49 +0200 Mattia Rizzolo wrote: > But as I mentioned, those messages are completely harmless, so you can > safely ignore these errors. In fact, the misbehavior I was after turned out to be unrelated. Thank you anyway. Best Ale signature.asc Description: OpenPGP digital signature
Bug#930154: inkscape: extension-error-log complaint. An improper .inx file?
Package: inkscape Version: 0.92.1-1 Severity: normal Dear Maintainer, I'm experiencing a strange behavior of Inkscape, and, trying to investigate, I found an extension-errors.log which I attach. In fact, I have: ~$ dpkg -L inkscape|grep -i win32 /usr/share/inkscape/extensions/print_win32_vector.inx /usr/share/inkscape/extensions/print_win32_vector.py Is that normal? Thank you Ale -- System Information: Debian Release: 9.9 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-9-amd64 (SMP w/4 CPU cores) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), LANGUAGE=en_IE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: sysvinit (via /sbin/init) Versions of packages inkscape depends on: ii libaspell150.60.7~20110707-3+b2 ii libatk1.0-02.22.0-1 ii libatkmm-1.6-1v5 2.24.2-2 ii libc6 2.24-11+deb9u4 ii libcairo2 1.14.8-1 ii libcairomm-1.0-1v5 1.12.0-1+b1 ii libcdr-0.1-1 0.1.3-3+b1 ii libdbus-1-31.10.26-0+deb9u1 ii libdbus-glib-1-2 0.108-2 ii libfontconfig1 2.11.0-6.7+b1 ii libfreetype6 2.6.3-3.2 ii libgc1c2 1:7.4.2-8 ii libgcc11:6.3.0-18+deb9u1 ii libgdk-pixbuf2.0-0 2.36.5-2+deb9u2 ii libglib2.0-0 2.50.3-2 ii libglibmm-2.4-1v5 2.50.0-1 ii libgomp1 6.3.0-18+deb9u1 ii libgsl22.3+dfsg-1 ii libgtk2.0-02.24.31-2 ii libgtkmm-2.4-1v5 1:2.24.5-1 ii libgtkspell0 2.0.16-1.1 ii libjpeg62-turbo1:1.5.1-2 ii liblcms2-2 2.8-4+deb9u1 ii libmagick++-6.q16-78:6.9.7.4+dfsg-11+deb9u7 ii libmagickcore-6.q16-3 8:6.9.7.4+dfsg-11+deb9u7 ii libmagickwand-6.q16-3 8:6.9.7.4+dfsg-11+deb9u7 ii libpango-1.0-0 1.40.5-1 ii libpangocairo-1.0-01.40.5-1 ii libpangoft2-1.0-0 1.40.5-1 ii libpangomm-1.4-1v5 2.40.1-3 ii libpng16-161.6.28-1+deb9u1 ii libpoppler-glib8 0.48.0-2+deb9u2 ii libpoppler64 0.48.0-2+deb9u2 ii libpopt0 1.16-10+b2 ii libpotrace01.13-3 ii librevenge-0.0-0 0.0.4-6 ii libsigc++-2.0-0v5 2.10.0-1 ii libstdc++6 6.3.0-18+deb9u1 ii libvisio-0.1-1 0.1.5-4+b1 ii libwpg-0.3-3 0.3.1-3 ii libx11-6 2:1.6.4-3+deb9u1 ii libxml22.9.4+dfsg1-2.2+deb9u2 ii libxslt1.1 1.1.29-2.1 ii python 2.7.13-2 ii zlib1g 1:1.2.8.dfsg-5 Versions of packages inkscape recommends: ii aspell 0.60.7~20110707-3+b2 ii fig2dev [transfig] 1:3.2.6a-2+deb9u1 ii imagemagick 8:6.9.7.4+dfsg-11+deb9u7 ii imagemagick-6.q16 [imagemagick] 8:6.9.7.4+dfsg-11+deb9u7 ii libimage-magick-perl 8:6.9.7.4+dfsg-11+deb9u7 ii libwmf-bin 0.2.8.4-10.6 ii python-lxml 3.7.1-1 ii python-numpy 1:1.12.1-3 ii python-scour 0.32-2 ii transfig 1:3.2.6a-2+deb9u1 Versions of packages inkscape suggests: ii dia 0.97.3+git20160930-6 ii dia-gnome0.97.3+git20160930-6 ii libsvg-perl 2.64-1 ii libxml-xql-perl 0.68-6 ii pstoedit 3.70-3+b2 pn python-uniconvertor ii ruby 1:2.3.3 -- no debconf information Extension "Sketch Input" failed to load because a dependency was not met. Dependency: type: executable location: path string: skconvert Extension "Win32 Vector Print" failed to load because the extension is designed for Windows only. This is caused by an improper .inx file for this extension. An improper .inx file could have been caused by a faulty installation of Inkscape.
Bug#711853: insserv: Design bug: rcN.d unstable and not, maintainable
On Thu 25/Apr/2019 16:12:42 +0200 Dmitry Bogatov wrote: > [2019-04-22 19:07] Alessandro Vesely > >> The point is building every time from scratch, rigidly enjoining specs, >> like it or lump it, versus an incremental, tolerant, minimal changes >> operation. > > What is the point of "incremental, tolerant, minimal changes operation"? Just to allow a wider set of possibilities. > C compiler always builds .o file from source file always afresh, and it > reduces its complexity, and insserv(8) can be seen as compiler from > content of /etc/init.d/, /etc/insserv/ and /etc/insserv.conf to > /etc/rc[0-6].d .o files are not quite editable. To patch them, one needs so much careful checking that it is not practical to do it. There is no tool to support it. And, you don't recompile every object and library every time. > The only possible reason to attempt reusing existing content of > /etc/rc[0-6].d is perfomance, and it does not apply. I agree performance is not an issue. > I argue, that isserv(8) is compiler, not build tool like make(1), since > it is impossible to separate processing of any individual file from rest > of them: /etc/init.d/, /etc/insserv/ and /etc/insserv.conf together > are single input. It is possible to consider each /etc/rc[0-6].d as > separate output, but it is useless. Your latter paragraph condenses very well the point on which we disagree. Unlike object files, /etc/rc?.d can be edited using ln, mv and rm. It would even be possible to place there a plain script or --why not?-- an executable. No, I never did that and cannot imagine why on earth someone else would do it. But, in case, who am I to deny them the right to do so? Put it another way, if I drop the (admittedly unrealistic) possibility to edit rc?.d's by hand, I would have to conclude that that architecture is a relic devoid of its functionality. Do we maintain it for aesthetic reasons, like the Colosseum? I wouldn't know. I like it, probably just because I've been using it for so long. I appreciate LSB comment convention as a clever evolution, which helps ordering the links. Preserving that somewhat baroque directory structure, deprived of its flexibility merits, however, sounds fictional. Best Ale --
Bug#711853: insserv: Design bug: rcN.d unstable and not, maintainable
On Mon 22/Apr/2019 11:55:55 +0200 Dmitry Bogatov wrote: > [2019-04-18 18:30] Alessandro Vesely >> On Thu 18/Apr/2019 12:43:24 +0200 Ian Jackson wrote: >>> >>> But I think the current behaviour of insserv in this situation is to >>> bomb out completely and refuse to operate, isn't it ? So it already >>> fails to disturb the existing symlinks ? >> >> At least, that's what happens at mine. I had to write a quick script to >> overcome that, http://www.tana.it/sw/fix-init/. > > I agree, better not to break things if we don't need to, but introducing > complexity to support broken setup? I thought that script was way less complex than insserv... > Cycled dependencies or otherwise incoherent dependencies is broken > setup. Fix it. We already discussed how to fix it. Asking to support it > is like asking to support situation, when dependency of your package is > removed by `dpkg -r'. Let me just note, in passing, that you're assuming any script belongs to some package. What if a simple-minded user wants to write "Hello world" on every boot? Similarly, LSB defines installation of scripts, and casually mentions rc as an example implementation. Given that the implementation can actually host more than the specification assumes, why artificially limit it?. >> Rather than a patch, I'd consider an alternative executable. The link above >> displays a man page for the script. I'm not advocating that script, as it >> has >> many defects. However, I like its man page and its options. I don't think > > You can try introducing new package into debian: > insserv-with-support-of-inconsistent-scripts and make it Provides: > insserv. I append that to my to do list. > Data point: I do not care much of speed of boot (as long it is not 90s), (loading ClamAV database may take longer...) > and I do not care at all of support for inconsistent LSB dependencies. I'd never complicate things in order to support unspecified martians. The point is building every time from scratch, rigidly enjoining specs, like it or lump it, versus an incremental, tolerant, minimal changes operation. > PS. About services starting before you can see config. There is > /sbin/rc.policy mechanism. Thanks for the tip. Best Ale --
Bug#711853: 711853
On Thu 18/Apr/2019 12:41:57 +0200 Tom H wrote: >>> I've always assumed that: >>> >>> - the rcX.d links are only meant to be changed by running "insserv" >>> (directly or via update-rc.d) >>> >>> - the dependencies of "/etc/init.d/foo" should be changed via >>> "/etc/insserv/overrides/foo" >> >> That sounds overly procrustean if applied rigorously, don't you think so? > > On a personal laptop, maybe. > > In a professional context, with multiple sysadmins and systems, > definitely not. The insserv man page should really say something like > "the /etc/rcX.d directories are owned by insserv and the symlinks that > they contain should not be edited manually." What's the point of having manually editable links, then? Create a binary file containing the boot recipe, à la systemd, and you can be almost sure that your ban against manual interventions is duly respected. > If creating "/etc/insserv/overrides/foo" is too much, there's always > the option of editing "/etc/init.d/foo" directly, since it's generally > (always?) a dpkg conffile. Probably writing /patches/ to the LSB's would be more appealing. For example one could eliminate X from runlevel 2 and ignore the rest of the block. Best Ale --
Bug#711853: insserv: Design bug: rcN.d unstable and not, maintainable
On Thu 18/Apr/2019 12:43:24 +0200 Ian Jackson wrote: > Dmitry Bogatov writes: >> >> As far as I know, "A depends B, B depends A" situation is called >> RC-critical bug. > > If shipped by Debian but it can perhaps arise due to old packages, > ad-hoc packages, etc. I agree that it's wrong but ISTM that it is > better not to break things if we don't need to. > > But I think the current behaviour of insserv in this situation is to > bomb out completely and refuse to operate, isn't it ? So it already > fails to disturb the existing symlinks ? At least, that's what happens at mine. I had to write a quick script to overcome that, http://www.tana.it/sw/fix-init/. > As for "stable sort": > > So IMO if someone wants to send a patch which improves the algorithm > so that it preserves more of the existing link ordering, when > right now it doesn't care, we ought to consider it. (We'd want to > be sure it didn't have any meaningfully different behaviour in > "normal" configurations.) Rather than a patch, I'd consider an alternative executable. The link above displays a man page for the script. I'm not advocating that script, as it has many defects. However, I like its man page and its options. I don't think sparse patches to insserv can result in similar behavior. > Note that the existing scheme parallelises things when the > dependencies permit, and we should not take a patch which fails to > parallelise things just because the existing links aren't parallel. Here's a point I had never considered. Perhaps, that's because I tend to boot very sparingly --even on laptops, since suspend works well enough. I accept parallelism can be a very important point for several people. An instance of diversity? Best Ale --
Bug#711853: insserv: Design bug: rcN.d unstable and not, maintainable
On Thu 18/Apr/2019 12:24:25 +0200 Dmitry Bogatov wrote: > [2019-04-17 18:02] Alessandro Vesely >> >> I recall having seen all links renumbered as 01, 02, 03, ... On the machine >> I'm writing from now --a client where the boot sequence was never tampered >> with-- links are numbered with gaps. I see several 01's, a single 02, then >> 14, >> 16, ... Perhaps unconditional renumbering was changed since I posted that >> bug? > > On my system no gaps: 01, 02, 03, 04, 05, 06 in rc2.d/ When programming in Basic, I was advised to number lines as 10, 20, 30, ..., so as to ease insertions without having to renumber everything. Yes, that was before Dijkstra's invective against goto's, but since you mentioned manually editing text segments... >> To edit LSB headers may make sense for one's own scripts. Arbitrary >> insserv overrides don't seem to be the right thing to do... Or is it >> customary? > > If you have special needs -- it is okay. If ordering is wrong -- report > bug. The whole idea of Debian is to ship things that work. Sounds good. >> Bottom line, I've been trying to recover some of the flexibility we >> had before LSB's. I know that train has left many years ago... > > To be honest, I have rather basic knowledge, how things worked before > LSB. But as you describe it, manual moving symlinks feels like manual > editing output of `gcc'. Actually, it was much easier. It usually boiled down to an /early/ vs /late/ decision, which was easily answered after reading the man page. Nowadays, daemons are started as soon as you install them, without even having a glance at their configuration. Best Ale --
Bug#711853: insserv: Design bug: rcN.d unstable and not, maintainable
On Wed 17/Apr/2019 00:44:26 +0200 Dmitry Bogatov wrote: > [2019-04-15 09:14] Alessandro Vesely >> >> Nowadays, stable sort algorithms are really widespread. Adjusting links >> without subverting their existing order is not that hard. > > I am not going to implement it, but even as user I fail to understand > your proposal. To configure a stable boot sequence. > Right now insserv implements little more than topological sort. You can > modify relations between scripts by editing LSB headers. What do you > mean 'adjusting links without subverting existing order'? Mind to provide > example? I just meant respecting the existing order, either if possible or if a fix is not at all obvious. Suppose A requires B and B requires A, a circular loop which is somehow resolved by having S10A S20B. Now, you want to insert links for C, which is new. If C requires B, you can insert it at S21C, even if C doesn't require A. That is, assume that the existing configuration works. I recall having seen all links renumbered as 01, 02, 03, ... On the machine I'm writing from now --a client where the boot sequence was never tampered with-- links are numbered with gaps. I see several 01's, a single 02, then 14, 16, ... Perhaps unconditional renumbering was changed since I posted that bug? To edit LSB headers may make sense for one's own scripts. Arbitrary insserv overrides don't seem to be the right thing to do... Or is it customary? Bottom line, I've been trying to recover some of the flexibility we had before LSB's. I know that train has left many years ago... Best Ale --
Bug#711853: Bug# 711853: insserv
On Sat 13/Apr/2019 01:06:01 +0200 Tom H wrote: > > I've always assumed that: > > - the rcX.d links are only meant to be changed by running "insserv" > (directly or via update-rc.d) > > - the dependencies of "/etc/init.d/foo" should be changed via > "/etc/insserv/overrides/foo" That sounds overly procrustean if applied rigorously, don't you think so? The beauty of init is not only in allowing inspection, but also offhand changes, however discouraged. jm2c Ale
Bug#711853: insserv: Design bug: rcN.d unstable and not, maintainable
On Sun 14/Apr/2019 12:52:44 +0200 Dmitry Bogatov wrote: > > control: tags -1 +wontfix +moreinfo > > [2019-04-11 10:54] Jesse Smith When update-rc.d calls insserv, the rcN.d directories are rebuilt without taking into consideration any adjustment that might have been set up locally. That seems to be done on the assumption that the dependencies coded in the LSB blocks are universally accurate. Now, LSBs are a great improvement over numeric priorities, but to hamper local system tuning, which is not necessarily related to LSBs, IMHO is an insult to the legendary versatility of SysV init. >>> >>> I believe it is not how things work now. Last time I checked, call >>> `insserv foo` does not update any links to `foo' if there is already at >>> least one of them. I get this: insserv: There is a loop between service umountnfs and rsyslog if stopped insserv: loop involving service rpcbind at depth 3 insserv: loop involving service umountnfs at depth 2 insserv: loop involving service gdm3 at depth 1 insserv: loop involving service sendsigs at depth 2 insserv: loop involving service networking at depth 7 insserv: exiting now without changing boot order! I run fixinit instead http://www.tana.it/sw/fix-init/ >> Now, as to whether this should be considered a bug or a desired effect >> is open to debate. On the one hand it is understandable people might not >> want insserv to overwrite their changes. On the other hand, in my case >> insserv is fixing a mistake in my symlinks, and adjusting them to match >> their LSB headers. Running interactively in some cases may make sense. Instead, insserv is run every time one installs a package which includes a daemon, automatically. Nowadays, stable sort algorithms are really widespread. Adjusting links without subverting their existing order is not that hard. >> My thought on this is if someone wants to improve their start-up routine >> it makes more sense for them to edit their script's LSB header and >> re-run insserv rather than editing links by hand. > > Thank you Jesse. Sounds reasonable. +1 > Dear submitter, please consider, whether your issue could be solved by > editing LSB headers and if not, why. Loops or other unforeseen circumstances are always possible. In such cases, it would still be possible to add or fix unrelated parts of the start-up sequence. Perhaps this should be turned wishlist, rather than wontfix. Thank you for the considerable work you're doing on sysv init. Ale --
Bug#909789: manpages-dev: stat(2) manpage on ENOENT for dangling symbolic links (broken links)
Package: manpages-dev Version: 4.10-2 Severity: minor Dear Maintainer, it seems to be a gotcha having stat(x, y) unexpectedly return -1 when x is a broken link. The stat(1) command works where stat(2) fails. The obvious solution is to use lstat. It is difficult to fix this without ineffectually lengthening the text. Perhaps, using the concept of unlinked file, which is valid for hard and soft links alike, might help. For example, the man page says: ENOENT A component of pathname does not exist, or pathname is an empty string. Alternatively, it could say: ENOENT A component of pathname is unlinked (does not exist), or pathname is an empty string. Besides, the 1st paragraph in the NOTES section says "AT_NO_AUTOMOUNT fag". Please substitute "AT_NO_AUTOMOUNT flag" lest someone smokes their unmounted devices... Thanks for maintaining man pages Ale -- System Information: Debian Release: 9.5 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-8-amd64 (SMP w/4 CPU cores) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), LANGUAGE=en_IE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: sysvinit (via /sbin/init) Versions of packages manpages-dev depends on: ii manpages 4.10-2 manpages-dev recommends no packages. Versions of packages manpages-dev suggests: ii jed-extra [man-browser] 2.5.7-2 ii man-db [man-browser] 2.7.6.1-2
Bug#483811: [fam] fam segfaults
I experienced more core dumps, but haven't had time to examine them.
In particular, at a time I had three core dumps in a row on Jul 14:
-rw--- 1 ale staff 6180864 Jul 14 17:10
core_epoch=1531581032_pid=5409_file=!usr!sbin!famd
-rw--- 1 ale staff 9302016 Jul 14 17:09
core_epoch=1531580943_pid=5317_file=!usr!sbin!famd
-rw--- 1 ale staff 26234880 Jul 14 17:05
core_epoch=1531580714_pid=26593_file=!usr!sbin!famd
The first of these only run for 1 minute. The "closure" in
TCP_Client::unblock_handler (closure=0x295ca20) at TCP_Client.c++:270
is always a LocalClient with a bad to_be_scanned element. In the first (short)
dump, it had:
to_be_scanned = {
, std::allocator >> =
std::set with 251 elements = {
Elements 0 to 102 were bad memory pointers.
Elements 103 to 250 were entries of type DirEntry with a common parent
corresponding to
a courierimapkeywords directory of a Courier-MTA mail folder. The parent
had 1170
entries, and this batch matched entries 12 to 159 in the parent. Since
those file names
contain Unix epoch, I could check that most --not all-- of them were in
ascending order.
One file was listed twice, and was out of order.
Dates ranged from June to a few hours before crash.
}, }
Courier at times removes a bunch of those files and stores the corresponding
IMAP keywords
in a single ":list" file. I have to study the code better to understand how
parent and
clients can be notified of Interest* deletion. Maybe next month...
Bug#840955: ITP: courier-zdkimfilter -- DKIM filter for Courier-MTA
Version 1.6 has an experimental /debian/ subdirectory included in the tarball, so that one can build a debian package (dpkg-buildpackage -b -uc -us) instead of making and installing in the traditional way. Best Ale
Bug#483811: [fam] fam segfaults
On sat 26 may 2018 it segfaulted again. Identical pattern:
(gdb) bt
#0 0x6811 in ?? ()
#1 0x00412b1c in TCP_Client::unblock_handler (closure=0xdb1870) at
TCP_Client.c++:270
#2 0x004105dc in Scheduler::handle_io (fds=0xaf3eb0,
fds@entry=0x7ffc71013620,
iotype=::FDInfo::read, iotype@entry=::FDInfo::write) at
Scheduler.c++:315
#3 0x00410811 in Scheduler::select () at Scheduler.c++:342
#4 0x00402fa5 in loop () at Scheduler.h:89
#5 main (argc=, argv=0x7ffc71013898) at main.c++:306
Clearly, the set contains a pointer to an object of type Interest which was
deleted.
Since ClientInterest issues a dequeue_from_scan when it is deleted, the culprit
must be a DirEntry. In fact, a call to its scan() function would not be
detectable from the core dump, because the code is tail-optimized:
bool
DirEntry::scan(Interest *ip)
{
assert(!ip);
return parent->scan(this);
}
(gdb) info address DirEntry::scan
Symbol "DirEntry::scan(Interest*)" is a function at address 0x404750.
(gdb) disass 0x404750
Dump of assembler code for function DirEntry::scan(Interest*):
0x00404750 <+0>: test %rsi,%rsi
0x00404753 <+3>: jne0x40476b
0x00404755 <+5>: mov%rdi,%rax
0x00404758 <+8>: mov0xc8(%rdi),%rdi
0x0040475f <+15>:mov%rax,%rsi
0x00404762 <+18>:mov(%rdi),%rdx
0x00404765 <+21>:mov0x20(%rdx),%rdx
0x00404769 <+25>:jmpq *%rdx <--- this jumps to a deleted
ClientInterest
0x0040476b <+27>:push %rax
0x0040476c <+28>:mov$0x414c80,%ecx
0x00404771 <+33>:mov$0x3b,%edx
0x00404776 <+38>:mov$0x414b8e,%esi
0x0040477b <+43>:mov$0x414b9b,%edi
0x00404780 <+48>:callq 0x4024b0 <__assert_fail@plt>
End of assembler dump.
Now I modified ClientInterest.h and Directory.c++, and further modified
ClientInterest.c++. I have:
--- orig/src/ClientInterest.h 2018-02-06 18:05:59.0 +0100
+++ ./src/ClientInterest.h 2018-06-16 10:25:18.0 +0200
@@ -73,6 +73,8 @@
virtual FileSystem * get_filesystem() { return myfilesystem; }
+void dequeue_from_scan(Interest *ip);
+
private:
enum { ACTIVE_STATE = 1 << 0 };
--- orig/src/ClientInterest.c++ 2003-01-18 15:18:12.0 +0100
+++ ./src/ClientInterest.c++2018-06-16 10:29:08.0 +0200
@@ -62,6 +62,8 @@
ClientInterest::~ClientInterest()
{
myfilesystem->cancel(this, fs_request);
+if (myclient)
+myclient->dequeue_from_scan(this);
}
void
@@ -162,6 +164,13 @@
myclient->dequeue_from_scan(ip);
}
+void
+ClientInterest::dequeue_from_scan(Interest *ip)
+{
+if (myclient)
+myclient->dequeue_from_scan(ip);
+}
+
bool
ClientInterest::do_scan()
{
--- orig/src/Directory.c++ 2003-01-18 15:18:12.0 +0100
+++ ./src/Directory.c++ 2018-06-16 10:17:32.0 +0200
@@ -77,6 +77,7 @@
{ (void) chdir();
while (p)
{ q = p->next;
+ dequeue_from_scan(p);
delete p;
p = q;
}
Waiting for next core dump...
Bug#483811: [fam] fam segfaults
On Fri, 30 Mar 2018 12:47:15 +0200 I wrote: > That suggests that Set.h doesn't work as expected. No, that wasn't the case. A couple of days ago I got a core dump with exactly the same back trace (bt), even if using std::set. Core was generated by `/usr/sbin/famd -v -f -T 0'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x in ?? () (gdb) bt #0 0x in ?? () #1 0x00412aec in TCP_Client::unblock_handler (closure=0x1935d20) at TCP_Client.c++:270 #2 0x004105ac in Scheduler::handle_io (fds=0x1c028f0, fds@entry=0x7ffd7bd92ef0, iotype=::FDInfo::read, iotype@entry=::FDInfo::write) at Scheduler.c++:315 #3 0x004107e1 in Scheduler::select () at Scheduler.c++:342 #4 0x00402fa5 in loop () at Scheduler.h:89 #5 main (argc=, argv=0x7ffd7bd93168) at main.c++:306 Need to look more closely at ip. (gdb) hd Undefined command: "hd". Try "help". (gdb) define hd Type commands for definition of "hd". End with a line saying just "end". >dump binary memory dump.tmp $arg0 $arg0+$arg1 >shell hd dump.tmp >end (gdb) p sizeof(Interest) $11 = 200 (gdb) p sizeof(File) $43 = 240 (gdb) hd (char*)ip 240 30 c1 73 02 00 00 00 00 50 56 02 02 00 00 00 00 |0.s.PV..| 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || 0020 e0 29 c0 01 00 00 00 00 36 30 30 30 36 38 31 31 |.)..60006811| 0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * 00c0 7f 00 00 01 01 00 00 00 f0 44 91 01 00 00 00 00 |.D..| 00d0 10 2b c0 01 00 00 00 00 01 00 00 00 00 00 00 00 |.+..| 00e0 f0 00 00 00 00 00 00 00 60 00 00 00 00 00 00 00 |`...| We have the following layout (from Interest.h, ClientInterest.h and `p &((Interest*)0).'): offset Instance Variables content found _vtbl bad (virtual functions) 0008Interest *hashlink; ?? 0010dev_t dev; 0 0018ino_t ino; 0 0020char *const myname; mixed buffer (see MYNAME below) 0028ScanState scan_state: 1;"6000?6811I?" ExecState cur_exec_state: 1; ExecState old_exec_state: 1; 0029char ci_char; 002achar dir_char; 0030struct stat old_stat; 00c0in_addr myhost; 127.0.0.1 00c4bool mypath_exported_to_host; 1 (remaining 3 bytes could have been set before) 00c8Client *myclient; bad, 0x19144f0 (see CLIENT below) 00d0Request request; 00d8const Cred mycred; 00e0FileSystem *myfilesystem; 00e8Request fs_request; MYNAME: (gdb) hd 0x1c029e0 80 00 00 00 00 00 00 00 00 32 39 2e 4d 38 33 31 38 |29.M8318| 0010 34 37 50 32 37 31 36 38 56 30 30 30 30 30 30 30 |47P27168V000| 0020 30 30 30 30 30 36 38 31 31 49 30 30 30 30 30 30 |06811I00| 0030 30 30 30 30 34 45 35 33 37 32 5f 31 2e 6e 6f 72 |4E5372_1.nor| 0040 74 68 2c 53 3d 32 32 35 36 36 35 00 53 00 00 53 |th,S=225665.S..S| 0050 The same is true for other Interest pointers still in to_be_scanned, $tbs0, ...: (gdb) hd $tbs0 200 90 d6 73 02 00 00 00 00 c0 2c c0 01 00 00 00 00 |..s..,..| 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || 0020 40 2a c0 01 00 00 00 00 36 30 30 30 36 38 31 31 |@*..60006811| 0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * 00c0 7f 00 00 01 01 35 34 33 |.543| 00c8 (gdb) p ((Interest*)$tbs0)->myname $13 = 0x1c02a40 "" (gdb) hd 0x1c02a40 80 00 00 00 00 00 00 00 00 32 39 2e 4d 38 34 33 38 |29.M8438| 0010 38 38 50 32 37 31 37 30 56 30 30 30 30 30 30 30 |88P27170V000| 0020 30 30 30 30 30 36 38 31 31 49 30 30 30 30 30 30 |06811I00| 0030 30 30 30 30 34 45 35 33 38 43 5f 31 2e 6e 6f 72 |4E538C_1.nor| 0040 74 68 2c 53 3d 32 32 35 36 36 35 00 00 00 00 00 |th,S=225665.| 0050 b0 01 00 00 00 00 00 00 30 00 00 00 00 00 00 00 |0...| (gdb) hd $tbs1 200 00 2b c0 01 00 00 00 00 80 2e c0 01 00 00 00 00 |.+..| 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || 0020 00 2c c0 01 00 00 00 00 36 30 30 30 36 38 31 31 |.,..60006811| 0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * 00c0 7f 00 00 01 01 35 34 33 |.543| 00c8 (gdb) p ((Interest*)$tbs1)->myname $14 = 0x1c02c00 "" (gdb) hd 0x1c02c00 80 00 00 00 00 00 00 00 00 34 34 2e 4d 34 35 37 31 |44.M4571| 0010 36 50 32 37 32 30 35 56 30 30 30 30 30 30 30 30 |6P27205V| 0020 30 30 30 30 36 38 31 31 49 30 30 30 30 30 30 30 |6811I000| 0030 30
Bug#483811: [fam] fam segfaults
Yesterday I got another core dump and, again, it was like the previous ones:
#1 0x00412927 in TCP_Client::unblock_handler (closure=0x1ffa030) at
TCP_Client.c++:270
I checked the assertions were indeed compiled in, by (gdb) disass
((TCP_Client*)$closure)->dequeue_from_scan, which ended with:
0x004129e4 <+84>:callq 0x402310 <__assert_fail@plt>
Yet, those assertions didn't catch anything. So I must have extracted from
client->to_be_scanned an ip with vtbl[4] == 0, which was never put into the
set. That suggests that Set.h doesn't work as expected. To check the latter
hypothesis, I modified TCP_Client.h so as to use a standard set instead:
--- fam2/fam-2.7.0/build-tree/fam-2.7.0/src/TCP_Client.h2003-01-18
15:18:12.0 +0100
+++ fam/fam-2.7.0/build-tree/fam-2.7.0/src/TCP_Client.h 2018-03-30
10:53:03.0 +0200
@@ -25,9 +25,28 @@
#include "ClientConnection.h"
#include "MxClient.h"
-#include "Set.h"
+
+// use std::set instead
+//#include "Set.h"
+#include
#include "Cred.h"
+class stdset : public std::set
+{
+public:
+// Inherit insert(), size()
+bool contains(const key_type e) {return find(e) != end();}
+void remove(const key_type e) {erase(e);}
+key_type first() const {return begin() == end()? NULL: *begin();}
+key_type next(const key_type k) const {
+ const_iterator it = find(k);
+ if (it != end()) ++it;
+ if (it == end()) return NULL;
+ return *it;
+}
+// sizeofnode() method is not used
+};
+
struct sockaddr_un;
// A TCP_Client is a client that connects to fam using the TCP/IP
@@ -60,7 +79,8 @@ protected:
private:
-Set to_be_scanned;
+// Set to_be_scanned;
+stdset to_be_scanned;
Scanner *my_scanner;
ClientConnection conn;
Activity a;// simply declaring it
activates timer.
Waiting for next core dump...
Bug#483811: [fam] fam segfaults
Yesterday it happened again, exactly the same pattern:
Reading symbols from ./build-tree/fam-2.7.0/src/famd...done.
[New LWP 18773]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/sbin/famd -v -f -T 0'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x in ?? ()
(gdb) bt
#0 0x in ?? ()
#1 0x004128e7 in TCP_Client::unblock_handler (closure=0x10982a0) at
TCP_Client.c++:270
#2 0x004103cc in Scheduler::handle_io (fds=0x1a4dd70,
fds@entry=0x7ffce30d7a40,
iotype=::FDInfo::read, iotype@entry=::FDInfo::write) at
Scheduler.c++:315
#3 0x00410601 in Scheduler::select () at Scheduler.c++:342
#4 0x00402dc5 in loop () at Scheduler.h:89
#5 main (argc=, argv=0x7ffce30d7cb8) at main.c++:306
This confirms the diagnosis. I put a couple of assertions like so:
--- src/TCP_Client.c++.orig 2003-01-18 15:18:12.0 +0100
+++ src/TCP_Client.c++ 2018-03-15 18:35:24.0 +0100
@@ -287,12 +287,14 @@
{
if (!to_be_scanned.size())
conn.ready_for_input(false);
+assert((*(long **)ip)[4] != 0L); // ip func[4] (scan) not virtual
to_be_scanned.insert(ip);
}
void
TCP_Client::dequeue_from_scan(Interest *ip)
{
+assert((*(long **)ip)[4] != 0L); // ip func[4] (scan) not virtual
to_be_scanned.remove(ip);
if (!to_be_scanned.size())
conn.ready_for_input(true);
While recompiling, I noticed this warning:
Listener.o: In function `Listener::create_local_client(TCP_Client&, unsigned
int)':
fam-2.7.0/build-tree/fam-2.7.0/src/Listener.c++:220: warning: the use of
`tempnam' is dangerous, better use `mkstemp'
I'm not sure how that is related to this bug, if at all.
Waiting for next core dump...
Bug#483811: [courier-users] This may be a problem with FAM or Gamin
On Wed 07/Feb/2018 00:34:59 +0100 Sam Varshavchik wrote: >> >> Curiously, I found this file name: >> .5058547.1517362926.M462851P21244V6811I00566211_0.north,S=4981 >> >> >> Regular mail files don't have that leading ".5058547". What does it mean, is >> it for temporary files? >> >> The timestamp 1517362926 is Jan 31, but the file's st_mtim was 1517563957, >> exactly the core dump epoch. Could that hint what might have happened? > > Where was it? The main directory, tmp, or new or cur? Neither maildrop nor > Courier-IMAP renames a message file, once it exists in new or cur. > > The code that creates new message file doesn't use this kind of a prefix; > checked both maildrop, deliverquota, and courier's built in maildir delivery > code itself, it all uses the same code. Pretty sure nothing in Courier would > create a filename like that. The "_0" part of the filename gets used by > Courier, so without that extra prefix this would definitely be a > Courier-created file. Hmm... I looked at other elements in the same node, and all of them have the same '.5058547.' prefix: (gdb) p (*(*(*(TCP_Client*)0x1a9f4c0).to_be_scanned.root).key[0]).myname $3 = 0x18479b0 ".5058547.1517362926.M462851P21244V", '0' , "6811I00566211_0.north,S=4981" (gdb) p (*(*(*(TCP_Client*)0x1a9f4c0).to_be_scanned.root).key[1]).myname $4 = 0x19cfd10 "" (gdb) p (*(*(*(TCP_Client*)0x1a9f4c0).to_be_scanned.root).key[2]).myname $5 = 0x19d1ad0 "" (gdb) p (*(*(*(TCP_Client*)0x1a9f4c0).to_be_scanned.root).key[3]).myname $6 = 0x1dbe700 ".5058547.1517362927.M690717P21565V", '0' , "6811I0056622B_0.north,S=4977" (gdb) p (*(*(*(TCP_Client*)0x1a9f4c0).to_be_scanned.root).key[4]).myname $7 = 0x2145240 ".5058547.1517360350.M457750P18964V", '0' , "6811I00564F88_0.north,S=7685" (gdb) p (*(*(*(TCP_Client*)0x1a9f4c0).to_be_scanned.root).key[5]).myname $8 = 0x21a3020 ".5058547.1517276523.M857008P29878V", '0' , "6811I00564F17_0.north,S=5345" (gdb) p (*(*(*(TCP_Client*)0x1a9f4c0).to_be_scanned.root).key[5]) The string "myname" appears a surprisingly low number of times in the 10,000+ lines of code, and nowhere it looks like adding or removing prefixes. Thanks Ale signature.asc Description: OpenPGP digital signature
Bug#483811: [fam] fam segfaults
Package: fam
Version: 2.7.0-17.1
Followup-For: Bug #483811
I eventually managed to compile a non-stripped version of famd.
In order to run it, I modified /etc/init.d/fam, which reportbug
detected and automatically copied below (search "-ale:"). I'll
attach /root/famd-wrapper in a moment. It's a useful workaround
anyway.
Now what I found in the dumped core file:
Reading symbols from /usr/sbin/famd...done.
[New LWP 27816]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/sbin/famd -v -f -T 0'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x in ?? ()
(gdb) bt
#0 0x in ?? ()
#1 0x004128e7 in TCP_Client::unblock_handler (closure=0x1a9f4c0) at
TCP_Client.c++:270
#2 0x004103cc in Scheduler::handle_io (fds=0x17438c0,
fds@entry=0x7ffd982ee5b0, iotype=::FDInfo::read,
iotype@entry=::FDInfo::write) at Scheduler.c++:315
#3 0x00410601 in Scheduler::select () at Scheduler.c++:342
#4 0x00402dc5 in loop () at Scheduler.h:89
#5 main (argc=, argv=0x7ffd982ee828) at main.c++:306
Scheduler::handle_io called the handler, presumably
NetConnection::write_handler()
which called NetConnection::flush() which called NetConnection::set_handlers().
All of those function return void and call the next function right before
returning,
so their stack frames are optimized out.
The relevant code in frame #1 is:
Interest *ip;
while (client->ready_for_events() && (ip = client->to_be_scanned.first()))
{ client->to_be_scanned.remove(ip);
ip->scan();
}
The culprit value of ip:
(gdb) info vtbl ip
vtable for 'Interest' @ 0x1743530 (subobject @ 0x17438c0):
[0]: 0x20
[1]: 0x311
[2]: 0x17431b0
[3]: 0x17438b0
[4]: 0x0
[5]: 0x0
[6]: 0x1743470
[7]: 0x1743396
[8]: 0x0
[9]: 0x0
ip->scan() corresponds to entry [4], callq *0x20(%rdx), hence segv.
I checked the value of ip is correct. Although it was just removed
from the set, the value is consistent with the registers. It is not
an Interest*. In addition, I looked at the 6 key entries in the root
node of the set, defined as Set to_be_scanned; I found:
(gdb) set $i = 0
(gdb) while ($i < 6)
>printf "%s\n",
>typeid(*(*(*(TCP_Client*)0x1a9f4c0).to_be_scanned.root).key[$i]).__name
>set $i = $i + 1
>end
8DirEntry
`
8Interest
8DirEntry
8DirEntry
8DirEntry
So there is a pure abstract element and an unknown pointer.
The diagnosis is garbage in the set. Now this could be a
flaw in BTree.h or something strange in ClientInterest::scan(),
which seems to be the only place where new entries are added
to the set. Ideas?
The key[0] entry is actually a mail server temporary file:
(gdb) p (*(*(*(TCP_Client*)0x1a9f4c0).to_be_scanned.root).key[0]).myname
$1 = 0x18479b0 ".5058547.1517362926.M462851P21244V", '0' ,
"6811I00566211_0.north,S=4981"
(gdb) p
(*(*(*(TCP_Client*)0x1a9f4c0).to_be_scanned.root).key[0]).old_stat.st_mtim
$2 = {tv_sec = 1517563957, tv_nsec = 0}
The tv_sec matches the creation of the core dump, four days ago.
Note that it took weeks to get a core dump. Now I wait for the next.
Ale
-- System Information:
Debian Release: 8.10
APT prefers oldstable-updates
APT policy: (500, 'oldstable-updates'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)
Versions of packages fam depends on:
ii libc6 2.19-18+deb8u10
ii libgcc11:4.9.2-10
ii libstdc++6 4.9.2-10
ii lsb-base 4.1+Debian13+nmu1
ii rpcbind [portmap] 0.2.1-6+deb8u2
ii update-inetd 4.43
fam recommends no packages.
fam suggests no packages.
-- Configuration Files:
/etc/init.d/fam changed:
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
DAEMON="/usr/sbin/famd"
NAME="FAM"
DESC="file alteration monitor"
FAMOPTS="-T 0"
test -x $DAEMON || exit 0
egrep -qs "^(sgi_fam|391002)" /etc/inetd.conf
. /lib/lsb/init-functions
set -e
case "$1" in
start)
status_of_proc $DAEMON $NAME > /dev/null && exit 0
log_daemon_msg "Starting $DESC" "$NAME"
# -ale: was:start-stop-daemon --start --quiet --exec $DAEMON --
$FAMOPTS < /dev/null
(setsid /root/famd-wrapper& )&
log_end_msg $?
;;
stop)
log_daemon_msg "Stopping $DESC" "$NAME"
start-stop-daemon --stop --oknodo --quiet --exec $DAEMON
log_end_msg $?
;;
restart|force-reload)
$0 stop
sleep 1
$0 start
;;
status)
status_of_proc $DAEMON $NAME
;;
*)
echo "Usage: $0 {start|stop|restart|force-reload|status}" >&2
exit 1
;;
esac
exit 0
-- no debconf information
#! /bin/sh
# called from /etc/init.d/fam, where I replaced the start-stop-daemon
#
Bug#888419: pillow: Bad Build-Depends for stretch
Source: pillow Version: 5.0.0 Severity: normal Dear Maintainer, I get: root@:~# apt-get build-dep pillow Reading package lists... Done Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: builddeps:pillow : Depends: python-olefile but it is not installable Depends: python3-olefile but it is not installable Depends: libraqm-dev but it is not installable E: Unable to correct problems, you have held broken packages. However: root@:~# apt-get check && echo ok Reading package lists... Done Building dependency tree Reading state information... Done ok After manually installing Build-Depends packages, except for the three unmet dependencies reported by builddeps above, and additionally installing python- sphinx and python-sphinx-rtd-theme (Build-Depends-Indep mentions the python3 versions of those sphinx packages), then, the command debuild -d -b -uc -us succeeded. So, removing python-olefile, python3-olefile, and libraqm-dev from Build- Depends may suffice. Best Ale -- System Information: Debian Release: 9.3 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-5-amd64 (SMP w/4 CPU cores) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), LANGUAGE=en_IE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: sysvinit (via /sbin/init)
Bug#879008: publicsuffix: effective_tld_names.dat is not upgraded
On Thu 19/Oct/2017 21:10:58 +0200 Daniel Kahn Gillmor wrote: > On Thu 2017-10-19 13:04:13 +0200, Alessandro Vesely wrote: >> >> What do you reckon? > > I'm not particularly interested in setting up cronjobs for people that > (a) introduce new regular network activity and (b) have dubious > cryptographic integrity and public transparency properties. Debian > packages already solve problem (b) and they avoid (a) by piggypacking on > the standard update channels that the operating system already performs. Fine. > Can you motivate your concern about daily updates a little more clearly? > You seem to have a sense of urgency about them that i don't have. Maybe > you're seeing some concern that i'm not seeing, though. I don't really need daily updates, just automated ones. I use the list for looking up DMARC policies, much like opendmarc. A missing update may result in overlooking a domain's policy record. In that case requested reports will not be sent. Most probably, that's not the worst surprise one may expect after opening a mail site under a new TLD. Since mail servers are not obliged to send DMARC reports, nobody will ever notice that failure. Compare that with web usage. Web clients --not servers-- need to have fresh data, lest they miss new domains' cookies. Some Brazilian users would certainly have noticed such failure, and some of them would have complained. Packages which have a sense of urgency include their own PSL. Searching my disk, for example, I get: $ ls -lt `find /usr -type f | xargs grep -l traffic-contro` -rw-r--r-- 1 root root 70512528 Sep 28 23:02 /usr/lib/firefox-esr/libxul.so -rwxr-xr-x 1 root root 95541560 Sep 27 04:03 /usr/bin/chromium-shell -rwxr-xr-x 1 root root 142386136 Sep 27 04:03 /usr/lib/chromium/chromium -rw-r--r-- 1 root root 73807152 Sep 6 18:15 /usr/lib/thunderbird/libxul.so -rw-r--r-- 1 root root 979152 Aug 9 16:31 /usr/lib/x86_64-linux-gnu/libsoup-2.4.so.1.8.0 -rw-r--r-- 1 root root 64892640 Jul 23 14:12 /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/rt.jar -rw-r--r-- 1 root root 36269 Apr 24 09:17 /usr/share/publicsuffix/public_suffix_list.dafsa -rw-r--r-- 1 root root 194948 Apr 24 09:17 /usr/share/publicsuffix/public_suffix_list.dat -rw-r--r-- 1 root root 55136 Jan 24 2017 /usr/lib/x86_64-linux-gnu/libpsl.so.5.1.1 -rw-r--r-- 1 root root5024184 Jan 11 2017 /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.7.1 -rw--- 1 ale ale 1386614784 Nov 28 2016 /usr/lib/mailman/Mailman/core -rw-r--r-- 1 root root3090544 Nov 9 2016 /usr/lib/x86_64-linux-gnu/libQtCore.so.4.8.7 -rw-r--r-- 1 root root 188997 Aug 8 2016 /usr/share/perl5/Domain/PublicSuffix/Default.pm -rw-r--r-- 1 root root 190368 Jul 14 2016 /usr/share/perl5/IO/Socket/SSL/PublicSuffix.pm -rw-r--r-- 1 root root 129891 Jun 14 2015 /usr/share/emacs/24.5/etc/publicsuffix.txt Quite some, eh? Some of them are old, some of them are new Some of them will turn up when you least expect them to And when they do, remember me, remember me. [B. Eno] Packages which are updated less frequently than the PSL have to decide whether to (i) depend on publicsuffix, (ii) compile-in their own version, or (iii) install their own cron job. (ii) implies possibly issuing dummy updates when the list changes. (i)-to-(iii) are meant to be best-to-worst. However, one cannot depend on publicsuffix if it is not updated regularly, so shifting on the worse side becomes compulsory. For a minor point, packages which depend on publicsuffix may need to pre-process the list and cache their own version of the data. If the list gets updated via regular package upgrades, what kind of hook can be provided? Perhaps, /etc/default/publicsuffix could be included, if it exists, by the post-inst script? Hm... is that customary? Ciao Ale
Bug#879008: publicsuffix: effective_tld_names.dat is not upgraded
On Thu 19/Oct/2017 08:06:27 +0200 Daniel Kahn Gillmor wrote: > > The publicsuffix package itself is what most debian packages should rely > on -- It will be updated regularly, and you'll have not only a recent > psl but you won't have to fetch any other data besides package upgrades. > > This is a similar pattern to: > > * tzdata > * dns-root-data > > the update cadence is likely to be faster than dns-root-data, but > probably about the same as tzdata. No, it's much faster. They say once every few days, but there are longer periods of quiescence, irregularly distributed along time. For details see: https://github.com/publicsuffix/list/commits/master > Or is this bug report just asking for a new upload of publicsuffix to > stretch-updates to catch the few dozen domains that have been updated > since stretch was released? That would not be enough. Many servers run on wheezy or jessie. Their best option is to set up a cron job to download the file daily. A more sophisticated user might download the file to a temporary directory, compare it to the existing one, and in case they differ replace the old file and then send a SIGHUP to any daemons which maintain a memory structure of it. Even better, use svn or git to download from github directly. However, this method requires hidden subdirectories, and hence may not seem to be compatible with the current packaging. Finally, consider issuing updates for all debian versions still enjoying long term support (https://wiki.debian.org/LTS). Is it better or worse than the former methods? If a cron job is better, one could be installed in cron.d... What do you reckon? Ciao Ale
Bug#879008: publicsuffix: effective_tld_names.dat is not upgraded
Package: publicsuffix Version: 20170424.0717-1 Severity: normal Dear Maintainer, at publicsuffix.org they recommend to avoid downloading the list too often, and recommend once a day. A dependant package, python-publicsuffix, offers a fetch() function which is explained in a blog: https://www.tablix.org/~avian/blog/archives/2015/07/python_publicsuffix_release_1_1_0/ What is the Debian philosophy here? A debian server could fetch the list daily and then issue a new release only when there is an effective change. That would seem to be optimal. Or maybe that would lead to unmanageably high version numbers? Thank you Ale -- System Information: Debian Release: 9.1 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), LANGUAGE=en_IE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: sysvinit (via /sbin/init) -- no debconf information
Bug#870498: clamav-unofficial-sigs: Option -i (configuration information) shows nothing
Package: clamav-unofficial-sigs Version: 3.7.2-2 Severity: normal Tags: upstream Dear Maintainer, /usr/sbin/clamav-unofficial-sigs -i produces a long report, but the final part of it, after the head: *** SCRIPT CONFIGURATION SETTINGS *** is not at all informative. A possible fix is as follows. (Sorry I cannot send a patch, I just edited it.) Just a couple of lines: echo "*** SCRIPT CONFIGURATION SETTINGS ***" echo "declared from: $default_config" # -ale: this doesn't work with debian config # egrep -v "^#|^$" $default_config env -i bash -c ". $default_config; declare -p" echo "" exit That way, output is as verbose as the preceding one. BTW, may I encourage updates to use more numbers (e.g. 005-clamav-unofficial*.conf) rather than overwrite existing number? I had overridden the 00-*.conf (to make reload_opt appropriate for me) so I was missing curl_connect_timeout, which made curl bail out. If it had been in a 005-*.conf, I would have got it. Just noting the possibility. Thank you for maintaining Debian Ale -- System Information: Debian Release: 8.9 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: sysvinit (via /sbin/init) Versions of packages clamav-unofficial-sigs depends on: ii bind9-host [host] 1:9.9.5.dfsg-9+deb8u13 ii clamav 0.99.2+dfsg-0+deb8u2 ii curl 7.38.0-4+deb8u5 ii dnsutils 1:9.9.5.dfsg-9+deb8u13 ii gnupg 1.4.18-7+deb8u3 ii rsync 3.1.1-3 clamav-unofficial-sigs recommends no packages. Versions of packages clamav-unofficial-sigs suggests: pn clamav-daemon -- no debconf information
Bug#857891: [logrotate does not rotate logs]
On Mon, 20 Mar 2017 21:14:39 +0100 Andreas Henriksson wrote: > [...] > > I thus very much suspect this is an already fixed bug. So is this bug confirmed? TIA Ale
Bug#838654: inkscape: rowstride integer overflow
On Mon 07/Nov/2016 18:21:37 +0100 Mattia Rizzolo wrote: On Fri, Sep 23, 2016 at 12:44:41PM +0200, Alessandro Vesely wrote: I open a new bug, since #838486 is rather different. Could you open a MR (or a bug with patch) upstream for this? That part didn't change at all in trunk, so it should be fairly easy. I compiled 0.92 directly from bzr checkout and, despite the (potentially) buggy code being still there, I wasn't able to reproduce the bug. Trying to edit a poster using Inkscape 0.91 r13725 triggers the error as soon as I click to select a group in the lower right corner. Inkscape 0.92+devel 15229 custom lets me select that group, and move it around at will. Ale
Bug#838486: inkscape: Segmentation fault in 0-48.5 src/display/nr-arena-image.cpp
On Mon 07/Nov/2016 18:16:00 +0100 Mattia Rizzolo wrote: control: tag -1 upstream - patch On Wed, Sep 21, 2016 at 09:26:10PM +0200, Alessandro Vesely wrote: I'll try and reapply the latter patch tomorrow, and see how it goes. How did that go? I sent a patch to Pixman's fast-path a month ago, and then a couple of messages to their mailing list, but didn't hear any more since the last I wrote. See (older to newer): https://bugs.freedesktop.org/show_bug.cgi?id=97938 https://lists.freedesktop.org/archives/pixman/2016-October/004647.html https://lists.freedesktop.org/archives/pixman/2016-October/004648.html https://lists.freedesktop.org/archives/pixman/2016-October/004653.html Note that what I sent are just some probationary patches looking for a resolution. Also, would you mind checking this upstream with 0.92 and possibly forward port your patch to that too (and send the bug/MR upstream)? I plan to put the pre-releases of 0.92 in experimental at one point if you want prefer to wait for that (i.e. if you don't play nice with bzr). IIR, the only other rowstride-overflow bug was in cairo: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=838648 Thus, the burden lies rather with the accompanying libraries than inkscape sources proper. Ale
Bug#838654: inkscape: rowstride integer overflow
Package: inkscape
Version: 0.91-5~bpo8+1
Severity: normal
Tags: upstream patch
Dear Mattia,
I open a new bug, since #838486 is rather different. The same idiom, however,
appears in the latest version of drawing-image.cpp. With the patch attached,
and some other patches in pixman (#838650) and cairo (#838648) i was able to
edit a large file, save a pdf copy of it, and view it with evince :-) I don't
know how epidemic the idiom is.
Best
Ale
-- System Information:
Debian Release: 8.6
APT prefers testing
APT policy: (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages inkscape depends on:
ii gconf-service 3.2.6-3
ii libaspell150.60.7~20110707-1.3
ii libatk1.0-02.14.0-1
ii libatkmm-1.6-1 2.22.7-2.1
ii libc6 2.19-18+deb8u6
ii libcairo2 1.14.0-2.1+deb8u1
ii libcairomm-1.0-1 1.10.0-1.1
ii libcdr-0.1-1 0.1.0-3
ii libexif12 0.6.21-2
ii libfontconfig1 2.11.0-6.3+deb8u1
ii libfreetype6 2.5.2-3+deb8u1
ii libgc1c2 1:7.2d-6.4
ii libgcc11:4.9.2-10
ii libgconf-2-4 3.2.6-3
ii libgdk-pixbuf2.0-0 2.31.1-2+deb8u5
ii libglib2.0-0 2.42.1-1+b1
ii libglibmm-2.4-1c2a 2.42.0-1
ii libgnomevfs2-0 1:2.24.4-6+b1
ii libgomp1 4.9.2-10
ii libgsl0ldbl1.16+dfsg-2
ii libgtk2.0-02.24.25-3+deb8u1
ii libgtkmm-2.4-1c2a 1:2.24.4-1.1
ii libgtkspell0 2.0.16-1.1
ii libjpeg8 8d-1+deb7u1
ii liblcms2-2 2.6-3+b3
ii libmagick++-6.q16-58:6.8.9.9-5+deb8u4
ii libmagickcore-6.q16-2 8:6.8.9.9-5+deb8u4
ii libmagickwand-6.q16-2 8:6.8.9.9-5+deb8u4
ii libpango-1.0-0 1.36.8-3
ii libpangocairo-1.0-01.36.8-3
ii libpangoft2-1.0-0 1.36.8-3
ii libpangomm-1.4-1 2.34.0-1.1
ii libpng12-0 1.2.50-2+deb8u2
ii libpoppler-glib8 0.26.5-2+deb8u1
ii libpoppler46 0.26.5-2+deb8u1
ii libpopt0 1.16-10
ii librevenge-0.0-0 0.0.1-3
ii libsigc++-2.0-0c2a 2.4.0-1
ii libstdc++6 4.9.2-10
ii libvisio-0.1-1 0.1.0-2
ii libwpg-0.3-3 0.3.0-3
ii libx11-6 2:1.6.2-3
ii libxml22.9.1+dfsg1-5+deb8u3
ii libxslt1.1 1.1.28-2+deb8u1
pn python:any
ii zlib1g 1:1.2.8.dfsg-2+b1
Versions of packages inkscape recommends:
ii aspell0.60.7~20110707-1.3
ii imagemagick 8:6.8.9.9-5+deb8u4
ii libgnomevfs2-extra1:2.24.4-6+b1
ii libimage-magick-perl 8:6.8.9.9-5+deb8u4
ii libwmf-bin0.2.8.4-10.3+deb8u1
ii pstoedit 3.62-2+b1
ii python-lxml 3.4.0-1
ii python-numpy 1:1.8.2-2
ii transfig 1:3.2.5.e-4
Versions of packages inkscape suggests:
ii dia 0.97.3-1
ii dia-gnome0.97.3-1
ii libsvg-perl 2.59-1
ii libxml-xql-perl 0.68-6
ii python-uniconvertor 1.1.4-1+b2
ii ruby 1:2.1.5+deb8u2
ii ruby1.8 [ruby] 1.8.7.358-7.1+deb7u3
-- no debconf information
Description: rowstride should be size_t
it is wrong to compute offsets like so:
int rowstride = something;
char *buffer = base_ptr + y*rowstride + x*4;
That idiom fails in 64bit architectures where integers are 32 bit. Consider
for example an A0 poster at 600 dpi brings a 19860x28080 image. While width
and heights are 16 bit numbers, their product multiplied by a bpp of 4 results
in a negative integer.
Stride should be size_t, or, if it can be negative, long integer.
--- inkscape-0.91.orig/src/display/drawing-image.cpp
+++ inkscape-0.91/src/display/drawing-image.cpp
@@ -209,9 +209,9 @@ DrawingImage::_pickItem(Geom::Point cons
} else {
unsigned char *const pixels = _pixbuf->pixels();
-int width = _pixbuf->width();
-int height = _pixbuf->height();
-int rowstride = _pixbuf->rowstride();
+unsigned width = _pixbuf->width();
+unsigned height = _pixbuf->height();
+unsigned rowstride = _pixbuf->rowstride();
Geom::Point tp = p * _ctm.inverse();
Geom::Rect r = bounds();
@@ -221,13 +221,13 @@ DrawingImage::_pickItem(Geom::Point cons
double vw = width * _scale[Geom::X];
double vh = height * _scale[Geom::Y];
-int ix = floor((tp[Geom::X] - _origin[Geom::X]) / vw * width);
-int iy = floor((tp[Geom::Y] - _origin[Geom::Y]) / vh * height);
+unsigned ix = floor((tp[Geom::X] - _origin[Geom::X]) / vw * width);
+unsigned iy = floor((tp[Geom::Y] - _origin[Geom::Y]) / vh * height);
-if ((ix < 0) || (iy < 0) || (ix >= width) || (iy >= height))
+
Bug#832579: pixman: SIGSEGV after rowstride overflow in large image
This bug is a duplicate of bug #838650. Please close it.
Bug#838650: pixman: rowstride integer overflow
Source: pixman
Version: pixman-0.32.6
Severity: normal
Tags: upstream patch
Dear Maintainer,
it is wrong to compute offsets like so:
int rowstride = something;
char *buffer = base_ptr + y*rowstride + x*4;
That idiom fails in 64bit architecture where integers are 32 bit. Consider a
not-so-uncommon A0 poster at 600 dpi. It results in a 19860x28080 image.
While width and heights are 16 bit numbers, their product multiplied by a bpp
of 4 results in a negative integer.
Strides should be type size_t, or, if they can be negative, long integer.
The patch I attach just avoids crashes in various clients (inkscape, evince).
Package authors may want to carry out a clearer change.
Ale
-- System Information:
Debian Release: 8.6
APT prefers stable
APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
--- a/pixman/pixman-fast-path.c
+++ b/pixman/pixman-fast-path.c
@@ -2798,7 +2798,7 @@
repeat (repeat_mode, , bits->width);
repeat (repeat_mode, , bits->height);
- row = (uint8_t *)bits->bits + bits->rowstride * 4 * ry;
+ row = (uint8_t *)bits->bits + (long)bits->rowstride * 4L * (long)ry;
pixel = convert_pixel (row, rx) | mask;
}
else
@@ -2809,7 +2809,7 @@
}
else
{
-row = (uint8_t *)bits->bits + bits->rowstride * 4 * ry;
+row = (uint8_t *)bits->bits + (long)bits->rowstride * 4L * (long)ry;
pixel = convert_pixel (row, rx) | mask;
}
}
@@ -2911,8 +2911,8 @@
repeat (repeat_mode, , width);
repeat (repeat_mode, , height);
- row1 = (uint8_t *)bits->bits + bits->rowstride * 4 * y1;
- row2 = (uint8_t *)bits->bits + bits->rowstride * 4 * y2;
+ row1 = (uint8_t *)bits->bits + (long)bits->rowstride * 4L * (long)y1;
+ row2 = (uint8_t *)bits->bits + (long)bits->rowstride * 4L * (long)y2;
tl = convert_pixel (row1, x1) | mask;
tr = convert_pixel (row1, x2) | mask;
@@ -2947,7 +2947,7 @@
}
else
{
- row1 = (uint8_t *)bits->bits + bits->rowstride * 4 * y1;
+ row1 = (uint8_t *)bits->bits + (long)bits->rowstride * 4L * (long)y1;
row1 += bpp / 8 * x1;
mask1 = PIXMAN_FORMAT_A (format)? 0 : 0xff00;
@@ -2960,7 +2960,7 @@
}
else
{
- row2 = (uint8_t *)bits->bits + bits->rowstride * 4 * y2;
+ row2 = (uint8_t *)bits->bits + (long)bits->rowstride * 4L * (long)y2;
row2 += bpp / 8 * x1;
mask2 = PIXMAN_FORMAT_A (format)? 0 : 0xff00;
@@ -3058,7 +3058,7 @@
repeat (repeat_mode, , height);
}
- row = (uint8_t *)bits->bits + bits->rowstride * 4 * y0;
+ row = (uint8_t *)bits->bits + (long)bits->rowstride * 4L * (long)y0;
buffer[i] = convert_pixel (row, x0) | mask;
}
Bug#838648: libcairo2: rowstride integer overflow
Package: libcairo2
Version: cairo-1.14.0
Severity: normal
Tags: upstream patch
Dear Maintainer,
it is wrong to compute offsets like so:
int rowstride = something;
char *buffer = base_ptr + y*rowstride + x*4;
That idiom fails in 64bit architecture where integers are 32 bit. Consider
that an A0 poster at 600 dpi brings a 19860x28080 image. While width and
heights are 16 bit numbers, their product multiplied by a bpp of 4 results in a
negative integer. Stride should be size_t, or, if it can be negative, long
integer.
The concept is illustrated by the last few lines of the gdb session I paste
below, which I used to find one of the patched locations.
$ gdb -q --args /usr/bin/inkscape -A test-pdf.pdf test-pdf.svg
Reading symbols from /usr/bin/inkscape...done.
(gdb) run
Starting program: /usr/bin/inkscape -A test-pdf.pdf test-pdf.svg
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Program received signal SIGSEGV, Segmentation fault.
__memcpy_sse2_unaligned () at ../sysdeps/x86_64/multiarch/memcpy-
sse2-unaligned.S:118
118 ../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S: No such file or
directory.
(gdb) up
#1 0x7fffef68394d in memcpy (__len=, __src=,
__dest=) at /usr/include/x86_64-linux-gnu/bits/string3.h:51
51return __builtin___memcpy_chk (__dest, __src, __len, __bos0
(__dest));
(gdb) up
#2 _cairo_image_surface_snapshot (abstract_surface=0x5c6a61d0) at
.../../../../src/cairo-image-surface.c:792
792 memcpy (clone->data, image->data, clone->stride *
clone->height);
(gdb) whatis clone->stride
type = int
(gdb) p /x (size_t)(clone->stride * clone->height)
$1 = 0x85082c58
(gdb) p /x (size_t)((long)clone->stride * clone->height)
$2 = 0x85082c58
(gdb)
-- System Information:
Debian Release: 8.6
APT prefers stable
APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
--- cairo-1.14.0.orig/src/cairo-image-surface.c
+++ cairo-1.14.0/src/cairo-image-surface.c
@@ -789,7 +789,7 @@ _cairo_image_surface_snapshot (void *abs
return >base;
if (clone->stride == image->stride) {
- memcpy (clone->data, image->data, clone->stride * clone->height);
+ memcpy (clone->data, image->data, (long)clone->stride * clone->height);
} else {
pixman_image_composite32 (PIXMAN_OP_SRC,
image->pixman_image, NULL, clone->pixman_image,
Description: integer-overflow
--- cairo-1.14.0.orig/src/cairo-pdf-surface.c
+++ cairo-1.14.0/src/cairo-pdf-surface.c
@@ -2500,7 +2500,7 @@ _cairo_pdf_surface_emit_image (cairo_pdf
i = 0;
for (y = 0; y < image->height; y++) {
- pixel = (uint32_t *) (image->data + y * image->stride);
+ pixel = (uint32_t *) (image->data + (long)y * image->stride);
bit = 7;
for (x = 0; x < image->width; x++, pixel++) {
Bug#838486: inkscape: Segmentation fault in 0-48.5 src/display/nr-arena-image.cpp
Hi Mattia, On Wed 21/Sep/2016 16:54:02 +0200 Mattia Rizzolo wrote: On Wed, Sep 21, 2016 at 02:13:24PM +0200, Alessandro Vesely wrote: $ gdb -q --args /usr/bin/inkscape test-pdf.svg Reading symbols from /usr/bin/inkscape...done. (gdb) run Starting program: /usr/bin/inkscape test-pdf.svg [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [New Thread 0x7fffe66dd700 (LWP 14025)] [New Thread 0x7fff5442f700 (LWP 14030)] [New Thread 0x7fff53bce700 (LWP 14033)] Program received signal SIGSEGV, Segmentation fault. nr_arena_image_pick (item=0x29f5e00, p=..., delta=) at display /nr-arena-image.cpp:318 318 return (pix_ptr[3] > 0) ? item : NULL; nasty crash. Now, that's the stable release, though. And most of the development efforts are concentrated in unstable. Can you please check whether the crash happens with 0.91? you can just use what you find in jessie-backports for that. I got a crash at a different point: $ gdb -q --args /usr/bin/inkscape test-pdf.svg Reading symbols from /usr/bin/inkscape...done. (gdb) run Starting program: /usr/bin/inkscape test-pdf.svg [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [New Thread 0x7fffe3026700 (LWP 21884)] [New Thread 0x7fff4c92b700 (LWP 21885)] [New Thread 0x7fff47f9f700 (LWP 21886)] Program received signal SIGSEGV, Segmentation fault. bits_image_fetch_separable_convolution_affine (repeat_mode=PIXMAN_REPEAT_NONE, format=PIXMAN_a8r8g8b8, convert_pixel=, mask=0x0, buffer=0x7fff4090, width=, line=, offset=, image=0x61e82e80) at ../../pixman/pixman-fast-path.c:2813 2813../../pixman/pixman-fast-path.c: No such file or directory. (gdb) This looks similar to an older bug I reported in July: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=832579 I'll try and reapply the latter patch tomorrow, and see how it goes. Ale
Bug#838486: inkscape: Segmentation fault in 0-48.5 src/display/nr-arena-image.cpp
Package: inkscape
Version: 0.48.5-3
Severity: normal
Tags: patch
Dear Maintainer,
$ gdb -q --args /usr/bin/inkscape test-pdf.svg
Reading symbols from /usr/bin/inkscape...done.
(gdb) run
Starting program: /usr/bin/inkscape test-pdf.svg
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffe66dd700 (LWP 14025)]
[New Thread 0x7fff5442f700 (LWP 14030)]
[New Thread 0x7fff53bce700 (LWP 14033)]
Program received signal SIGSEGV, Segmentation fault.
nr_arena_image_pick (item=0x29f5e00, p=..., delta=) at display
/nr-arena-image.cpp:318
318 return (pix_ptr[3] > 0) ? item : NULL;
(gdb) p pix_ptr[3]
Cannot access memory at address 0x7ffedc831b83
(gdb) p /x pixels
$1 = 0x7fff5af7d010
(gdb) p /x pixels + iy * image->pxrs + ix * 4
$2 = 0x7fffdc831b80
(gdb) p /x malloc_usable_size(pixels)
[Thread 0x7fff53bce700 (LWP 14033) exited]
$3 = 0x85082ff0
(gdb) p /x pixels + malloc_usable_size(pixels)
$4 = 0x7ffee000
(gdb) p /x pixels + (unsigned)malloc_usable_size(pixels)
$5 = 0x7fffe000
(gdb) p /x pixels + (unsigned)(iy * image->pxrs + ix * 4)
$6 = 0x7fffdc831b80
(gdb) p /x pix_ptr
$7 = 0x7ffedc831b80
(gdb) whatis image->pxrs
type = unsigned int
(gdb) q
A debugging session is active.
Inferior 1 [process 14021] will be killed.
Quit anyway? (y or n) y
ale@pcale:~/g/nano2016$
-- System Information:
Debian Release: 8.6
APT prefers stable
APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages inkscape depends on:
ii gconf-service 3.2.6-3
ii libaspell150.60.7~20110707-1.3
ii libatk1.0-02.14.0-1
ii libatkmm-1.6-1 2.22.7-2.1
ii libc6 2.19-18+deb8u6
ii libcairo2 1.14.0-2.1+deb8u1
ii libcairomm-1.0-1 1.10.0-1.1
ii libfontconfig1 2.11.0-6.3+deb8u1
ii libfreetype6 2.5.2-3+deb8u1
ii libgc1c2 1:7.2d-6.4
ii libgcc11:4.9.2-10
ii libgconf-2-4 3.2.6-3
ii libgdk-pixbuf2.0-0 2.31.1-2+deb8u5
ii libglib2.0-0 2.42.1-1+b1
ii libglibmm-2.4-1c2a 2.42.0-1
ii libgnomevfs2-0 1:2.24.4-6+b1
ii libgomp1 4.9.2-10
ii libgsl0ldbl1.16+dfsg-2
ii libgtk2.0-02.24.25-3+deb8u1
ii libgtkmm-2.4-1c2a 1:2.24.4-1.1
ii libgtkspell0 2.0.16-1.1
ii liblcms2-2 2.6-3+b3
ii libmagick++-6.q16-58:6.8.9.9-5+deb8u4
ii libmagickcore-6.q16-2 8:6.8.9.9-5+deb8u4
ii libmagickwand-6.q16-2 8:6.8.9.9-5+deb8u4
ii libpango-1.0-0 1.36.8-3
ii libpangocairo-1.0-01.36.8-3
ii libpangoft2-1.0-0 1.36.8-3
ii libpangomm-1.4-1 2.34.0-1.1
ii libpng12-0 1.2.50-2+deb8u2
ii libpoppler-glib8 0.26.5-2+deb8u1
ii libpoppler46 0.26.5-2+deb8u1
ii libpopt0 1.16-10
ii librevenge-0.0-0 0.0.1-3
ii libsigc++-2.0-0c2a 2.4.0-1
ii libstdc++6 4.9.2-10
ii libwpg-0.3-3 0.3.0-3
ii libx11-6 2:1.6.2-3
ii libxml22.9.1+dfsg1-5+deb8u3
ii libxslt1.1 1.1.28-2+deb8u1
pn python:any
ii zlib1g 1:1.2.8.dfsg-2+b1
Versions of packages inkscape recommends:
ii aspell 0.60.7~20110707-1.3
ii imagemagick8:6.8.9.9-5+deb8u4
ii libgnomevfs2-extra 1:2.24.4-6+b1
ii libimage-magick-perl [perlmagick] 8:6.8.9.9-5+deb8u4
ii libwmf-bin 0.2.8.4-10.3+deb8u1
ii perlmagick 8:6.8.9.9-5+deb8u4
ii pstoedit 3.62-2+b1
ii python-lxml3.4.0-1
ii python-numpy 1:1.8.2-2
ii transfig 1:3.2.5.e-4
Versions of packages inkscape suggests:
ii dia 0.97.3-1
ii dia-gnome0.97.3-1
ii libsvg-perl 2.59-1
ii libxml-xql-perl 0.68-6
ii python-uniconvertor 1.1.4-1+b2
ii ruby 1:2.1.5+deb8u2
ii ruby1.8 [ruby] 1.8.7.358-7.1+deb7u3
-- no debconf information
--- a/src/display/nr-arena-image.cpp
+++ b/src/display/nr-arena-image.cpp
@@ -303,17 +303,17 @@
} else {
unsigned char *const pixels = image->px;
-int const width = image->pxw;
-int const height = image->pxh;
-int const rowstride = image->pxrs;
+unsigned int const width = (unsigned int)(image->pxw);
+unsigned int const height = (unsigned int)(image->pxh);
+unsigned int const rowstride = (unsigned int)(image->pxrs);
Geom::Point tp = p * image->grid2px;
-int const ix = (int)(tp[Geom::X]);
-int const iy = (int)(tp[Geom::Y]);
+unsigned int const ix = (unsigned
Bug#832579: pixman: SIGSEGV after rowstride overflow in large image
Source: pixman Version: 0.32.6 Severity: normal Tags: patch Dear Maintainer, the following message was being written by dbg after launching evince on a pdf containing a heavy image: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffe5f92700 (LWP 32388)] bits_image_fetch_bilinear_affine (repeat_mode=PIXMAN_REPEAT_PAD, format=PIXMAN_x8r8g8b8, convert_pixel=, mask=0x7fffe5f8a5a0, buffer=0x7fffe5f8a3a0, width=, line=, offset=, image=0x7fffd00c4ea0) at ../../pixman/pixman-fast-path.c:2917 In order to understand the bug severity, consider that I obtained a large image by exporting a 600dpi bitmap of an A0 poster. Then I converted it to pdf. I brought an USB key with the resulting 170MB document to the print shop down the road and got a hard copy. Their plotter resolves 600dpi, and although it takes a few minutes to load the file, producing that kind of files is still the most practical approach, in my experience. The nature of the bug is clear from the following excerpt: (gdb) info locals [...] width = 19866 height = 28087 row1 = 0x7ffe8f375618 row2 = 0x7ffe8f388c80 Indeed, after applying the patch I attach, evince works well. Ale -- System Information: Debian Release: 8.5 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) --- a/pixman/pixman-fast-path.c +++ b/pixman/pixman-fast-path.c @@ -2911,8 +2911,8 @@ repeat (repeat_mode, , width); repeat (repeat_mode, , height); - row1 = (uint8_t *)bits->bits + bits->rowstride * 4 * y1; - row2 = (uint8_t *)bits->bits + bits->rowstride * 4 * y2; + row1 = (uint8_t *)bits->bits + (long)bits->rowstride * 4L * (long)y1; + row2 = (uint8_t *)bits->bits + (long)bits->rowstride * 4L * (long)y2; tl = convert_pixel (row1, x1) | mask; tr = convert_pixel (row1, x2) | mask;
Bug#807316: jwhois: WHOIS vs RDAP or WhoisRWS
Package: jwhois Version: 4.0-2.1 Severity: wishlist Tags: upstream Dear Maintainer, I looked up an abuse address for 192.254.239.154 and found supp...@websitewelcome.com. The mail bounced. I thought I'd report invalid WHOIS data, but instead report this. Because ARIN's web page returned a valid, different email address. How come? My guess is that nowadays they use WhoisRWS, which, as I understand it, is RDAP using XML rather than JSON. Apparently, they consider WHOIS so disused that they don't bother removing a redirection pointing to an outdated WHOIS server at websitewelcome.com. This whishlist entry asks that jwhois makes RDAP queries and falls back to WHOIS for legacy servers only, so as to make the transition smooth. Alternatively, jwhois could stick to the WHOIS protocol; in this case an outstanding warning should appear in its man page. Thank you Ale -- System Information: Debian Release: 8.2 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages jwhois depends on: ii adduser 3.113+nmu3 ii dpkg 1.17.26 ii install-info 5.2.0.dfsg.1-6 ii libc6 2.19-18+deb8u1 ii libgdbm3 1.8.3-13.1 Versions of packages jwhois recommends: ii lynx 2.8.9dev1-2+deb8u1 jwhois suggests no packages. -- no debconf information
Bug#783228: clamav-unofficial-sigs: securiteinfo databases not available any more
Package: clamav-unofficial-sigs Version: 3.7.1-3 Severity: minor Tags: upstream The si_dbs=[...] entry should be commented out from /usr/share/clamav-unofficial-sigs/conf.d/00-clamav-unofficial-sigs.conf See this post by Steve Basford: http://lurker.clamav.net/message/20150423.072453.3394b584.en.html -- System Information: Debian Release: 7.8 APT prefers stable-updates APT policy: (920, 'stable-updates'), (900, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.65ale23 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages clamav-unofficial-sigs depends on: ii bind9-host [host] 1:9.8.4.dfsg.P1-6+nmu2+deb7u4 ii clamav 0.98.6+dfsg-0+deb7u1 ii curl 7.26.0-1+wheezy13 ii dnsutils 1:9.8.4.dfsg.P1-6+nmu2+deb7u4 ii gnupg 1.4.12-7+deb7u7 ii rsync 3.0.9-4 clamav-unofficial-sigs recommends no packages. Versions of packages clamav-unofficial-sigs suggests: pn clamav-daemon none -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#773428: jwhois: no option to skip rwhois redirection
Package: jwhois Version: 4.0-2.1 Severity: wishlist Tags: upstream Dear Maintainer, please file a request upstream to avoid following some redirections I need this if I query, for example: jwhois 192.254.235.94 This brings up a poor page, which has no abuse contact information. Arin is very careful about abuse contacts, and if one uses -n the page includes OrgAbuseEmail. However, routinely using -n skips _all_ redirections, for example: jwhois -n 182.50.169.128 does not redirect to apnic, and one gets OrgAbuseEmail: search- apnic-not-a...@apnic.net. Perhaps, following whois redirections only (not rwhois) would work in both cases? Thank you for your attention Alessandro -- System Information: Debian Release: 7.7 APT prefers stable-updates APT policy: (920, 'stable-updates'), (900, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.51ale22 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages jwhois depends on: ii adduser 3.113+nmu3 ii dpkg 1.16.15 ii install-info 4.13a.dfsg.1-10 ii libc6 2.13-38+deb7u6 ii libgdbm3 1.8.3-11 Versions of packages jwhois recommends: ii lynx 2.8.8dev.12-2 jwhois suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#761632: gwhois: Add .fail TLD
Package: gwhois Version: 20120626 Severity: normal Tags: upstream Dear Maintainer, please add this to the pattern file: :whois|whois.donuts.co \.fail$ (per http://www.iana.org/domains/root/db/fail.html) For example, domain dmarc.fail was registered to handle From: rewriting of mailing list addresses that would otherwise fail dmarc policy (funny). Ale -- System Information: Debian Release: 7.6 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gwhois depends on: ii curl 7.26.0-1+wheezy9 ii debconf [debconf-2.0] 1.5.49 ii libnet-libidn-perl 0.12.ds-1+b3 ii libwww-perl6.04-1 ii lynx-cur 2.8.8dev.12-2 ii perl 5.14.2-21+deb7u1 gwhois recommends no packages. Versions of packages gwhois suggests: ii openbsd-inetd [inet-superserver] 0.20091229-2 -- debconf information: gwhois/inetd: false gwhois/noinetd: -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#761162: clamav-unofficial-sigs: Cron job results spread onto mail and logs
On Fri 12/Sep/2014 02:46:06 +0200 Paul Wise wrote:
On Thu, 2014-09-11 at 19:10 +0200, Alessandro Vesely wrote:
I'd rather suggest something along the lines of the attached patch
(not tested). It should get rid of some cron spam. For reporting, I
think libclamav does issue some warnings if a database is unacceptably
old, not sure that covers all databases though.
Two issues with the patch:
I don't think hardcoding the version number in user-agent is a good
idea. I also don't think setting a version number in user-agent is
useful either.
It would be helpful for webmasters at the distributing sites if they
can trace specific behavior to possible problems in the client
software.
I also don't want the clamav-unofficial-sigs user-agent to be
specific to Debian so that part of the patch will be removed until
Bill adds it to the official version.
Fully agreed, the patch was actually meant for Bill.
You removed the comparison between the original dbs in the clamav
directory and the newly downloaded dbs.
One gets a 304 reply if the file was changed. I concur that a dummy
change (`touch`) would still cause the database to be reprocessed and
reloaded, but don't think we should expect such kind of attack from a
server.
You can change the default URL by putting si_url=... here:
/etc/clamav-unofficial-sigs.conf.d/sanesecurl.conf
Hm... that would work if those assignments were done before sourcing
$config_source.
I guess you missed that the main configuration file sources the files in
the conf.d directory (as well as the ones in /usr):
/etc/clamav-unofficial-sigs.conf
I had looked at that, it's cute. But comes at line 604.
Alternatively:
--- clamav-unofficial-sigs-3.7.2/clamav-unofficial-sigs.sh 2013-08-27
18:08:25.0 +0200
+++ clamav-unofficial-sigs-3.7.2/clamav-unofficial-sigs-patched2.sh
2014-09-12 09:49:51.0 +0200
@@ -751,7 +751,7 @@
fi
# Unofficial ClamAV database provider URLs
-ss_url=rsync.sanesecurity.net
+ss_url=${ss_premium_url:-rsync.sanesecurity.net}
si_url=clamav.securiteinfo.com
mbl_url=www.malwarepatrol.net
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#761162: clamav-unofficial-sigs: Cron job results spread onto mail and logs
Package: clamav-unofficial-sigs Version: 3.7.1-3 Severity: normal Dear Maintainer, this bug is different from bug #704656, albeit similar: The issue here is the output of curl not redirected, rather than the output of clamscan not being redirected. I frequently receive mail to clamav@`hostname` from the Cron Daemon, saying curl: (28) connect() timed out!, one or more times. Perhaps, that recipient address should be configurable. Looking at the log file, I find corresponding lines: Sep 11 02:52:07 WARNING - Failed curl connection to clamav.securiteinfo.com - SKIPPED SecuriteInfo securiteinfodos.hdb update Sep 11 02:52:22 WARNING - Failed curl connection to clamav.securiteinfo.com - SKIPPED SecuriteInfo securiteinfoelf.hdb update Sep 11 02:52:37 WARNING - Failed curl connection to clamav.securiteinfo.com - SKIPPED SecuriteInfo securiteinfo.hdb update The above results from standard package installation. The missing info is how severe those warnings are. When have those files been last updated? Note that there are other files downloaded from the same host. So connect() fails intermittently. The page at http://sanesecurity.com/donate/ says one can get a better url by paying for the service. However, shell variable si_url is hardcoded in clamav-unofficial- sigs.sh. Perhaps, making it configurable may encourage donations. In fact, it is not clear whether that host is managed by Sanesecurity or SecuriteInfo. Thank you Ale -- System Information: Debian Release: 7.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.51ale22 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages clamav-unofficial-sigs depends on: ii bind9-host [host] 1:9.8.4.dfsg.P1-6+nmu2+deb7u1 ii clamav 0.98.4+dfsg-0+deb7u2 ii curl 7.26.0-1+wheezy9 ii dnsutils 1:9.8.4.dfsg.P1-6+nmu2+deb7u1 ii gnupg 1.4.12-7+deb7u4 ii rsync 3.0.9-4 clamav-unofficial-sigs recommends no packages. Versions of packages clamav-unofficial-sigs suggests: pn clamav-daemon none -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#761162: clamav-unofficial-sigs: Cron job results spread onto mail and logs
On Thu 11/Sep/2014 12:20:11 +0200 Paul Wise wrote:
Bill, would it be possible for you to update clamav-unofficial-sigs so
that only signature downtime of more than one day is reported by the
cron job? The current setup means that many admins are getting a lot of
non-actionable cron spam, myself included.
I'd rather suggest something along the lines of the attached patch
(not tested). It should get rid of some cron spam. For reporting, I
think libclamav does issue some warnings if a database is unacceptably
old, not sure that covers all databases though.
shell variable si_url is hardcoded in clamav-unofficial-
sigs.sh. Perhaps, making it configurable may encourage
donations. In fact, it is not clear whether that host
is managed by Sanesecurity or SecuriteInfo.
At a closer look, it /is/ clear: Sanesecurity rate SecuriteInfo
databases, but neither produce nor distribute them. Sorry for the
confusion.
You can change the default URL by putting si_url=... here:
/etc/clamav-unofficial-sigs.conf.d/sanesecurl.conf
Hm... that would work if those assignments were done before sourcing
$config_source.
I doubt the premium mirrors would resolve this issue though.
You're right. Unlike Sanesecurity, SecuriteInfo have no premium
mirror. Instead, they warn not to download files more than once a day
on pain of ip-ban[1]. Hence, I changed to 24 the default
si_update_hours (it is 4 in the dist clamav-unofficial-sigs.conf).
Ciao
Ale
[1]:
https://www.securiteinfo.com/services/clamav_unofficial_malwares_signatures.shtml
--- clamav-unofficial-sigs-3.7.2/clamav-unofficial-sigs.sh 2013-08-27
18:08:25.0 +0200
+++ clamav-unofficial-sigs-3.7.2/clamav-unofficial-sigs-patched.sh
2014-09-11 15:36:46.0 +0200
@@ -869,7 +869,7 @@
# Silence curl output and only report errors - useful if script is run via
cron.
if [ $curl_silence = yes ] ; then
- curl_output_level=-s -S
+ curl_output_level=-s -f
fi
# If ClamD status check is enabled (clamd_socket variable is uncommented
@@ -1166,12 +1166,16 @@
else
z_opt=
fi
-if curl $curl_proxy $curl_output_level --connect-timeout
$curl_connect_timeout \
- --max-time $curl_max_time -L -R $z_opt -o $si_dir/$db_file
http://$si_url/$db_file
+curl_output=$(curl $curl_proxy $curl_output_level
--connect-timeout $curl_connect_timeout \
+ --max-time $curl_max_time -L -R $z_opt -o $si_dir/$db_file \
+ --user-agent clamav-unofficial-sigs/3.7.2 --write-out
http_code=%{http_code} http://$si_url/$db_file)
+curl_rtc=$?
+if [ $curl_rtc -eq 0 ]
then
loop=1
- if ! cmp -s $si_dir/$db_file $clam_dbs/$db_file ; then
- if [ $? = 0 ] ; then
+ eval $curl_output
+ if [ $http_code -eq 200 ]
+ then
db_ext=`echo $db_file | cut -d . -f2`
comment
comment Testing updated SecuriteInfo database file:
$db_file
@@ -1231,10 +1235,12 @@
log WARNING - Failed to successfully
update SecuriteInfo production database file: $db_file - SKIPPING
fi
fi
- fi
+ elif [ $http_code -ne 304 ]
+ then
+log WARNING - Failed download from $si_url (http
reply code $http_code) - SKIPPED SecuriteInfo $db_file update
fi
else
- log WARNING - Failed curl connection to $si_url - SKIPPED
SecuriteInfo $db_file update
+ log WARNING - Failed curl connection to $si_url (exit code
$curl_rtc) - SKIPPED SecuriteInfo $db_file update
fi
if [ $si_db_update != 1 ] ; then
comment
Bug#102186: checksecurity and fuse.sshfs
I see this bug is still open. I'm not familiar with smbfs, but I get the same error as in the original report with user's networked files: /etc/cron.weekly/checksecurity: find: `/my/mount/point': Permission denied find: `/my/mount/point': Permission denied find: `/my/mount/point': Permission denied where /my/mount/point is of type fuse.sshfs. While the behavior described by Justin (quoted below) may look like an actual malfunction or error, hiding remote files is a designed feature of sshfs. I reported the latter as bug# 724690. Note: The mountpoint does not appear among find's arguments, as it is correctly filtered by grep. It is encountered while descending from /. AFAIK there is no way find can learn that it is crossing a filesystem boundary, because if I try to stat the mountpoint as root, I get a 'Permission denied' error, each and every time. On 09/04/04 07:26, Justin Pryzby wrote: FWIW, I experience the same daily error email from checksecurity. I have, in the past, theorized that its actually a kernel smbfs problem. Here's what I've observed. When an smb mount goes unused for a long time, manipulating it (with stat, apparently) hangs for a few seconds, then dies with an error. _Immediately_ after the error, rerunning the command results in success. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695751: depending on a script that depends on $all (including by not having LSB headers) creates loop
On 26/01/13 18:55, Ben Hutchings wrote: Russ allbery wrote: We've encountered this problem many times with locally-written init scripts without LSB headers, since they get an implicit dependency on $all, which will create a loop if there is any other header with an implicit dependency on $all. But the best solution is to just add LSB headers. [...] Right. This probably merits a mass bug filing on packages with such scripts *after* wheezy. I can't believe it's serious enough to need fixing right now. I agree that adding the correct LSB headers is the right course of action. However, having insserv performing a stable sort could avoid to exacerbate this kind of problems, and still allow classical start order tampering for those who can't resist it. (I'm surviving with the fix-init script attached to bug #711853) Ale -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#718434: Bug #718434, please leave CAcert as is
On Thu 05/Dec/2013 20:16:57 +0100 Geoffrey Thomas wrote: Can you quantify what you mean by useful and handy? It is just convenient. Using curl, for example, you can skip some prior settings and command line options. If there are use cases for CAcert other than the fact that their certificates are free-of-charge, I'd be curious to know that, but I'm under the impression that that's basically the only driver these days, and my arguments in this thread are mostly based on that. It seems to me CAcert certificates are free, not free-of-charge. The difference is between free beer and free speech, as they say. I see that other providers offer free-of-charge certificates, and I consider those marketing strategies ultimately aimed at improving their sales. From a practical POV, the incidents reported by THC[0] mention different CAs, so I'd rather remove them than CAcert. I believe all those roots were either removed from the Mozilla set, or rekeyed. A THC reported line says Comodo (InfoSecurity, 2011). Not once, but multiple times. Yet, on wheezy, I have: for f in /usr/share/ca-certificates/mozilla/Comodo*; \ do certtool -i --infile $f | grep 'Not Before'; done Not Before: Thu Jan 01 00:00:00 UTC 2004 Not Before: Thu Jan 01 00:00:00 UTC 2004 Not Before: Thu Jan 01 00:00:00 UTC 2004 That doesn't hurt me. IMHO, it is beyond Debian responsibilities to independently investigate on security incidents. When an upstream maintainer/provider identifies a security weakness and issues a patch, the Debian security team follows up, and I think that's enough. For what it's worth, I'd be happy to see Debian be _more_ conservative than Mozilla in what roots it includes, just not less. I beg to differ. In order to be conservative, Debian should devise objective criteria for auditing and assessing each CA. Carrying that activity out would consume an amount of resources, while the added value would be minimal: Server admins have to choose the CAs that better suit their needs anyway, regardless of Debian mumblings. So, including any known CA (unless it is a blatant scam, of course) seems to be a more effective approach. If anything, it should made clear[er] that there is no endorsement or assumption of responsibility in distributing ca-certificates: Just like any other package, it is done on a best-effort basis. I actually do think that's the right policy for Debian, but in the form that Debian should pass the trust questions off to an entity like Mozilla who is willing to make those endorsements (since the only other real way to make no endorsement clear is to make no roots trusted by default). Mozilla can make rather strict assumptions on how the certificates they accept are going to be used. Debian used to be more generic, and I don't think this post-disclosure period is the best moment to introduce policy restrictions. If it works, don't fix it; use it. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#718434: Bug #718434, please leave CAcert as is
I find CAcert pretty useful, and it is handy to have their certificate installed by default. From other contributions to this bug, it seems their auditing, policies, or disclaimer have some issues. From a practical POV, the incidents reported by THC[0] mention different CAs, so I'd rather remove them than CAcert. CAcert's disclaimer spells the same no-liability stuff that all Debian software bears. The only real reason that we would remove that certificate is because Mozilla doesn't do it. (BTW, CAcert is not any more on the pending list mentioned in message #40.) If anything, it should made clear[er] that there is no endorsement or assumption of responsibility in distributing ca-certificates: Just like any other package, it is done on a best-effort basis. CAcert is a well known CA. Debian has historically distributed its certificate, and should not stop unless there is a serious reason to do so. Please just set WONTFIX. [0] https://wiki.thc.org/ssl#head-96dca2abae666e78fe5a0955a6548517812bdc4e Thanks Ale -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#721825: closed by Andres Salomon dilin...@debian.org (Bug#721825: fixed in msr-tools 1.3-1)
On Fri 11/Oct/2013 05:21:10 +0200 Andres Salomon wrote: * Add a note to manpages about ensuring the correct kernel modules are loaded when running commands (closes: #721825). The original package (both versions) has a script MAKEDEV-cpuid-msr that creates 32 directories /dev/cpu/$n with a pair of device nodes each. (It is probably worth to use something like: n_cpus=$(egrep '^processor' /proc/cpuinfo | wc -l) n=0 while [ $n -lt $n_cpus ]; do instead. BTW, reading can be done using /dev/cpu/0 only, but writing seems to require nodes for each cpu.) IMHO, it is necessary to populate /dev/cpu like that on each boot, if msr-tools are to be used reliably. A note on the man page may help users, but also annoy them with the need to devise how to set up a proper initialization on each startup. Shouldn't the package install a script in /etc/init.d, with a start action similar to MAKEDEV-cpuid-msr, to accomplish that task directly? Ale -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#724690: sshfs: user's mountpoint is not accessible by root
On Thu 26/Sep/2013 19:04:19 +0200 Bastien ROUCARIES wrote: Not a bug a security feature SEE fuse man page. I understand those security concerns. What I'm asking is that just the mountpoint be accessible to root, not the remote files. That would be enough for root to learn that the directory contents reside on a different device. I see no other way to avoid breaking scripts such as check-setuid (package checksecurity). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#724687: checksecurity: buggy check-setuid default settings produce an empty list
Package: checksecurity Version: 2.0.14 Severity: normal The trailing | in the type (xxx...|) branch of CS_NFSAFS (see patch) apparently matches any type, so that find gets no paths to start with. Removing it, I am left with / and /dev rather than the empty list. -- System Information: Debian Release: 7.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.41ale20 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages checksecurity depends on: ii cron 3.0pl1-124 ii debconf [debconf-2.0] 1.5.49 ii perl 5.14.2-21 ii util-linux 2.20.1-5.3 Versions of packages checksecurity recommends: pn logcheck none pn tiger none ii tripwire 2.4.2.2-2 Versions of packages checksecurity suggests: pn apt-watch | cron-apt none ii lockfile-progs0.1.17 -- Configuration Files: /etc/checksecurity/check-setuid.conf changed [not included] -- debconf-show failed *** check-setuid.conf.patch --- check-setuid.conf.default 2009-05-26 01:39:51.0 +0200 +++ check-setuid.conf 2013-09-26 17:42:17.0 +0200 @@ -48,7 +48,7 @@ # Use temp variables to build up CHECKSECURITY_FILTER, to make it # a little more readable. # -CS_NFSAFS='(type (nfs|afs|coda|lustre|mfs|nnpfs|)|^(arla .* type xfs))' +CS_NFSAFS='(type (nfs|afs|coda|lustre|mfs|nnpfs)|^(arla .* type xfs))' # Uncomment the next line to get the old behaviour. #CS_NFSAFS='(nfs|afs) \(.*(nosuid|noexec).*nodev.*\)' # -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#724690: sshfs: user's mountpoint is not accessible by root
Package: sshfs Version: 2.4-1 Severity: normal Superuser has access to anything on a given machine, usually. However, after a user mounts sshfs, the mount point becomes unreadable by other shells: stat says Permission denied even to root. The ability to stat mountpoints would allow commands like `find / -xdev ...` to complete without errors when issued by root. -- System Information: Debian Release: 7.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.41ale20 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages sshfs depends on: ii fuse2.9.0-2+deb7u1 ii libc6 2.13-38 ii libfuse22.9.0-2+deb7u1 ii libglib2.0-02.33.12+really2.32.4-5 ii openssh-client 1:6.0p1-4 sshfs recommends no packages. sshfs suggests no packages. -- debconf-show failed -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#721946: [Pkg-xen-devel] Bug#721946: xen-hypervisor-4.1-amd64: dom0_mem cannot exceed some value
On Fri 06/Sep/2013 17:05:15 +0200 Ian Campbell wrote:
Both sets of log contain stuff like:
Sep 6 15:22:53 pcale kernel: [ 126.828195] ata4.00: exception Emask 0x0
SAct 0x0 SErr 0x8 action 0x6 frozen
Sep 6 15:22:53 pcale kernel: [ 126.828199] ata4: SError: { 10B8B }
Sep 6 15:22:53 pcale kernel: [ 126.828201] ata4.00: failed command: SMART
Sep 6 15:22:53 pcale kernel: [ 126.828205] ata4.00: cmd
b0/d8:00:00:4f:c2/00:00:00:00:00/00 tag 0
Sep 6 15:22:53 pcale kernel: [ 126.828206] res
40/00:ff:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Sep 6 15:22:53 pcale kernel: [ 126.828207] ata4.00: status: { DRDY }
Sep 6 15:22:53 pcale kernel: [ 126.828211] ata4: hard resetting link
Sep 6 15:22:54 pcale kernel: [ 127.320197] ata4: SATA link up 3.0 Gbps
(SStatus 123 SControl 300)
Sep 6 15:22:54 pcale kernel: [ 127.321358] ata4.00: configured for UDMA/133
Sep 6 15:22:54 pcale kernel: [ 127.336200] ata4: EH complete
Is your disk dying?
Died already. It was just an 80G Western Digital of 2005, but it
contained the Windows XP install that I wanted to run under Xen :-(
Does this happen if you boot the exact same Linux kernel without Xen
underneath?
Yes, but was never mounted. Only update-grub reported read errors.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#721825: msr-tools: missing /dev/cpu/0/msr (rdmsr: open: No such file or directory)
Package: msr-tools Version: 1.2-3 Severity: normal I found a workaround in http://archives.gentoo.org/gentoo-dev/msg_b90576f03c87fbcc790a96d3d0960f9a.xml Probably, it would suffice to do an mknod in /dev/cpu/0/msr but I copied that script verbatim (on a quadcore). It yields: cr--r--r-- 1 root root 203, 0 Sep 4 13:09 /dev/cpu/0/cpuid crw--T 1 root root 202, 0 Sep 4 13:09 /dev/cpu/0/msr cr--r--r-- 1 root root 203, 1 Sep 4 13:09 /dev/cpu/1/cpuid crw--T 1 root root 202, 1 Sep 4 13:09 /dev/cpu/1/msr cr--r--r-- 1 root root 203, 2 Sep 4 13:09 /dev/cpu/2/cpuid crw--T 1 root root 202, 2 Sep 4 13:09 /dev/cpu/2/msr cr--r--r-- 1 root root 203, 3 Sep 4 13:09 /dev/cpu/3/cpuid crw--T 1 root root 202, 3 Sep 4 13:09 /dev/cpu/3/msr Permissions might need some adjustment... -- System Information: Debian Release: 7.1 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages msr-tools depends on: ii libc6 2.13-38 msr-tools recommends no packages. msr-tools suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#709510: update
On Thu 13/Jun/2013 13:09:27 +0200 Robin Wood wrote: I've tried the upgrade with rpcbind and nfs-common stopped and it makes no difference. On a similar issue, I found no alternatives than switching off insserv. Did you find a better workaround? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#712224: bootchart2: bootchart-done INIT INFO block has no Default-Stop for levels 0 6
Package: bootchart2 Version: 0.14.4-3 Severity: normal The installation script puts start links correctly (S99) and also puts some kill links, K99 in rc0.d and rc6.d. The latter K links have no counterpart in the LSB info, and should be removed as they are no-opt. This would be a minor bug in a package whose core business is not the init process, IMHO. -- System Information: Debian Release: 7.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.41ale20 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages bootchart2 depends on: ii libc6 2.13-38 ii lsb-base 4.1+Debian8 Versions of packages bootchart2 recommends: ii pybootchartgui 0.14.4-3 bootchart2 suggests no packages. -- debconf-show failed -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#709510: update
On Fri 14/Jun/2013 09:14:44 +0200 Robin Wood wrote: Did you switch insserv off, then install then switch back on again or did you have to switch it off and leave it off? I've left it off for good, as the makefiles are not updated. (update-rc.d becomes somewhat unreliable too. I use a script to check what it does: fix-init, attached to bug #711853.) A switch to something different from Sys V init seems to be incumbent, but for boxes that only boot a few times a year it should not be a priority, and legacy mode worked well under squeeze... -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#711853: insserv: Design bug: rcN.d unstable and not maintainable
Package: insserv
Version: 1.14.0-5
Severity: normal
When update-rc.d calls insserv, the rcN.d directories are rebuilt
without taking into consideration any adjustment that might have
been set up locally. That seems to be done on the assumption that
the dependencies coded in the LSB blocks are universally accurate.
Now, LSBs are a great improvement over numeric priorities, but to
hamper local system tuning, which is not necessarily related to
LSBs, IMHO is an insult to the legendary versatility of SysV init.
On the other hand, when .legacy-bootordering exists, update-rc.d
does not use LSB blocks at all, and mindlessly links at priority
20. I understand that maintainers don't put default priority
orders, which are difficult to maintain: That is exactly the
reason why LSB INIT INFO blocks were devised. So, why not use
them?
A way to use that info and still respect existing priorities is
coded in the attached script. Thanks to it, I was able to get the
cleanest boot since I upgraded to wheezy. Unlike update-rc.d,
fix-init does not take a scrip name to operate on. It assumes all
links older than .legacy-bootordering are to be respected, and
writes any action it deems required to a shell script.
Please have a look at it.
Regards
Ale
-- System Information:
Debian Release: 7.0
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.2.41ale20 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages insserv depends on:
ii libc6 2.13-38
insserv recommends no packages.
Versions of packages insserv suggests:
pn bootchart2 none
-- debconf-show failed
#! /usr/bin/perl
# written by Alessandro Vesely in June 2013. This is free software.
=head1 NAME
fix-init - rebuild Finit?.d links according to LSB headers
=head1 SYNOPSIS
fix-init [-n|--dry-run [Ifile]]
[-r|--renum [Istep]]
[--root Iroot]
[-v|--verbose [2|3|4]]
fix-init -h|--help [1|2]
=head1 OPTIONS
=over
=item help
An optional value of I1 displays these options in addition to the synopsis.
Use I2 for a man-like page.
=item root
Default to F/. Use a different directory for testing.
=item dry-run
Bfix-init writes shell commands on a temporary file, then executes it.
This option prevents that execution. It is implied if Iroot is not
writable. If an output Ifile is specified, it will be used instead of a
temporary one, overwriting its previous content if any.
=item renum
Without this option, Bfix-init tries to respect the existing order of links.
Otherwise, it renumbers them. The default Istep is 6, resulting in names
like FS06xyz, FS12xyzzy, FS18foo, ... This option is implied if
dependecy based boot sequencing is in effect.
=item verbose
Minimal verbosity (I-v) is recommended, otherwise Bfix-init is almost
silent. At intermediate verbosity, unsatisfied required dependencies (I-v 2),
optional (should) and satisfied ones (I-v 3) are displayed, as well as some
skipped files and strange facts. Top verbosity (I-v 4) dumps some internal
structures, such as the initial and resulting order for each level.
=back
=cut
use strict;
use warnings;
use feature switch;
use File::Find;
use File::Temp 'tempfile';
use Getopt::Long;
use List::Util qw(max min);
use Data::Dumper;
use Pod::Usage;
use constant {BROKEN_LINK = 1,
PLAIN_FILE = 2, STRANGE_LINK = 3, NEW_LINK = 4};
my ($dryrun, $renum, $help, $root, $verbose);
Getopt::Long::Configure('no_ignore_case');
if (!GetOptions('verbose|v:i' = \$verbose,
'dry-run|n:s' = \$dryrun,
'renum|r:i' = \$renum,
'root=s' = \$root,
'help|h:i'= \$help))
{
pod2usage();
exit 1;
}
if (defined($help))
{
pod2usage(-verbose = $help);
}
if (defined($verbose))
{
$verbose = 1 unless ($verbose); # -v same as -v 1
}
else {$verbose = 0;}
$root = '/' unless defined($root);
$root .= '/' unless (substr($root, -1) eq '/');
my $initdir = $root . 'etc/init.d';
my $init_link = ../init.d/;
my $fix_flag = $initdir .'/.legacy-bootordering';
my $overridepath = /usr/share/insserv/overrides;
my $hostoverridepath = /etc/insserv/overrides;
$Data::Dumper::Terse = 1;
my @levels = map $_, ('S', 0.. 6);
my %rc_d = map {$_ = $root .etc/rc$_.d} @levels;
my $rc_d_length = length($rc_d{0}); # different from length($initdir)
do {
my @invalid = grep ! -d, values %rc_d;
push(@invalid, $initdir) unless -d $initdir;
pod2usage(-msg = 'Invalid dir: '. join(', ', @invalid)) if (@invalid);
};
my $timestamp = (stat($fix_flag))[9];
if (!defined($timestamp))
{
$timestamp = 0;
if (!defined($renum))
{
$renum = 0;
print Dependecy based boot sequencing detected, --renum implied\n
if ($verbose);
}
}
my $defaultstep = 6;
$renum = $defaultstep if (defined($renum) $renum == 0);
# cannot do, because order becomes negative or larger than 99
my $cannot
Bug#709772: nullidentd: Missing xinetd.d configuration file
Package: nullidentd Version: 1.0-5 Severity: wishlist Setting up nullidentd is less straightforward than it could be because a configuration file is missing. -- System Information: Debian Release: 7.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.41ale20 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages nullidentd depends on: ii libc6 2.13-38 ii netbase5.0 ii update-inetd 4.43 ii xinetd [inet-superserver] 1:2.3.14-7.1 nullidentd recommends no packages. nullidentd suggests no packages. -- debconf-show failed -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#709772: Acknowledgement (nullidentd: Missing xinetd.d configuration file)
Forgot the attachment, to go in /etc/xinetd.d/nullidentd
# default: off
# description: Minimal identd server implementing the auth protocol (RFC 1413).
# need to set a user
service auth
{
disable = yes
flags = NODELAY
socket_type = stream
protocol= tcp
wait= no
server = /usr/sbin/nullidentd
server_args = nobody
user= nobody
}
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#708369: closed by Julien Cristau jcris...@debian.org (Re: Bug#708369: release-notes: Please mention ipset)
It's not clear to me what you think is release-notes material about this, sorry. I'd have expected some subsection of Chapter 5 to say something like, say: 5.16 Ipset and Iptables On squeeze systems that have xtables-addons the upgrade process may stop when attempting to install the corresponding wheezy package. Upgrade can be recovered by removing the package. Wheezy stock kernel supports ipset 6 natively, so do custom kernels based on linux-source, provided the relevant IP_SET configure options are enabled. Hence, no addons are necessary for that. Please not ipset 6 syntax changes with respect to version 4: Now ipset provides for word-style rather than option-style commands; e.g. /ipset create $name $type/ rather than /ipset -N $name $type/. Iptables command line parsing is also more strict: Using intrapositioned negation (`--option ! this`) is deprecated in favor of extrapositioned (`! --option this`). That would have saved some downtime when upgrading. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#708696: cpqarrayd: Misleading package summary: kernel 3.2 seems to be supported
Package: cpqarrayd Version: 2.3-1.3 Severity: minor The package summary says this tool works with Linux kernels 2.x. However, the last changelog entry talks about 3.x kernels. Since it's on wheezy, that's what I'd have expected. When it starts, it just says May 17 20:53:40 north cpqarrayd: Logging Enabled... Will it LOG_CRIT in case of something noticeable? Please note that HP support is less than that, and various packages of theirs, e.g. hpcpqacuxe, don't seem to be ready for wheezy. P.S. Adding a SEE ALSO entry to the man page would be great! -- System Information: Debian Release: 7.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.41ale20 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages cpqarrayd depends on: ii libc6 2.13-38 cpqarrayd recommends no packages. cpqarrayd suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#708369: release-notes: Please mention ipset
Package: release-notes Severity: normal Ipset is probably used by several servers, since there are articles explaining how to compile it on Debian/Ubuntu and how to use it, for example with Spamhaus DROP list. Xtables-addons 1.42 won't compile for existing 2.6.32 kernels (undefined struct flowi6 in xt_ECHO.c) and one needs to remove xtables-addons-dkms. Wheezy's ipset won't work with the old kernel. Then one needs to find out if any addons are needed for running ipset with the 3.2 kernel. Apparently not, but I haven't done it yet. -- System Information: Debian Release: 7.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 2.6.32ale18 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#616414: tripwire: Modifies current directory, possibly triggering a violation on next check
Package: tripwire Version: 2.4.2-9 Severity: minor Tags: upstream After changing a monitored part of the system, one runs tripwire -m c -I Even accepting all changes, the next time a check is run it fails again if the command was issued from a monitored directory. It is not uncommon to fall into such trap, as the user might had cd there to operate the changes. The correct sequence is pushd /tmp tripwire -m c -I (assuming /tmp is not monitored.) See also bug #353062 Tripwire creates a temporary file in the current directory in order to run the check. It should create it into /tmp. -- System Information: Debian Release: 6.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- Configuration Files: /etc/cron.daily/tripwire changed [not included] /etc/tripwire/twcfg.txt changed [not included] /etc/tripwire/twpol.txt changed [not included] -- debconf information: * tripwire/installed: tripwire/site-passphrase-incorrect: false * tripwire/use-localkey: true tripwire/change-in-default-policy: tripwire/upgrade: true * tripwire/rebuild-policy: true * tripwire/rebuild-config: true tripwire/email-report: tripwire/broken-passphrase: * tripwire/use-sitekey: true tripwire/local-passphrase-incorrect: false -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#412767: seen it again
On 20:59, Joey Hess wrote: Always stops at the same size log file. I believe that I have reinstalled this server at least once since I originally saw the bug in 2006. There are no disk quota settings, and ulimit does not seem relevant: j...@wren:~ulimit -a -t: cpu time (seconds) unlimited -f: file size (blocks) unlimited Is that a different partition than the one where the message is being saved? I've read somewhere that Postfix has a config parameter mailbox_size_limit and it's default is 5120 bytes... Not using Postfix, I tried to reproduce that behavior, to no avail. See http://www.mail-archive.com/courier-us...@lists.sourceforge.net/msg35306.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#596849: logrotate: Rotated file name unknown to postrotate script
Package: logrotate Version: 3.7.1-5 Severity: wishlist The argument passed to the script is the name that the log file was renamed from, rather than the one it has been renamed to. This requires that scripts are manually kept in sync with the extension, e.g. changing to dateext will break scripts looking for some.log.0. Since the parameter is poorly documented (see bug #423270), I would suggest to use a variable instead, e.g. something like FILE *fp = fdopen(fd, w); fprintf(fp, #! /bin/sh\n\nROTATEDLOG=%s\n%s, finalName, script); where finalName is passed as a third argument to runScript. -- Package-specific info: Contents of /etc/logrotate.d total 100 -rw-r--r-- 1 root root 368 2009-09-22 12:05 apache2 -rw-r--r-- 1 root root 381 2009-09-22 12:03 apache2~ -rw-r--r-- 1 root root 84 2009-02-07 22:18 apt -rw-r--r-- 1 root root 79 2007-03-14 15:46 aptitude -rw-r--r-- 1 root root 330 2008-03-07 22:36 atop -rw-r--r-- 1 root root 215 2008-07-28 22:50 checksecurity -rw-r--r-- 1 root root 248 2009-01-13 17:09 cups -rw-r--r-- 1 root root 111 2007-01-02 11:22 dpkg -rw-r--r-- 1 root root 273 2007-01-20 11:22 exim4-base -rw-r--r-- 1 root root 94 2006-10-12 10:46 hibernate -rw-r--r-- 1 root root 77 2008-10-11 02:14 hp-health -rw-r--r-- 1 root root 77 2008-10-01 00:46 hp-snmp-agents -rw-r--r-- 1 root root 169 2007-02-11 17:06 mcelog -rw-r--r-- 1 root root 837 2009-02-03 17:15 mysql-server -rw-r--r-- 1 root root 153 2007-01-29 16:30 postgresql-common -rw-r--r-- 1 root root 1061 2008-03-07 22:36 psaccs_atop -rw-r--r-- 1 root root 512 2008-03-07 22:36 psaccu_atop -rw-r--r-- 1 root root 88 2008-07-23 03:50 razor -rw-r--r-- 1 root root 68 2007-02-16 10:22 scrollkeeper -rw-r--r-- 1 root root 108 2008-07-27 05:34 shorewall -rw-r--r-- 1 root root 172 2010-02-01 12:49 thermal_sensor -rw-r--r-- 1 root root 167 2009-09-19 18:21 thermal_sensor~ -rw-r--r-- 1 root root 135 2007-03-18 15:55 ulogd -rw-r--r-- 1 root root 114 2006-10-02 11:03 unattended-upgrades -rw-r--r-- 1 root root 80 2006-10-05 02:27 wpa_action -- System Information: Debian Release: 5.0.6 APT prefers stable APT policy: (800, 'stable'), (200, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26ale10 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages logrotate depends on: ii base-passwd 3.5.20 Debian base system master password ii cron3.0pl1-105 management of regular background p ii libc6 2.7-18lenny4 GNU C Library: Shared libraries ii libpopt01.14-4 lib for parsing cmdline parameters ii libselinux1 2.0.65-5 SELinux shared libraries Versions of packages logrotate recommends: ii bsd-mailx [mailx] 8.1.2-0.20071201cvs-3 A simple mail user agent ii mailx 1:20071201-3 Transitional package for mailx ren logrotate suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#419496: on Sunday mornings weekly and daily run together
Package: sysklogd Version: 1.5-5 Followup-For: Bug #419496 run-parts does /etc/cron.weekly on Sunday at 4:47, right after cron.daily. Since the latter contains some lengthy stuff (mandb), they may end up running in reverse order, or simultaneously. this is particularly annoying when log files are post-processed. This requires some customization (See Bug #104278) and may result in the same file being rotated twice the same day, and the post-processing to miss either the large or the short part, randomly. This bug should be merged with Bug #104278. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#568409: apache2.2-common: HostnameLookup Off apparently doesn't work (allow from localhost?)
Package: apache2.2-common Version: 2.2.9-10+lenny6 Severity: minor Although HostnameLookup is set to Off (the default) host names are sometimes logged instead of IP addresses. This can be solved by using %a rather than %h in the LogFormat. However, why are IP resolved? I suspect the directive found in /etc/apache2/mods-enabled/mod_info.c which says Location /server-info SetHandler server-info Order deny,allow Deny from all Allow from localhost ip6-localhost #Allow from .example.com /Location Does that require mod_authz_host to lookup names? If that's the case, it should probably be commented out. It might also be a good idea to replace the one already commented out with, say, #Allow from 192.0.2.0/24 -- Package-specific info: List of enabled modules from 'apache2 -M': actions alias asis auth_basic auth_digest authn_file authz_default authz_groupfile authz_host authz_svn authz_user autoindex cgi dav dav_svn dir env headers include info macro mime negotiation perl php5 proxy_http proxy python rewrite setenvif speling ssl status -- System Information: Debian Release: 5.0.4 APT prefers stable APT policy: (800, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26ale9 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages apache2.2-common depends on: ii apache2-utils 2.2.9-10+lenny6 utility programs for webservers ii libapr1 1.2.12-5+lenny1 The Apache Portable Runtime Librar ii libaprutil1 1.2.12+dfsg-8+lenny4 The Apache Portable Runtime Utilit ii libc6 2.7-18lenny2 GNU C Library: Shared libraries ii libmagic1 4.26-1 File type determination library us ii libssl0.9.8 0.9.8g-15+lenny6 SSL shared libraries ii lsb-base3.2-20 Linux Standard Base 3.2 init scrip ii mime-support3.44-1 MIME files 'mime.types' 'mailcap ii net-tools 1.60-22 The NET-3 networking toolkit ii perl5.10.0-19lenny2 Larry Wall's Practical Extraction ii procps 1:3.2.7-11 /proc file system utilities ii zlib1g 1:1.2.3.3.dfsg-12compression library - runtime Versions of packages apache2.2-common recommends: ii ssl-cert 1.0.23 simple debconf wrapper for OpenSSL Versions of packages apache2.2-common suggests: ii apache2-doc 2.2.9-10+lenny6 Apache HTTP Server documentation pn apache2-suexec | apache2 none (no description available) ii epiphany-gecko [www-brow 2.22.3-9Intuitive GNOME web browser - Geck ii iceweasel [www-browser] 3.0.6-3 lightweight web browser based on M ii lynx-cur [www-browser] 2.8.7dev9-2.1 Text-mode WWW Browser with NLS sup ii w3m [www-browser]0.5.2-2+b1 WWW browsable pager with excellent Versions of packages apache2.2-common is related to: pn apache2-mpm-eventnone (no description available) pn apache2-mpm-itk none (no description available) ii apache2-mpm-prefork 2.2.9-10+lenny6 Apache HTTP Server - traditional n pn apache2-mpm-worker none (no description available) -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#566018: libpopt-dev: poptPrintHelp displays syntax with no arguments
Package: libpopt-dev
Version: 1.14-4
Severity: wishlist
The otherHelp field cannot be set, therefore poptPrintHelp always printf
Usage: progname [OPTIONS...]
and never prints an argument list. otherHelp is defined in poptint.h, but
an utility is missing for setting it. Something like the following would
suffice:
void poptSetOtherHelp(poptContext con, const char *alt)
{
con-otherHelp = strdup(alt);
}
-- System Information:
Debian Release: 5.0.3
APT prefers stable
APT policy: (800, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.26ale9 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages libpopt-dev depends on:
ii libc6-dev [libc-dev] 2.7-18 GNU C Library: Development Librari
ii libpopt0 1.14-4 lib for parsing cmdline parameters
libpopt-dev recommends no packages.
libpopt-dev suggests no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#169577: bind9: Ownership of /etc/bind/rndc.key is the problem.
On Fri, 09 Jan 2009 00:00:15 +1100 Bruce Tulloch wrote
This bug still exists in lenny as of today (bind9/1:9.5.0.dfsg.P2-4)
despite it being reported as fixed in bind9/1:9.5.0.dfsg.P2-1.
Also exists today with bind9/lenny uptodate 1:9.5.1.dfsg.P3-1+lenny1
(presumably after the DNS cache poisoning update CVE-2009-4022)
Clearly the maintainer scripts in bind9/1:9.5.0.dfsg.P2-4 are *still*
setting the ownership permissions for /etc/bind/rndc.key incorrectly.
I also think so :-(
What is not clear to me is why ownership of bind.bind does not work.
I'd guess it's because of no capabilities settings. It does:
25342 capget(0x20080522, 0, NULL) = -1 EFAULT (Bad address)
25342 capget(0x20080522, 0, NULL) = -1 EFAULT (Bad address)
25342 capget(0x20080522, 0,
{CAP_DAC_READ_SEARCH|CAP_SETGID|CAP_SETUID|CAP_NET_BIND_SERVICE|CAP_SYS_CHROOT|CAP_SYS_RESOURCE,
CAP_DAC_READ_SEARCH|CAP_SETGID|CAP_SETUID|CAP_NET_BIND_SERVICE|CAP_SYS_CHROOT|CAP_SYS_RESOURCE,
0}) = 0
25342 getuid() = 0
25342 capset(0x20080522, 0, {CAP_NET_BIND_SERVICE|CAP_SYS_RESOURCE,
CAP_NET_BIND_SERVICE|CAP_SYS_RESOURCE, 0}) = 0
and then, with /etc/bind/rndc.key owned by bind:bind, rw-r-,
and no setuid, it runs the following sequence (all but the last
line are for context)
25344 open(/etc/bind/named.conf, O_RDONLY) = 9
25344 fstat(9, {st_mode=S_IFREG|0640, st_size=1091, ...}) = 0
25344 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x7f48e9616000
25344 read(9, // This is the primary configurat..., 4096) = 1091
25344 open(/etc/bind/named.conf.options, O_RDONLY) = 10
25344 fstat(10, {st_mode=S_IFREG|0640, st_size=2786, ...}) = 0
25344 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x7f48e9615000
25344 read(10, acl trusted_ns {\n\t194.243.254.162..., 4096) = 2786
25344 open(/etc/bind/rndc.key, O_RDONLY) = -1 EACCES (Permission denied)
And thereafter fails.
The usual workaround, chown root /etc/bind/rndc.key, still works...
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#393093: Does not depend on Courier: xrealloc: ../bash/subst.c:512: cannot reallocate 512 bytes (0 bytes allocated)
Hi all, Today I recompiled courier-authlib and this triggered the bug: I got /usr/local/sbin/imapd: xrealloc: ../bash/subst.c:512: cannot reallocate 512 bytes (0 bytes allocated) same for imapd-ssl; the rest worked OK. Note that /usr/local/sbin/imapd is a softlink to a shell script. If I invoke that script directly, I get the same result. However, if I _source_ it, it works. Later on, I've made a copy of the script for testing. It turns out that execution stops when bash expands the command line that invokes /usr/bin/env. Replacing /bin/sh with /bin/dash on the shebang works. Thus, it is rather a bash extra memory consumption. You may play with the attached script to check when bash consumes more memory than allowed by its own ulimit. On the etch64 system I use, it stops either in subst.c or in make_cmd.c Ciao Ale #! /bin/bash # reproduce bug 393093 set -a # 12345678901234567890123456789012345678901234567890 VAR1=this is variable is 50 bytes quote to quote length VAR2=$VAR1$VAR1$VAR1$VAR1$VAR1$VAR1$VAR1$VAR1$VAR1$VAR1 VAR3=$VAR2$VAR2$VAR2$VAR2$VAR2$VAR2$VAR2$VAR2$VAR2$VAR2 VAR4=$VAR3$VAR3$VAR3$VAR3$VAR3$VAR3$VAR3$VAR3$VAR3$VAR3 VAR5=$VAR4$VAR4$VAR4$VAR4$VAR4$VAR4$VAR4$VAR4$VAR4$VAR4 ulimit -v 65536 echo VAR3 is 5000 /bin/sh -c echo $VAR3 /dev/null echo VAR4 is 5 /bin/sh -c echo $VAR4 /dev/null echo not reached in bash echo VAR5 is 50 /bin/sh -c echo $VAR5 /dev/null echo dash says: ./bstest: 19: /bin/sh: Argument list too long
Bug#382410: /etc/rc0.d out of order: blame update-rc.d docs?
Package: sysv-rc Version: 2.86.ds1-1 I had to read the init.d/rc script to make sure that Knn* are _not_ called in reversed sort order. In facts, the docs don't say it. Giving a single NN argument should be deprecated. More misunderstandings below... Related bugs: 268713, 288098 The following also applies to version 2.86.ds1-2, AFAICS. Suggestions: 1) advertise update-rc.d Add a paragraph in /etc/init.d/README saying something like Use the update-rc.d command to create symbolic links in the /etc/rc?.d as appropriate. See that man page for more details. 2) encourage setting the stop number correctly In the man page I would replace this can be overridden by supplying one or two NN arguments with this should be overridden if there are dependencies. For example if daemon B depends on A, then A must be started before B and B must be killed before A. You accomplish this by supplying two NN arguments. In general, core daemons should start early and be killed late, whilst applications can start late and be killed early. See EXAMPLES below. The first NN argument supplies the start sequence number and the second NN argument supplies the kill sequence number. Kill scripts are called first, passing a stop argument. Then start scripts are called passing a start argument. In either case, calls happen in ascending sequence number order. Supplying a single NN argument will use the same number for both start and kill links. This is supported for backward compatibility but is discouraged, as it may lead to inconsistent settings. As a rule of thumb, if you increase the start sequence number you should also decrease the stop sequence number, and vice-versa. And then put more examples, e.g. Insert links at default runlevels when B requires A update-rc.d script_for_A defaults 80 20 update-rc.d script_for_B defaults 90 10 Insert a link to a service that (presumably) will not be needed by any other daemon update-rc.d top_level_app defaults 98 02 Insert links for a script that requires services that start/stop at sequence number 20 update-rc.d script_depends_on_svc20 defaults 21 19 Giving a single argument should be deprecated: Let two independent daemons A and B configured in that way, say A starts/stops at sequence number 20 and B at sequence number 40. Then consider a service C that depends on A and provides services necessary for B. (E.g. B can be configured to do authentication using C.) Then C may start at 30, after A but before B. There is no valid sequence number to stop C. In facts, the stopping order should be kill-B, kill-C, kill-A, which is not possible because A is killed before B. Of course, such deadlocks may happen also letting the default 20, but then at least it is clear that the problem hasn't been put. I see no circumstance in which supplying `40' to the configuration of B yields a benefit. What am I missing? More misunderstandings: - I have rc0.d/K21fam and rc3.d/S21fam. They used to be both at 20 (see bug 280617.) What issue has been solved with that move? - If anyone is registered there, please edit http://wiki.linuxquestions.org/wiki/Update-rc.d it says so: Yes, you can use the arguments start and stop, followed by NN (where NN are the desired runlevels) to specify which runlevels the script will start and stop in. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
