Re: 2.6.18-rc1-mm2: process `showconsole' used the removed sysctl system call

["Michal Piotrowski" <michal.k.k.piotrowski@gmail.com>]

On 16/07/06, Eric W. Biederman <ebiederm@xmission.com> wrote:
> Michal Piotrowski <michal.k.k.piotrowski@gmail.com> writes:
>
> > Hi Andrew,
> >
> > Andrew Morton wrote:
> >> On Sat, 15 Jul 2006 16:40:36 +0200
> >> Tilman Schmidt <tilman@imap.cc> wrote:
> >>
> >>> After installing a 2.6.18-rc1-mm2 kernel without sysctl syscall support
> >>> on a standard SuSE 10.0 system, I find the following in my dmesg:
> >>>
> >>>> [ 36.955720] warning: process `showconsole' used the removed sysctl system
> > call
> >>>> [ 39.656410] warning: process `showconsole' used the removed sysctl system
> > call
> >>>> [ 43.304401] warning: process `showconsole' used the removed sysctl system
> > call
> >>>> [   45.717220] warning: process `ls' used the removed sysctl system call
> >>>> [   45.789845] warning: process `touch' used the removed sysctl system call
> >>> which at face value seems to contradict the statement in the help text
> >>> for the CONFIG_SYSCTL_SYSCALL option that "Nothing has been using the
> >>> binary sysctl interface for some time time now". (sic)
> >>>
> >>> Meanwhile, the second part of that sentence that "nothing should break"
> >>> by disabling it seems to hold true anyway. The system runs fine, and
> >>> activating CONFIG_SYSCTL_SYSCALL in the kernel doesn't seem to have any
> >>> effect apart from changing the word "removed" to "obsolete" in the above
> >>> messages.
> >>
> >> Thanks.
> >>
> >
> > date and salsa also use sysctl.
> >
> > warning: process `date' used the removed sysctl system call
> > warning: process `salsa' used the removed sysctl system call
> >
> >> Eric, that tends to make the whole idea inviable, doesn't it?
> >
> > How about _very_ long term to remove sysctl (i.e. January 2010)?
>
> That may be reasonable.  However please confirm that everything
> that you have complaints from is using libpthreads.

ldd /bin/date
        linux-gate.so.1 =>  (0xb7f22000)
        librt.so.1 => /lib/librt.so.1 (0x4aab9000)
        libc.so.6 => /lib/libc.so.6 (0x49ca3000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x49f38000)
        /lib/ld-linux.so.2 (0x49c86000)

ldd /bin/ls
        linux-gate.so.1 =>  (0xb7f23000)
        librt.so.1 => /lib/librt.so.1 (0x4aab9000)
        libselinux.so.1 => /lib/libselinux.so.1 (0x45a71000)
        libc.so.6 => /lib/libc.so.6 (0x49ca3000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x49f38000)
        /lib/ld-linux.so.2 (0x49c86000)
        libdl.so.2 => /lib/libdl.so.2 (0x49dd8000)
        libsepol.so.1 => /lib/libsepol.so.1 (0x41ad5000)

ldd /sbin/salsa
        linux-gate.so.1 =>  (0xb7fd7000)
        libasound.so.2 => /lib/libasound.so.2 (0x4100f000)
        libc.so.6 => /lib/libc.so.6 (0x49ca3000)
        libm.so.6 => /lib/libm.so.6 (0x49dde000)
        libdl.so.2 => /lib/libdl.so.2 (0x49dd8000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x49f38000)
        /lib/ld-linux.so.2 (0x49c86000)

ldd /bin/touch
        linux-gate.so.1 =>  (0xb7fa2000)
        librt.so.1 => /lib/librt.so.1 (0x4aab9000)
        libc.so.6 => /lib/libc.so.6 (0x49ca3000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x49f38000)
        /lib/ld-linux.so.2 (0x49c86000)

I can confirm this, but I don't have a "showconsole".

>
> As there is one use of libpthreads that is using sysctl
> in a very non-serious way.
>
> With libptrheads modified to use uname and not sysctl I am not seeing that
> message.  I thought I had broken my test setup by forgetting to compile
> glibc with --with-tls but I managed but I managed to get things working
> again using LD_ASSUME_KERNEL=2.4.1
>
> Still not the best data point but a very interesting one.
>
> Eric
>

Regards,
Michal

-- 
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/wiki/)