Hello,
tried today to mkfs.ext2 a partition of my disk and detected there is
a little difference between 'login: root' and 'su -'.
First I tried it this way:
Welcome to SuSE Linux 7.0 (i386) - Kernel 2.4.14 (tty1).
zodiak login: seiderer
Password:
seiderer@zodiak:~ > su -
Password:
zodiak:~ #
zodiak:~ # mkfs.ext2 /dev/hdc4
mke2fs 1.18, 11-Nov-1999 for EXT2 FS 0.5b, 95/08/09
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
716672 inodes, 1432116 blocks
71605 blocks (5.00%) reserved for the super user
First data block=0
44 block groups
32768 blocks per group, 32768 fragments per group
16288 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736
Writing inode tables: 16/44File size limit exceeded
strace showed that write returned wit EFBIG and the process ended with SIGXFSZ:
write(1, "\10\10\10\10\10", 5) = 5
write(1, "16/44", 5) = 5
_llseek(4, 18446744071562084352, [2147500032], SEEK_SET) = 0
write(4, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 32768) = -1 EFBIG (File too large)
--- SIGXFSZ (File size limit exceeded) ---
+++ killed by SIGXFSZ +++
When login in directly from the console as root everything went right:
Welcome to SuSE Linux 7.0 (i386) - Kernel 2.4.14 (tty1).
zodiak login: root
Password:
zodiak:~ # mkfs.ext2 /dev/hdc4
mke2fs 1.18, 11-Nov-1999 for EXT2 FS 0.5b, 95/08/09
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
716672 inodes, 1432116 blocks
71605 blocks (5.00%) reserved for the super user
First data block=0
44 block groups
32768 blocks per group, 32768 fragments per group
16288 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736
Writing inode tables: done
Writing superblocks and filesystem accounting information: done
zodiak:~ #
The RLIMIT_FSIZE showed in both cases the same values:
getrlimit(RLIMIT_FSIZE) rlim_cur: 2147483647 rlim_max: 2147483647
Can anybody point me out what went wrong? Is it a kernel limit?
Peter
Mhhh,
the strace output from the 'login: root' one (the one which was good)
looks the same till the EFBIG place:
write(1, "\10\10\10\10\10", 5) = 5
write(1, "16/44", 5) = 5
_llseek(4, 18446744071562084352, [2147500032], SEEK_SET) = 0
write(4, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 32768) = 32768
_llseek(4, 18446744071562117120, [2147532800], SEEK_SET) = 0
write(4, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 32768) = 32768
_llseek(4, 18446744071562149888, [2147565568], SEEK_SET) = 0
write(4, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 32768) = 32768
_llseek(4, 18446744071562182656, [2147598336], SEEK_SET) = 0
write(4, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 32768) = 32768
Peter
On Wed, Nov 07, 2001 at 10:48:24PM +0200, Ville Herva wrote:
> On Wed, Nov 07, 2001 at 06:47:10PM +0100, you [Peter Seiderer] claimed:
> > Hello,
> > tried today to mkfs.ext2 a partition of my disk and detected there is
> > a little difference between 'login: root' and 'su -'.
> >
> > First I tried it this way:
> >
> > Welcome to SuSE Linux 7.0 (i386) - Kernel 2.4.14 (tty1).
> >
> > zodiak login: seiderer
> > Password:
> > seiderer@zodiak:~ > su -
> > Password:
> > zodiak:~ #
> > zodiak:~ # mkfs.ext2 /dev/hdc4
> > mke2fs 1.18, 11-Nov-1999 for EXT2 FS 0.5b, 95/08/09
> > Filesystem label=
> > OS type: Linux
> > Block size=4096 (log=2)
> > Fragment size=4096 (log=2)
> > 716672 inodes, 1432116 blocks
> > 71605 blocks (5.00%) reserved for the super user
> > First data block=0
> > 44 block groups
> > 32768 blocks per group, 32768 fragments per group
> > 16288 inodes per group
> > Superblock backups stored on blocks:
> > 32768, 98304, 163840, 229376, 294912, 819200, 884736
> >
> > Writing inode tables: 16/44File size limit exceeded
> >
> > strace showed that write returned wit EFBIG and the process ended with SIGXFSZ:
> >
> > write(1, "\10\10\10\10\10", 5) = 5
> > write(1, "16/44", 5) = 5
> > _llseek(4, 18446744071562084352, [2147500032], SEEK_SET) = 0
> > write(4, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 32768) = -1 EFBIG (File too large)
> > --- SIGXFSZ (File size limit exceeded) ---
> > +++ killed by SIGXFSZ +++
>
> Hmm, 18446744071562084352 = 0xffffffff80004000, 2147500032 = 0x80004000...
> It looks a tad like llseek's offset_high would have been corrupted...
> Strange.
>
> 1432116 blocks * 4096 bytes/block * 16/44 written = 2133071685.81818 so
> 2147500032 looks sane(ish).
>
>
> -- v --
>
> [email protected]
On Wed, Nov 07, 2001 at 06:47:10PM +0100, Peter Seiderer wrote:
> Hello,
> tried today to mkfs.ext2 a partition of my disk and detected there is
> a little difference between 'login: root' and 'su -'.
[snip]
> The RLIMIT_FSIZE showed in both cases the same values:
> getrlimit(RLIMIT_FSIZE) rlim_cur: 2147483647 rlim_max: 2147483647
>
> Can anybody point me out what went wrong? Is it a kernel limit?
I had similar problems. The root of all evil was ulimit in bash. After
compiling bash against the new glibc and kernel headers, all was O.K.
(the bad bash was instaled in kernel-2.2 times). So check if you have the
latest versions of kernel, glibc, e2fsprogs and bash (maybe others)
recompiled.
Cheers,
Vita
Hello,
in both cases file descriptor 4 is from 'open("/dev/hdc4", O_RDWR) = 4' ....
Peter
On Thu, Nov 08, 2001 at 08:10:07AM +0200, Ville Herva wrote:
> On Wed, Nov 07, 2001 at 11:40:25PM +0100, you [Peter Seiderer] claimed:
> > Mhhh,
> > the strace output from the 'login: root' one (the one which was good)
> > looks the same till the EFBIG place:
> >
> > write(1, "\10\10\10\10\10", 5) = 5
> > write(1, "16/44", 5) = 5
> > _llseek(4, 18446744071562084352, [2147500032], SEEK_SET) = 0
> > write(4, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 32768) = 32768
> > _llseek(4, 18446744071562117120, [2147532800], SEEK_SET) = 0
> > write(4, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 32768) = 32768
> > _llseek(4, 18446744071562149888, [2147565568], SEEK_SET) = 0
> > write(4, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 32768) = 32768
> > _llseek(4, 18446744071562182656, [2147598336], SEEK_SET) = 0
> > write(4, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 32768) = 32768
>
> Weird. Perhaps strace gets that wrong and the problem is elsewhere.
>
> Did you make sure that fd 4 is the same _partition_ in both cases (using
> strace)? The only thing I could imagine exposing 2GB limit is writing to a
> file.
>
> > > > zodiak login: seiderer
> > > > Password:
> > > > seiderer@zodiak:~ > su -
> > > > Password:
> > > > zodiak:~ #
> > > > zodiak:~ # mkfs.ext2 /dev/hdc4
> > > > mke2fs 1.18, 11-Nov-1999 for EXT2 FS 0.5b, 95/08/09
> > > > Filesystem label=
> > > > OS type: Linux
> > > > Block size=4096 (log=2)
> > > > Fragment size=4096 (log=2)
> > > > 716672 inodes, 1432116 blocks
> > > > 71605 blocks (5.00%) reserved for the super user
> > > > First data block=0
> > > > 44 block groups
> > > > 32768 blocks per group, 32768 fragments per group
> > > > 16288 inodes per group
> > > > Superblock backups stored on blocks:
> > > > 32768, 98304, 163840, 229376, 294912, 819200, 884736
> > > >
> > > > Writing inode tables: 16/44File size limit exceeded
> > > >
> > > > strace showed that write returned wit EFBIG and the process ended with SIGXFSZ:
> > > >
> > > > write(1, "\10\10\10\10\10", 5) = 5
> > > > write(1, "16/44", 5) = 5
> > > > _llseek(4, 18446744071562084352, [2147500032], SEEK_SET) = 0
> > > > write(4, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 32768) = -1 EFBIG (File too large)
> > > > --- SIGXFSZ (File size limit exceeded) ---
> > > > +++ killed by SIGXFSZ +++
> > >
> > > Hmm, 18446744071562084352 = 0xffffffff80004000, 2147500032 = 0x80004000...
> > > It looks a tad like llseek's offset_high would have been corrupted...
> > > Strange.
> > >
> > > 1432116 blocks * 4096 bytes/block * 16/44 written = 2133071685.81818 so
> > > 2147500032 looks sane(ish).
>
> -- v --
>
> [email protected]
Hello,
first thank you for your effort.
Did the diff: nearly no difference till the failure point (only pid, time etc.).
Peter
On Thu, Nov 08, 2001 at 10:46:34AM +0200, Ville Herva wrote:
> On Thu, Nov 08, 2001 at 09:46:37AM +0100, you [Peter Seiderer] claimed:
> > Hello,
> > in both cases file descriptor 4 is from 'open("/dev/hdc4", O_RDWR) = 4' ....
> > Peter
>
> Well, beats me. Sorry I wasn't much of a help...
>
> One thing you could try is to capture the strace output of both sessions up
> to the point where the 'su -' one fails. Then do a diff for those logs and
> see if anything suspicios differs. Not much _should_ differ, I reckon...
>
>
> -- v --
>
> [email protected]
--
------------------------------------------------------------------------
Peter Seiderer E-Mail: [email protected]
(Diplom-Informatiker Univ.) (PGP-key available)
Holzstr. 13 WWW : http://www.ciselant.de
D-80469 Muenchen Phone : +49 (0)89 - 69380934
------------------------------------------------------------------------
Hello,
the SIGXFSZ signal is produced in the file mm/filemap.c (linx-2.4.14) in
line 2771:
2769: if (limit != RLIM_INFINITY) {
2770: if (pos >= limit) {
2771: send_sig(SIGXFSZ, current, 0);
2772: goto out;
2773: }
The valus at this point are
limit: 0x7fffffff
RLIM_INFINITY: 0xffffffff
pos: 0x80004000
where limit comes from:
unsigned long limit = current->rlim[RLIMIT_FSIZE].rlim_cur;
but I did not yet detected the point(s) where
current->rlim[RLIMIT_FSIZE].rlim_cur
is(are) set/changed.
Peter
On Thu, Nov 08, 2001 at 11:13:30AM +0200, Ville Herva wrote:
> On Thu, Nov 08, 2001 at 10:00:14AM +0100, you [Peter Seiderer] claimed:
> > Hello,
> > first thank you for your effort.
> >
> > Did the diff: nearly no difference till the failure point (only pid, time
> > etc.). Peter
>
> And there really are no resource limits nor quota?
>
> At this point you'll propably have to dig into glibc / kernel source and try
> to find out what might cause that...
>
>
> -- v --
>
On Thu, Nov 08, 2001 at 11:14:21AM +0100, Peter Seiderer wrote:
> Hello,
> the SIGXFSZ signal is produced in the file mm/filemap.c (linx-2.4.14) in
> line 2771:
>
> 2769: if (limit != RLIM_INFINITY) {
> 2770: if (pos >= limit) {
> 2771: send_sig(SIGXFSZ, current, 0);
> 2772: goto out;
> 2773: }
>
> The valus at this point are
> limit: 0x7fffffff
> RLIM_INFINITY: 0xffffffff
> pos: 0x80004000
>
> where limit comes from:
> unsigned long limit = current->rlim[RLIMIT_FSIZE].rlim_cur;
>
> but I did not yet detected the point(s) where
> current->rlim[RLIMIT_FSIZE].rlim_cur
> is(are) set/changed.
> Peter
>
Investigated a litte bit in the kernel I detected there is a
sys_getrlimit function and a sys_old_getrlimit function which is
called in arch i386, m68k, sh, ppc, s390, cris, arm which mangles the
RLIM_INFINITY: 0xffffffff to 0x7fffffff.
The problem is that it is now impossible to set the limits to
RLIM_INFINITY while only 0x7fffffff is given as input.
Therefor I programed analog to sys_old_getrlimit the function sys_old_setrlimit
which mangles all values >= 0x7fffffff to 0xffffffff (see attached patch).
Peter
Hi,
BTW, /dev/hdc4, is that a regular hard disk partition? I was always used to
create /dev/hda1, /dev/hda5, /dev/hda6 etc. as normal partitions (via
fdisk).
Is your /dev/hda hard disk drive or some other device?
Just for my curiosity :)
Regards
Petr
> -----P?vodn? zpr?va-----
> Od: Peter Seiderer [SMTP:[email protected]]
> Odesl?no: 8. listopadu 2001 9:47
> Komu: [email protected]
> Kopie: Ville Herva
> P?edm?t: Re: What is the difference between 'login: root' and 'su -'
> ?
>
> Hello,
> in both cases file descriptor 4 is from 'open("/dev/hdc4", O_RDWR) = 4'
> ....
> Peter
>
> On Thu, Nov 08, 2001 at 08:10:07AM +0200, Ville Herva wrote:
> > On Wed, Nov 07, 2001 at 11:40:25PM +0100, you [Peter Seiderer] claimed:
> > > Mhhh,
> > > the strace output from the 'login: root' one (the one which was good)
> > > looks the same till the EFBIG place:
> > >
> > > write(1, "\10\10\10\10\10", 5) = 5
> > > write(1, "16/44", 5) = 5
> > > _llseek(4, 18446744071562084352, [2147500032], SEEK_SET) = 0
> > > write(4,
> "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 32768) =
> 32768
> > > _llseek(4, 18446744071562117120, [2147532800], SEEK_SET) = 0
> > > write(4,
> "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 32768) =
> 32768
> > > _llseek(4, 18446744071562149888, [2147565568], SEEK_SET) = 0
> > > write(4,
> "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 32768) =
> 32768
> > > _llseek(4, 18446744071562182656, [2147598336], SEEK_SET) = 0
> > > write(4,
> "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 32768) =
> 32768
> >
> > Weird. Perhaps strace gets that wrong and the problem is elsewhere.
> >
> > Did you make sure that fd 4 is the same _partition_ in both cases (using
> > strace)? The only thing I could imagine exposing 2GB limit is writing to
> a
> > file.
> >
> > > > > zodiak login: seiderer
> > > > > Password:
> > > > > seiderer@zodiak:~ > su -
> > > > > Password:
> > > > > zodiak:~ #
> > > > > zodiak:~ # mkfs.ext2 /dev/hdc4
> > > > > mke2fs 1.18, 11-Nov-1999 for EXT2 FS 0.5b, 95/08/09
> > > > > Filesystem label=
> > > > > OS type: Linux
> > > > > Block size=4096 (log=2)
> > > > > Fragment size=4096 (log=2)
> > > > > 716672 inodes, 1432116 blocks
> > > > > 71605 blocks (5.00%) reserved for the super user
> > > > > First data block=0
> > > > > 44 block groups
> > > > > 32768 blocks per group, 32768 fragments per group
> > > > > 16288 inodes per group
> > > > > Superblock backups stored on blocks:
> > > > > 32768, 98304, 163840, 229376, 294912, 819200, 884736
> > > > >
> > > > > Writing inode tables: 16/44File size limit exceeded
> > > > >
> > > > > strace showed that write returned wit EFBIG and the process ended
> with SIGXFSZ:
> > > > >
> > > > > write(1, "\10\10\10\10\10", 5) = 5
> > > > > write(1, "16/44", 5) = 5
> > > > > _llseek(4, 18446744071562084352, [2147500032], SEEK_SET) = 0
> > > > > write(4,
> "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 32768) = -1
> EFBIG (File too large)
> > > > > --- SIGXFSZ (File size limit exceeded) ---
> > > > > +++ killed by SIGXFSZ +++
> > > >
> > > > Hmm, 18446744071562084352 = 0xffffffff80004000, 2147500032 =
> 0x80004000...
> > > > It looks a tad like llseek's offset_high would have been
> corrupted...
> > > > Strange.
> > > >
> > > > 1432116 blocks * 4096 bytes/block * 16/44 written = 2133071685.81818
> so
> > > > 2147500032 looks sane(ish).
> >
> > -- v --
> >
> > [email protected]
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
Peter Seiderer wrote:
> Hello,
> tried today to mkfs.ext2 a partition of my disk and detected there is
> a little difference between 'login: root' and 'su -'.
[...]
> --- SIGXFSZ (File size limit exceeded) ---
> +++ killed by SIGXFSZ +++
I ran into the same Problem in SuSE 7.0 .
Turned out it was pam_limits.so , try if it works if you comment out the
line with pam_limits.so in it in /etc/pam.d/su .
You probably have to recompile the pam libraries.
--
Tobias PGP: 0x9AC7E0BC
On Thu, Nov 08, 2001 at 04:38:22PM +0100, Tobias Diedrich wrote:
> Peter Seiderer wrote:
> > Hello,
> > tried today to mkfs.ext2 a partition of my disk and detected there is
> > a little difference between 'login: root' and 'su -'.
> [...]
> > --- SIGXFSZ (File size limit exceeded) ---
> > +++ killed by SIGXFSZ +++
>
> I ran into the same Problem in SuSE 7.0 .
> Turned out it was pam_limits.so , try if it works if you comment out the
> line with pam_limits.so in it in /etc/pam.d/su .
> You probably have to recompile the pam libraries.
>
> --
> Tobias PGP: 0x9AC7E0BC
There is no pam_limits line in my /etc/pam.d/su only in /etc/pam.d/login.
But commenting it out did not help.
Peter