package procps 1:3.2.8-11ubuntu6.1 failed to install/upgrade: il sottoprocesso vecchio script di post-installation ha restituito lo stato di errore 1

Bug #1241562 reported by luciopineda on 2013-10-18
18
This bug affects 3 people
Affects Status Importance Assigned to Milestone
procps (Ubuntu)
Undecided
Unassigned

Bug Description

After apt-get update and than apt-get upgrade I've the following report from shell
Continuare [S/n]? s
Configurazione di procps (1:3.2.8-11ubuntu6.1)...
start: Job failed to start
invoke-rc.d: initscript procps, action "start" failed.
dpkg: errore nell'elaborare procps (--configure):
 il sottoprocesso vecchio script di post-installation ha restituito lo stato di errore 1
Si sono verificati degli errori nell'elaborazione:
 procps
E: Sub-process /usr/bin/dpkg returned an error code (1)

ProblemType: Package
DistroRelease: Ubuntu 12.04
Package: procps 1:3.2.8-11ubuntu6.1
ProcVersionSignature: Ubuntu 3.2.0-54.82-generic-pae 3.2.50
Uname: Linux 3.2.0-54-generic-pae i686
ApportVersion: 2.0.1-0ubuntu17.5
Architecture: i386
Date: Fri Oct 18 09:09:32 2013
DuplicateSignature: package:procps:1:3.2.8-11ubuntu6.1:il sottoprocesso vecchio script di post-installation ha restituito lo stato di errore 1
ErrorMessage: il sottoprocesso vecchio script di post-installation ha restituito lo stato di errore 1
InstallationMedia: Ubuntu 12.04 LTS "Precise Pangolin" - Release i386 (20120423)
MarkForUpload: True
SourcePackage: procps
Title: package procps 1:3.2.8-11ubuntu6.1 failed to install/upgrade: il sottoprocesso vecchio script di post-installation ha restituito lo stato di errore 1
UpgradeStatus: No upgrade log present (probably fresh install)

luciopineda (lucio-pineda) wrote :
tags: removed: need-duplicate-check
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in procps (Ubuntu):
status: New → Confirmed
Ouilsen (ouilsen) wrote :

The problem is that you probably use a hoster that relies on a different kernel than ubuntu (custom 2.6.x build in my case). So you have to remove a kernel option in /etc/sysctl.d/10-kernel-hardening.conf, since your kernel does not support it. However, this does not seem to be recommended. So I am getting in touch with my hoster.

Il 23/10/2013 10:33, Ouilsen ha scritto:
> Here is a solution.
>
> http://ubuntuforums.org/showthread.php?t=1505356
It doesn't help me
>
> The problem is that you probably use a hoster that relies on a different
> kernel than ubuntu (custom 2.6.x build in my case). So you have to
> remove a kernel option in the ptrace upstart script in
> /etc/sysctl.d/10-ptrace.conf, since your kernel does not support it.
> However, this does not seem to be recommended. So I am getting in touch
> with my hoster.
This is my

/etc/sysctl.d/10-ptrace.conf

lucio@lucio-N61PA-M2S:/etc/sysctl.d$ cat 10-ptrace.conf
# The PTRACE system is used for debugging. With it, a single user process
# can attach to any other dumpable process owned by the same user. In the
# case of malicious software, it is possible to use PTRACE to access
# credentials that exist in memory (re-using existing SSH connections,
# extracting GPG agent information, etc).
#
# A PTRACE scope of "0" is the more permissive mode. A scope of "1" limits
# PTRACE only to direct child processes (e.g. "gdb name-of-program" and
# "strace -f name-of-program" work, but gdb's "attach" and "strace -fp $PID"
# do not). The PTRACE scope is ignored when a user has CAP_SYS_PTRACE, so
# "sudo strace -fp $PID" will work as before. For more details see:
# https://wiki.ubuntu.com/SecurityTeam/Roadmap/KernelHardening#ptrace
#
# For applications launching crash handlers that need PTRACE, exceptions can
# be registered by the debugee by declaring in the segfault handler
# specifically which process will be using PTRACE on the debugee:
# prctl(PR_SET_PTRACER, debugger_pid, 0, 0, 0);
#
# In general, PTRACE is not needed for the average running Ubuntu system.
# To that end, the default is to set the PTRACE scope to "1". This value
# may not be appropriate for developers or servers with only admin accounts.
kernel.yama.ptrace_scope = 1
lucio@lucio-N61PA-M2S:/etc/sysctl.d$

> But I don't know what to do
Many Thanks

luciopineda (lucio-pineda) wrote :

Il 23/10/2013 10:37, Ouilsen ha scritto:
> The problem is that you probably use a hoster that relies on a different
> kernel than ubuntu (custom 2.6.x build in my case). So you have to
> remove a kernel option in /etc/sysctl.d/10-kernel-hardening.conf, since
> your kernel does not support it. However, this does not seem to be
> recommended. So I am getting in touch with my hoster.
>
searching a solution I've found another tip: to change
/etc/sysctl.d/10-ptrace.conf
kernel.yama.ptrace_scope = 1 in kernel.yama.ptrace_scope = 0
Do you know if there is any problem about security in this way ?
What do you mean by

The problem is that you probably use a hoster that relies on a different
kernel than ubuntu
And
So I am getting in touch with my hoster.

Tanks

Hi,

I solved the same problem in this way:

sudo rm /var/lib/dpkg/info/procps.postinst
sudo apt-get --reinstall install procps
sudo apt-get -f install
sudo dpkg --configure -a
sudo apt-get update
sudo apt-get upgrade

I hope it works for you too.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers