On Sun, 7 Nov 1999, David Malone wrote:
> > The lock doesn't seem to be released until *explicitly* released, like
> > the manual page says. I don't think closing the descriptor counts as
> > an explicit unlock, though I am probably wrong. Run this program,
> > you'll see the parent still has the
> The lock doesn't seem to be released until *explicitly* released, like
> the manual page says. I don't think closing the descriptor counts as
> an explicit unlock, though I am probably wrong. Run this program,
> you'll see the parent still has the lock. Change close(fd) to flock(fd,
> LOCK_UN)
On Sat, 6 Nov 1999, Dmitrij Tejblum wrote:
> David Malone wrote:
> > A child process seems to be able to let go of a parent's lock on
> > 4.0 by closing a file discriptor, the same doesn't seem to be true
> > on 3.3.
>
> So, apparently, it was broken in rev. 1.68 of kern_descript.c. (Another
>
According to David Malone:
> But if the real master process forks and then it's child closes the fd
> which the lock was on, then the master process will have lost it's lock.
> Is this likely? Does the real master fork children to do stuff?
All the time. "master" is an inetd-like daemon which spa
On Sat, 6 Nov 1999, Dmitrij Tejblum wrote:
> Brian Fundakowski Feldman wrote:
> > There were zero comments about what order things happen in; in fact,
> > the ordering in this case is Just Plain Lame (TM). It's much more
> > correct to explicitly check for fp->f_count == 1.
>
> Not sure what yo
David Malone wrote:
> On Sat, Nov 06, 1999 at 01:29:16PM -0600, Jonathan Lemon wrote:
>
>> From the manual page for flock:
>>
>> NOTES
>> Locks are on files, not file descriptors. That is, file descriptors du-
>> plicated through dup(2) or fork(2) do not result in multiple instances
On Sun, Nov 07, 1999 at 02:01:02AM +0100, Ollivier Robert wrote:
> Right but in Postfix case this is not the case. The "master" process run to
> check whether Postfix is running or not is definitely NOT a child of the real
> "master" process.
But if the real master process forks and then it's ch
On Sat, Nov 06, 1999 at 01:29:16PM -0600, Jonathan Lemon wrote:
> From the manual page for flock:
>
> NOTES
> Locks are on files, not file descriptors. That is, file descriptors du-
> plicated through dup(2) or fork(2) do not result in multiple instances of
> a lock, but rather m
According to Jonathan Lemon:
> NOTES
> Locks are on files, not file descriptors. That is, file descriptors
> du- plicated through dup(2) or fork(2) do not result in multiple
> instances of a lock, but rather multiple references to a single lock.
> If a process holding a lock o
Brian Fundakowski Feldman wrote:
> There were zero comments about what order things happen in; in fact,
> the ordering in this case is Just Plain Lame (TM). It's much more
> correct to explicitly check for fp->f_count == 1.
Not sure what you mean. The commit clearly states that POSIX and BSD
lo
In article [EMAIL PROTECTED]> you
write:
>
>On Sat, Nov 06, 1999 at 12:50:16AM +0100, Ollivier Robert wrote:
>
>A child process seems to be able to let go of a parent's lock on
>4.0 by closing a file discriptor, the same doesn't seem to be true
>on 3.3.
>From the manual page for flock:
NOTES
David Malone wrote:
> A child process seems to be able to let go of a parent's lock on
> 4.0 by closing a file discriptor, the same doesn't seem to be true
> on 3.3.
So, apparently, it was broken in rev. 1.68 of kern_descript.c. (Another
example that comments (in closef() in this case) serve no
On Sat, Nov 06, 1999 at 12:50:16AM +0100, Ollivier Robert wrote:
A child process seems to be able to let go of a parent's lock on
4.0 by closing a file discriptor, the same doesn't seem to be true
on 3.3.
For example, if you try to run two copies of the included program
as on 3.3, you get a res
> (thanks to David O'Brien for having updated the lsof port).
More so to Vic Abell <[EMAIL PROTECTED]> for bending over backwards to
deal our changes. I forgot to mention that I've now given him access to
my Alpha. So 4.46.1 mostly works on the Alpha now.
To Unsubscribe: send mail to [EMAIL P
According to Ollivier Robert:
> 3.3-RELEASE:
>
> 405 [22:56] root@sidhe:spool/postfix# lsof pid/master.pid
> COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
> master 7155 root7uW VREG 0,131079 17 18615 pid/master.pid
> ^^^
Apparently the lock is NOT do
While changing my Postfix configuration, I stumbled on something weird.
One of Postfix's processes (master) runs all the time and keep a exclusive
write lock on $spool/pid/master.pid. When one does a reload, postfix-script
runs master with the ``-t'' argument which makes master try to get a lock
16 matches
Mail list logo
