Creating files in /tmp, /etc, /lib32, and /var return ENOENT (touch
/tmp/foo => strerror(ENOENT)).
However, this is done as root and the dirs are marked 755 root:root.
df -i shows only 2% inode usage.
Any explanation as to why a rwx-ed dir can't be written to? This is
breaking quite a few of the init scripts.
--
Andrey Vul
begin-base64 600 sig
bXNuLCBob21lOiBhbmRyZXkudnVsQGdtYWlsLmNvbQ0KdSBvZi B0OiBhbmRyZXkudnVsQHV0b3Jv
bnRvLmNhDQpzbXMsIHZvaWNlbWFpbDogNDE2MzAzOTkyMw0K
`
end
07-28-2010, 08:52 PM
Alan McKinnon
dir is rwx but can't create file
On Wednesday 28 July 2010 22:20:17 Andrey Vul wrote:
> Creating files in /tmp, /etc, /lib32, and /var return ENOENT (touch
> /tmp/foo => strerror(ENOENT)).
> However, this is done as root and the dirs are marked 755 root:root.
> df -i shows only 2% inode usage.
> Any explanation as to why a rwx-ed dir can't be written to? This is
> breaking quite a few of the init scripts.
>
> --
> Andrey Vul
> begin-base64 600 sig
> bXNuLCBob21lOiBhbmRyZXkudnVsQGdtYWlsLmNvbQ0KdSBvZi B0OiBhbmRyZXkudnVsQHV0b3J
> v bnRvLmNhDQpzbXMsIHZvaWNlbWFpbDogNDE2MzAzOTkyMw0K
> `
> end
sounds like / is mounted read-only
--
alan dot mckinnon at gmail dot com
07-28-2010, 10:11 PM
Bill Longman
dir is rwx but can't create file
On 07/28/2010 01:52 PM, Alan McKinnon wrote:
> On Wednesday 28 July 2010 22:20:17 Andrey Vul wrote:
>> Creating files in /tmp, /etc, /lib32, and /var return ENOENT (touch
>> /tmp/foo => strerror(ENOENT)).
>> However, this is done as root and the dirs are marked 755 root:root.
>> df -i shows only 2% inode usage.
>> Any explanation as to why a rwx-ed dir can't be written to? This is
>> breaking quite a few of the init scripts.
>>
>> --
>> Andrey Vul
>> begin-base64 600 sig
>> bXNuLCBob21lOiBhbmRyZXkudnVsQGdtYWlsLmNvbQ0KdSBvZi B0OiBhbmRyZXkudnVsQHV0b3J
>> v bnRvLmNhDQpzbXMsIHZvaWNlbWFpbDogNDE2MzAzOTkyMw0K
>> `
>> end
>
> sounds like / is mounted read-only
Do read-only filesystems typically reply ENOENT when trying to create a
file? It's usually something like "read-only filesystem" in that case.
ENOENT means it can't even find the file.
07-29-2010, 12:23 AM
Andrey Vul
dir is rwx but can't create file
If / was mounted ro, touch would output strerror(EROFS), not strerror(ENOENT)
On 2010-07-28, Bill Longman <bill.longman@gmail.com> wrote:
> On 07/28/2010 01:52 PM, Alan McKinnon wrote:
>> On Wednesday 28 July 2010 22:20:17 Andrey Vul wrote:
>>> Creating files in /tmp, /etc, /lib32, and /var return ENOENT (touch
>>> /tmp/foo => strerror(ENOENT)).
>>> However, this is done as root and the dirs are marked 755 root:root.
>>> df -i shows only 2% inode usage.
>>> Any explanation as to why a rwx-ed dir can't be written to? This is
>>> breaking quite a few of the init scripts.
>>>
>>> --
>>> Andrey Vul
>>> begin-base64 600 sig
>>> bXNuLCBob21lOiBhbmRyZXkudnVsQGdtYWlsLmNvbQ0KdSBvZi B0OiBhbmRyZXkudnVsQHV0b3J
>>> v bnRvLmNhDQpzbXMsIHZvaWNlbWFpbDogNDE2MzAzOTkyMw0K
>>> `
>>> end
>>
>> sounds like / is mounted read-only
>
> Do read-only filesystems typically reply ENOENT when trying to create a
> file? It's usually something like "read-only filesystem" in that case.
> ENOENT means it can't even find the file.
>
>
--
Sent from my mobile device
Andrey Vul
begin-base64 600 sig
bXNuLCBob21lOiBhbmRyZXkudnVsQGdtYWlsLmNvbQ0KdSBvZi B0OiBhbmRyZXkudnVsQHV0b3Jv
bnRvLmNhDQpzbXMsIHZvaWNlbWFpbDogNDE2MzAzOTkyMw0K
`
end
07-29-2010, 11:24 AM
walt
dir is rwx but can't create file
On 07/28/2010 01:20 PM, Andrey Vul wrote:
Creating files in /tmp, /etc, /lib32, and /var return ENOENT (touch
/tmp/foo => strerror(ENOENT)).
However, this is done as root and the dirs are marked 755 root:root.
On Thursday 29 July 2010 13:24:29 walt wrote:
> On 07/28/2010 01:20 PM, Andrey Vul wrote:
> > Creating files in /tmp, /etc, /lib32, and /var return ENOENT (touch
> > /tmp/foo => strerror(ENOENT)).
> > However, this is done as root and the dirs are marked 755 root:root.
>
> Is the sticky bit set on /tmp?
>
> drwxrwxrwt 26 root root 36864 2010-07-29 04:15 tmp/
> ^
That will not make a difference.
Sticky bit on a directory does not affect creation of files, only WHO may
delete them (regardless of w permissions on /tmp)
--
alan dot mckinnon at gmail dot com
07-29-2010, 12:31 PM
Alex Schuster
dir is rwx but can't create file
walt writes:
> On 07/28/2010 01:20 PM, Andrey Vul wrote:
> > Creating files in /tmp, /etc, /lib32, and /var return ENOENT (touch
> > /tmp/foo => strerror(ENOENT)).
> > However, this is done as root and the dirs are marked 755 root:root.
Are all these directories located on the root file system?
> Is the sticky bit set on /tmp?
>
> drwxrwxrwt 26 root root 36864 2010-07-29 04:15 tmp/
> ^
Well, it set or not, this would not prevent the creation of files.
I have no idea what's going on here. I'd force a fsck (touch /forcefsck;
reboot) to make sure it's no file system problem. And what about a live-
cd, does the problem happen then, too?
Wonko
07-29-2010, 12:56 PM
Andrey Vul
dir is rwx but can't create file
Also, echo > /tmp/foo => same thing
It looks like a problem with open(..., O_CREAT|O_TRUNC, 644), but i'll
retry strace'ing the open,write and see where the problem chain starts
On 2010-07-29, Andrey Vul <andrey.vul@gmail.com> wrote:
> If / was mounted ro, touch would output strerror(EROFS), not
> strerror(ENOENT)
>
> On 2010-07-28, Bill Longman <bill.longman@gmail.com> wrote:
>> On 07/28/2010 01:52 PM, Alan McKinnon wrote:
>>> On Wednesday 28 July 2010 22:20:17 Andrey Vul wrote:
>>>> Creating files in /tmp, /etc, /lib32, and /var return ENOENT (touch
>>>> /tmp/foo => strerror(ENOENT)).
>>>> However, this is done as root and the dirs are marked 755 root:root.
>>>> df -i shows only 2% inode usage.
>>>> Any explanation as to why a rwx-ed dir can't be written to? This is
>>>> breaking quite a few of the init scripts.
>>>>
>>>> --
>>>> Andrey Vul
>>>> begin-base64 600 sig
>>>> bXNuLCBob21lOiBhbmRyZXkudnVsQGdtYWlsLmNvbQ0KdSBvZi B0OiBhbmRyZXkudnVsQHV0b3J
>>>> v bnRvLmNhDQpzbXMsIHZvaWNlbWFpbDogNDE2MzAzOTkyMw0K
>>>> `
>>>> end
>>>
>>> sounds like / is mounted read-only
>>
>> Do read-only filesystems typically reply ENOENT when trying to create a
>> file? It's usually something like "read-only filesystem" in that case.
>> ENOENT means it can't even find the file.
>>
>>
>
> --
> Sent from my mobile device
>
> Andrey Vul
> begin-base64 600 sig
> bXNuLCBob21lOiBhbmRyZXkudnVsQGdtYWlsLmNvbQ0KdSBvZi B0OiBhbmRyZXkudnVsQHV0b3Jv
> bnRvLmNhDQpzbXMsIHZvaWNlbWFpbDogNDE2MzAzOTkyMw0K
> `
> end
>
--
Sent from my mobile device
Andrey Vul
begin-base64 600 sig
bXNuLCBob21lOiBhbmRyZXkudnVsQGdtYWlsLmNvbQ0KdSBvZi B0OiBhbmRyZXkudnVsQHV0b3Jv
bnRvLmNhDQpzbXMsIHZvaWNlbWFpbDogNDE2MzAzOTkyMw0K
`
end
Thu Jul 29 15:30:02 2010
Return-path: <centos-bounces@centos.org>
Envelope-to: tom@linux-archive.org
Delivery-date: Thu, 29 Jul 2010 15:13:19 +0300
Received: from mail.centos.org ([72.26.200.202]:60188)
by s2.java-tips.org with esmtp (Exim 4.69)
(envelope-from <centos-bounces@centos.org>)
id 1OeRzD-0003Tu-Oh
for tom@linux-archive.org; Thu, 29 Jul 2010 15:13:19 +0300
Received: from mail.centos.org (voxeldev.centos.org [127.0.0.1])
by mail.centos.org (Postfix) with ESMTP id 65B8D6F680;
Thu, 29 Jul 2010 08:57:46 -0400 (EDT)
X-Original-To: centos@centos.org
Delivered-To: centos@centos.org
Received: from mail.filmakademie.de (mail.filmakademie.de [193.196.129.3])
by mail.centos.org (Postfix) with ESMTP id 29B436F717
for <centos@centos.org>; Thu, 29 Jul 2010 08:57:45 -0400 (EDT)
Received: from mac10337.local ([172.17.22.29]) (authenticated bits=0)
by mail.filmakademie.de (8.13.8/8.13.8) with ESMTP id o6TCvehd005801
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
for <centos@centos.org>; Thu, 29 Jul 2010 14:57:40 +0200
Message-ID: <4C517AC4.9080200@filmakademie.de>
Date: Thu, 29 Jul 2010 14:57:40 +0200
From: =?ISO-8859-15?Q?G=F6tz_Reinicke_-_IT-Koordinator?=
<goetz.reinicke@filmakademie.de>
Organization: Filmakademie =?ISO-8859-15?Q?Baden-W=FCrttemberg_GmbH?=
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; de;
rv:1.9.2.7) Gecko/20100713 Lightning/1.0b2 Thunderbird/3.1.1
MIME-Version: 1.0
To: CentOS mailing list <centos@centos.org>
References: <4C516C2E.2010003@filmakademie.de> <4C51743F.2080602@zomojo.com>
In-Reply-To: <4C51743F.2080602@zomojo.com>
X-Enigmail-Version: 1.1.1
X-Filmakademie-MailScanner-Information: Please contact the ISP for more
information
X-Filmakademie-MailScanner-ID: o6TCvehd005801
X-Filmakademie-MailScanner: Found to be clean
X-Filmakademie-MailScanner-SpamCheck: not spam,
SpamAssassin (nicht zwischen gespeichert, Wertung=-16.8,
benoetigt 3.6, autolearn=disabled, ALL_TRUSTED -1.80,
BAYES_00 -15.00)
X-Filmakademie-MailScanner-From: goetz.reinicke@filmakademie.de
Subject: Re: [CentOS] DHCP failover ... Some questions.
X-BeenThere: centos@centos.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: CentOS mailing list <centos@centos.org>
List-Id: CentOS mailing list <centos.centos.org>
List-Unsubscribe: <http://lists.centos.org/mailman/listinfo/centos>,
<mailto:centos-request@centos.org?subject=unsubscribe>
List-Archive: <http://lists.centos.org/pipermail/centos>
List-Post: <mailto:centos@centos.org>
List-Help: <mailto:centos-request@centos.org?subject=help>
List-Subscribe: <http://lists.centos.org/mailman/listinfo/centos>,
<mailto:centos-request@centos.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0944701619=="
Sender: centos-bounces@centos.org
Errors-To: centos-bounces@centos.org
This is a cryptographically signed message in MIME format.
Am 29.07.10 14:29, schrieb Phil Manuel:
> On 29/07/10 9:55 PM, G=F6tz Reinicke - IT-Koordinator wrote:
>> Hi,
>>
>> I plan to reorganise our IP management and I'd like to implement a sla=
ve
>> DHCP server. Right now we assign IP addresses based on the
>> ethernetadress of a client 1:1.
>>
>> The tutorial here [1] is simple and looks like the thing I need.
>>
>> I do have a lot of subnetworks and my cisco router has an DHCP helper
>> address set. I know I'll have to add the second dhcp-server address.
>>
>> My questions now is:
>>
>> Dose the dhcp-slave syncs the dhcp data from the master?
>>
>> Or do I have to copy the data to the master AND slave?
>>
>> Any other sugesstions or comments?
>>
>>
>> Thanks and best regards,
>>
>> G=F6tz
>>
>> =20
> Hi,
> I thought the latest dhcp server had built-in support for master-slave =
> scenarios, it just replicates current status to the slave, and when it =
> fails the slave takes over.
Do you have any more information on that or do you just think it is like
that? I can't find any docs on that, so any hint is welcome!
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
--===============0944701619==--
07-29-2010, 01:00 PM
Andrey Vul
dir is rwx but can't create file
While /tmp's mode is 1777, it doesnt make a difference since the same
error occurs with /etc, /lib32, and /var.
On 2010-07-29, Andrey Vul <andrey.vul@gmail.com> wrote:
> Also, echo > /tmp/foo => same thing
> It looks like a problem with open(..., O_CREAT|O_TRUNC, 644), but i'll
> retry strace'ing the open,write and see where the problem chain starts
>
> On 2010-07-29, Andrey Vul <andrey.vul@gmail.com> wrote:
>> If / was mounted ro, touch would output strerror(EROFS), not
>> strerror(ENOENT)
>>
>> On 2010-07-28, Bill Longman <bill.longman@gmail.com> wrote:
>>> On 07/28/2010 01:52 PM, Alan McKinnon wrote:
>>>> On Wednesday 28 July 2010 22:20:17 Andrey Vul wrote:
>>>>> Creating files in /tmp, /etc, /lib32, and /var return ENOENT (touch
>>>>> /tmp/foo => strerror(ENOENT)).
>>>>> However, this is done as root and the dirs are marked 755 root:root.
>>>>> df -i shows only 2% inode usage.
>>>>> Any explanation as to why a rwx-ed dir can't be written to? This is
>>>>> breaking quite a few of the init scripts.
>>>>>
>>>>> --
>>>>> Andrey Vul
>>>>> begin-base64 600 sig
>>>>> bXNuLCBob21lOiBhbmRyZXkudnVsQGdtYWlsLmNvbQ0KdSBvZi B0OiBhbmRyZXkudnVsQHV0b3J
>>>>> v bnRvLmNhDQpzbXMsIHZvaWNlbWFpbDogNDE2MzAzOTkyMw0K
>>>>> `
>>>>> end
>>>>
>>>> sounds like / is mounted read-only
>>>
>>> Do read-only filesystems typically reply ENOENT when trying to create a
>>> file? It's usually something like "read-only filesystem" in that case.
>>> ENOENT means it can't even find the file.
>>>
>>>
>>
>> --
>> Sent from my mobile device
>>
>> Andrey Vul
>> begin-base64 600 sig
>> bXNuLCBob21lOiBhbmRyZXkudnVsQGdtYWlsLmNvbQ0KdSBvZi B0OiBhbmRyZXkudnVsQHV0b3Jv
>> bnRvLmNhDQpzbXMsIHZvaWNlbWFpbDogNDE2MzAzOTkyMw0K
>> `
>> end
>>
>
> --
> Sent from my mobile device
>
> Andrey Vul
> begin-base64 600 sig
> bXNuLCBob21lOiBhbmRyZXkudnVsQGdtYWlsLmNvbQ0KdSBvZi B0OiBhbmRyZXkudnVsQHV0b3Jv
> bnRvLmNhDQpzbXMsIHZvaWNlbWFpbDogNDE2MzAzOTkyMw0K
> `
> end
>
--
Sent from my mobile device
Andrey Vul
begin-base64 600 sig
bXNuLCBob21lOiBhbmRyZXkudnVsQGdtYWlsLmNvbQ0KdSBvZi B0OiBhbmRyZXkudnVsQHV0b3Jv
bnRvLmNhDQpzbXMsIHZvaWNlbWFpbDogNDE2MzAzOTkyMw0K
`
end
07-30-2010, 05:34 AM
Andrey Vul
dir is rwx but can't create file
On Thu, Jul 29, 2010 at 08:31, Alex Schuster <wonko@wonkology.org> wrote:
> walt writes:
>
>> On 07/28/2010 01:20 PM, Andrey Vul wrote:
>> > Creating files in /tmp, /etc, /lib32, and /var return ENOENT (touch
>> > /tmp/foo => *strerror(ENOENT)).
>> > However, this is done as root and the dirs are marked 755 root:root.
>
> Are all these directories located on the root file system?
>
>> Is the sticky bit set on /tmp?
>>
>> drwxrwxrwt *26 root root 36864 2010-07-29 04:15 tmp/
>> * * * * * ^
>
> Well, it set or not, this would not prevent the creation of files.
>
> I have no idea what's going on here. I'd force a fsck (touch /forcefsck;
> reboot) to make sure it's no file system problem. And what about a live-
> cd, does the problem happen then, too?
>
fsck -f followed by use of USB-SATA bridge seems to work. However, my
laptop just died, so I can't really test it on the laptop.