Somewhere between 2.4.5-pre1 and 2.4.6-pre3, the behavior of the setgid
bit on directories has changed:
2.4.5-pre1:
# mkdir foo
# chgrp adm foo
# chmod 2775 foo
# cd foo
# ls -las
total 12
4 drwxrwsr-x3 root adm 4096 Jul 3 01:11 .
4 drwxr-xr-x6 root adm
Somewhere between 2.4.5-pre1 and 2.4.6-pre3, the behavior of the setgid
bit on directories has changed:
2.4.5-pre1:
# mkdir foo
# chgrp adm foo
# chmod 2775 foo
# cd foo
# ls -las
total 12
4 drwxrwsr-x3 root adm 4096 Jul 3 01:11 .
4 drwxr-xr-x6 root adm
Urgh, learn something new everyday (ipcs, ipcrm). My apologies; apropos
didn't catch it on my boxes. :-(
--
Ken.
[EMAIL PROTECTED]
On Tue, Jun 26, 2001 at 02:09:16PM -0700, Ken Brownfield wrote:
| With RedHat's new Samba 2.0.10 RPM (the one to patch the latest
| vulnerability) they seem
With RedHat's new Samba 2.0.10 RPM (the one to patch the latest
vulnerability) they seem to have sniffed enough glue to start using SysV
IPC semaphores which apparently leak until SEM??? are reached. semget()
is returning "No space left on device", and disk/inodes/memory are all
fine.
With RedHat's new Samba 2.0.10 RPM (the one to patch the latest
vulnerability) they seem to have sniffed enough glue to start using SysV
IPC semaphores which apparently leak until SEM??? are reached. semget()
is returning No space left on device, and disk/inodes/memory are all
fine.
Anyway,
Urgh, learn something new everyday (ipcs, ipcrm). My apologies; apropos
didn't catch it on my boxes. :-(
--
Ken.
[EMAIL PROTECTED]
On Tue, Jun 26, 2001 at 02:09:16PM -0700, Ken Brownfield wrote:
| With RedHat's new Samba 2.0.10 RPM (the one to patch the latest
| vulnerability) they seem
Or you could keep your hardware and try the Intel driver, which seems to
work fine. It only works as a module, though. This might also help
narrow the issue to a driver vs. card vs. mobo/BIOS/IRQ/APIC/etc issue.
Personally, I've found the EtherExpress hardware and eepro100 driver to
be
Or you could keep your hardware and try the Intel driver, which seems to
work fine. It only works as a module, though. This might also help
narrow the issue to a driver vs. card vs. mobo/BIOS/IRQ/APIC/etc issue.
Personally, I've found the EtherExpress hardware and eepro100 driver to
be
I'd be forced to agree. I have 2.4.x in limited production, and with
the exception of the HP/APIC fatal issues that have a "noapic"
work-around, I have had no problem at all with any of the 2.4.x kernels
I've used.
Open software by definition will never reach the kind of monolithic
I'd be forced to agree. I have 2.4.x in limited production, and with
the exception of the HP/APIC fatal issues that have a noapic
work-around, I have had no problem at all with any of the 2.4.x kernels
I've used.
Open software by definition will never reach the kind of monolithic
stability
I have some info at "http://web.irridia.com/linux/; from an LPr having
issues, including the dmidecode output and a mostly complete boot-time
dmesg dump from an LPr and LP1000r. The LPr was running 2.4.2-pre4 and
the LP1000r is running 2.4.5-pre1, both without "noapic". Please let me
know
I'm losing the timer interrupt, but it's not driver-specific -- only the
motherboard is required to reproduce for me; different SCSI, RAID, and
ether drivers have been swapped out. Nothing with "HP" on it seems to
work, and it wouldn't surprise me in the least to find out that HP's
stuff is
The failure mode I'm seeing is that the timer interrupt disappears.
Hard to schedule processes at that point. I'm not seeing the IRQ issues
personally.
HP's LP1000r machine uses ServerWorks, but still shows the problem. I
only have access to HP SMP hardware currently, but they all have the
I just wanted to throw in my two cents and say that there appear to be
widespread issues with the APIC code in 2.4.x. I'm tempted to stick my
neck out and say that it might be best to disable SMP IOAPIC by default
until APIC can be massaged, at least for a wider variety of hardware.
I'm
I just wanted to throw in my two cents and say that there appear to be
widespread issues with the APIC code in 2.4.x. I'm tempted to stick my
neck out and say that it might be best to disable SMP IOAPIC by default
until APIC can be massaged, at least for a wider variety of hardware.
I'm
The failure mode I'm seeing is that the timer interrupt disappears.
Hard to schedule processes at that point. I'm not seeing the IRQ issues
personally.
HP's LP1000r machine uses ServerWorks, but still shows the problem. I
only have access to HP SMP hardware currently, but they all have the
I'm losing the timer interrupt, but it's not driver-specific -- only the
motherboard is required to reproduce for me; different SCSI, RAID, and
ether drivers have been swapped out. Nothing with HP on it seems to
work, and it wouldn't surprise me in the least to find out that HP's
stuff is
I have some info at http://web.irridia.com/linux/; from an LPr having
issues, including the dmidecode output and a mostly complete boot-time
dmesg dump from an LPr and LP1000r. The LPr was running 2.4.2-pre4 and
the LP1000r is running 2.4.5-pre1, both without noapic. Please let me
know if
On Thursday, April 26, 2001, at 07:03 AM, <[EMAIL PROTECTED]> wrote:
> he owns the computer, he may do anything he wants.
This sentence really stood out for me, and implies a profound lack of
understanding of multi-user machines. No offense intended.
I've been a Unix admin for over ten
On Thursday, April 26, 2001, at 07:03 AM, [EMAIL PROTECTED] wrote:
he owns the computer, he may do anything he wants.
This sentence really stood out for me, and implies a profound lack of
understanding of multi-user machines. No offense intended.
I've been a Unix admin for over ten years,
20 matches
Mail list logo
