--- Begin Message ---
- To: Debian Bug Tracking System <submit@bugs.debian.org>
- Subject: During upgrade niceness of server-process is inherited from mother-process.
- From: Juhapekka Tolvanen <juhtolv@iki.fi>
- Date: Sun, 9 May 2010 23:21:41 +0300
- Message-id: <20100509202141.GA14350@juhtolv.dyndns.org>
- Reply-to: Juhapekka Tolvanen <juhtolv@iki.fi>
Package: openssh-server
Version: 1:5.5p1-3
Severity: normal
When I update and upgarade my Debian-packages with apt-get, I run it
in nice value 19. Unfortunately it has this side effect:
# ps xfo pid,tty,nice,stat,time,command
PID TT NI STAT TIME COMMAND
(Clip)
13721 ? 19 SNs 00:00:00 /usr/sbin/sshd
Maybe this bugreport really belongs to that system-utility, that actually
stops and restarts servers during upgrade.
-- System Information:
Debian Release: squeeze/sid
APT prefers stable
APT policy: (990, 'stable'), (500, 'testing-proposed-updates'), (500, 'proposed-updates'), (101, 'testing'), (99, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.32-trunk-686 (SMP w/1 CPU core)
Locale: LANG=fi_FI.utf8, LC_CTYPE=fi_FI.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages openssh-server depends on:
ii adduser 3.112 add and remove users and groups
ii debconf [debconf-2.0] 1.5.32 Debian configuration management sy
ii dpkg 1.15.5.6 Debian package management system
ii libc6 2.10.2-6 Embedded GNU C Library: Shared lib
ii libcomerr2 1.41.11-1 common error description library
ii libgssapi-krb5-2 1.8.1+dfsg-2 MIT Kerberos runtime libraries - k
ii libkrb5-3 1.8.1+dfsg-2 MIT Kerberos runtime libraries
ii libpam-modules 1.1.1-3 Pluggable Authentication Modules f
ii libpam-runtime 1.1.1-3 Runtime support for the PAM librar
ii libpam0g 1.1.1-3 Pluggable Authentication Modules l
ii libselinux1 2.0.94-1 SELinux runtime shared libraries
ii libssl0.9.8 0.9.8n-1 SSL shared libraries
ii libwrap0 7.6.q-18 Wietse Venema's TCP wrappers libra
ii lsb-base 3.2-23.1 Linux Standard Base 3.2 init scrip
ii openssh-blacklist 0.4.1 list of default blacklisted OpenSS
ii openssh-client 1:5.5p1-3 secure shell (SSH) client, for sec
ii procps 1:3.2.8-9 /proc file system utilities
ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime
Versions of packages openssh-server recommends:
ii openssh-blacklist-extra 0.4.1 list of non-default blacklisted Op
ii xauth 1:1.0.3-2 X authentication utility
Versions of packages openssh-server suggests:
ii gtk-led-askpass [ssh-askpass 0.10-2 GTK+ password dialog suitable for
ii molly-guard 0.4.4-2 protects machines from accidental
pn rssh <none> (no description available)
ii ssh-askpass 1:1.2.4.1-9 under X, asks user for a passphras
pn ufw <none> (no description available)
-- debconf information:
ssh/vulnerable_host_keys:
ssh/new_config: true
* ssh/use_old_init_script: true
ssh/disable_cr_auth: false
ssh/encrypted_host_key_but_no_keygen:
--
Juhapekka "naula" Tolvanen * http colon slash slash iki dot fi slash juhtolv
"Quidquid Latine dictum sit altum videtur."
--- End Message ---
--- Begin Message ---
- To: Juhapekka Tolvanen <juhtolv@iki.fi>, 580919-close@bugs.debian.org
- Subject: Re: Bug#580919: During upgrade niceness of server-process is inherited from mother-process.
- From: Colin Watson <cjwatson@debian.org>
- Date: Sun, 30 Nov 2025 22:25:53 +0000
- Message-id: <aSzEcT5ocTcdKum3@riva.ucam.org>
- In-reply-to: <20100509204231.GA12396@riva.ucam.org>
- References: <20100509202141.GA14350@juhtolv.dyndns.org> <20100509204231.GA12396@riva.ucam.org>
On Sun, May 09, 2010 at 09:42:32PM +0100, Colin Watson wrote:
On Sun, May 09, 2010 at 11:21:41PM +0300, Juhapekka Tolvanen wrote:
When I update and upgarade my Debian-packages with apt-get, I run it
in nice value 19. Unfortunately it has this side effect:
# ps xfo pid,tty,nice,stat,time,command
PID TT NI STAT TIME COMMAND
(Clip)
13721 ? 19 SNs 00:00:00 /usr/sbin/sshd
Maybe this bugreport really belongs to that system-utility, that actually
stops and restarts servers during upgrade.
I'm not sure what we should do about this. invoke-rc.d doesn't seem to
sanitise the environment at all, so I imagine nearly all packages have
exactly the same bug.
Moving to Upstart would fix this, since with Upstart we can instruct the
init daemon to start the job rather than having to run the init script
as a descendant of the postinst. I wonder if it's really worth going
around trying to sanitise the environment all over the place when we
should be able to switch to Upstart in the not too distant future
anyway?
This shouldn't be a problem any more now that the restart instruction
goes via systemd on most systems.
Thanks,
--
Colin Watson (he/him) [cjwatson@debian.org]
--- End Message ---