On Sun, Mar 20, 2016 at 08:43:31PM -0400, Thor Lancelot Simon wrote:
> On Sun, Mar 20, 2016 at 08:53:03PM +, Roy Marples wrote:
> > On Sunday 20 March 2016 14:53:46 you wrote:
> > > On Sat, 19 Mar 2016 23:29:37 +
> > >
> > > Roy Marples wrote:
> > > > pidfile(3) is pretty crap - it just w
On Sun, Mar 20, 2016 at 08:53:03PM +, Roy Marples wrote:
> On Sunday 20 March 2016 14:53:46 you wrote:
> > On Sat, 19 Mar 2016 23:29:37 +
> >
> > Roy Marples wrote:
> > > pidfile(3) is pretty crap - it just writes to the file without any
> > > locking.
> >
> > I don't understand why you
In article <21451069.kys5rkk...@uberpc.marples.name>,
Roy Marples wrote:
>On Sunday 20 March 2016 23:05:12 Christos Zoulas wrote:
>> In article <1547312.w6y7ml9...@uberpc.marples.name>,
>> Roy Marples wrote:
>>
>> There is no need for pidfile_lock(), just fix pid_file() to return pid_t.
>> I'v
On Sunday 20 March 2016 23:05:12 Christos Zoulas wrote:
> In article <1547312.w6y7ml9...@uberpc.marples.name>,
> Roy Marples wrote:
>
> There is no need for pidfile_lock(), just fix pid_file() to return pid_t.
> I've audited the code in the tree and the code that checks, checks for -1.
> The com
In article <1547312.w6y7ml9...@uberpc.marples.name>,
Roy Marples wrote:
There is no need for pidfile_lock(), just fix pid_file() to return pid_t.
I've audited the code in the tree and the code that checks, checks for -1.
The compat code below is probably wrong anyway.
christos
>+/* The old fun
On Sunday 20 March 2016 14:53:46 you wrote:
> On Sat, 19 Mar 2016 23:29:37 +
>
> Roy Marples wrote:
> > pidfile(3) is pretty crap - it just writes to the file without any
> > locking.
>
> I don't understand why you think any of that matters. Locks only
> advisory anyway. Any noncooperating
On Mar 20, 12:02pm, charles.cui1...@gmail.com (Charles Cui) wrote:
-- Subject: Re: Google summer code 2016 project ideas
| here is the link:
|
https://docs.google.com/document/d/1zUd2LRm9vj-NgwLzKGcdOZ9Cd1YGpSmdBF0KLp_8Eek/edit?usp=sharing
Thanks, I saw it. Looks good and I offered to mentor.
c
here is the link:
https://docs.google.com/document/d/1zUd2LRm9vj-NgwLzKGcdOZ9Cd1YGpSmdBF0KLp_8Eek/edit?usp=sharing
2016-03-17 20:48 GMT-07:00 Charles Cui :
> Hi Christos,
>
>I have uploaded my proposal, you guys should be able to see it now.
> Please feel free to comment it.
>
>
> Thanks, Char
On Sat, 19 Mar 2016 23:29:37 +
Roy Marples wrote:
> pidfile(3) is pretty crap - it just writes to the file without any
> locking.
I don't understand why you think any of that matters. Locks only
advisory anyway. Any noncooperating process can (with sufficient
privilege) overwrite the file
r...@marples.name (Roy Marples) writes:
>Saying that, I'm not really bothered about any remote lock on a remote fs,
>just as long as it can lock correctly on the host.
Why would you think NFS root to be not on the host?
--
--
Michael van Elst
Internet: mlel...@
On Sunday 20 March 2016 14:04:52 Roy Marples wrote:
> Updated patch with man page changes, including an example of it's use.
> Added pidfile_remove() which fixes the existing BUGS section.
> Added pidfile_close() so a forked process can close it safely.
> Made pidfile_read() visible so it's easy to
Hi,
Could someone please review and commit the patch in bin/50460? Let me
know if it doesn't merge or if there is any issue with it.
Regards
Abhinav
Updated patch with man page changes, including an example of it's use.
Added pidfile_remove() which fixes the existing BUGS section.
Added pidfile_close() so a forked process can close it safely.
Made pidfile_read() visible so it's easy to obtain the PID to send a signal to.
RpyIndex: include/util
On Sunday 20 March 2016 09:26:23 Michael van Elst wrote:
> r...@marples.name (Roy Marples) writes:
> >So I've created pidfile_lock (patch attached) to address these problems.
>
> Does it work on NFS root?
I've not tested it especially, but I would assume so as flock(2) makes no note
of it not wo
r...@marples.name (Roy Marples) writes:
>So I've created pidfile_lock (patch attached) to address these problems.
Does it work on NFS root?
--
--
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every t
15 matches
Mail list logo