Garrett Holmstrom writes:
On 2012-07-19 15:57, Sam Varshavchik wrote:
The fact that the same consequences can occur from
upgrades, or some other unspecified events, is irrelevant, because
appropriate measures /can/ be easily put in place, to take the
appropriate action when upgrading, and most
On Fri, Jul 20, 2012 at 07:08:39AM -0400, Sam Varshavchik wrote:
> >??? prelink most certainly does NOT restart every daemon. prelink
> >restarts init because historically init didn't always re-exec itself at
> >shutdown, which in turn caused the root filesystem to not be cleanly
> >unmounted.
>
Chris Adams writes:
Once upon a time, Sam Varshavchik said:
> No, it's not because init is "not a standard daemon". prelink did not
> single out init for special treatment just because of its special status.
> prelink does this to every binary, not just init. It's just that the
> results of
On Fri, 2012-07-20 at 01:04 +0200, Brendan Jones wrote:
> Can someone please kill this thread.
It's easy enough to filter it out.
Reading -devel without filtering out at least one thread per month can
cause serious damage to your mental wellbeing. Just sayin'.
--
Adam Williamson
Fedora QA Commu
On 2012-07-19 15:57, Sam Varshavchik wrote:
The fact that the same consequences can occur from
upgrades, or some other unspecified events, is irrelevant, because
appropriate measures /can/ be easily put in place, to take the
appropriate action when upgrading, and most likely for whatever those
ot
Once upon a time, Sam Varshavchik said:
> No, it's not because init is "not a standard daemon". prelink did not
> single out init for special treatment just because of its special status.
> prelink does this to every binary, not just init. It's just that the
> results of prelink's frak-up ar
On 07/20/2012 12:57 AM, Sam Varshavchik wrote:
Chris Adams writes:
Once upon a time, Sam Varshavchik said:
> If what prelink is doing is perfectly fine, then there's no reason
to have
> the /sbin/telinit hack in /etc/cron.daily, is it? That statement, of
> course, would be either true or fals
Chris Adams writes:
Once upon a time, Sam Varshavchik said:
> If what prelink is doing is perfectly fine, then there's no reason to have
> the /sbin/telinit hack in /etc/cron.daily, is it? That statement, of
> course, would be either true or false irrespective of what I'm doing,
> which is co
Once upon a time, Sam Varshavchik said:
> If what prelink is doing is perfectly fine, then there's no reason to have
> the /sbin/telinit hack in /etc/cron.daily, is it? That statement, of
> course, would be either true or false irrespective of what I'm doing,
> which is completely irrelevant
On Thu, 2012-07-19 at 08:14 -0400, Sam Varshavchik wrote:
> I'm already handling updates. Updates are a no-brainer. It's a controlled,
> orderly process, and I can handle my housekeeping using the hook scripts.
>
> There is nothing comparable that can be used with prelink.
The API for that woul
On 07/19/2012 01:17 PM, Jakub Jelinek wrote:
These days I think init reexecs itself during shutdown sequence
anyway,
Yes, there's a reexec or two during shutdown. After stopping the units
the usual way, systemd re-execs into a helper program
(/usr/lib/systemd/systemd-shutdown), which does the
Tomas Mraz writes:
Actually if you normally open the /proc/pid/exe and read it, it will
give you the exact executable that was used to start the process with
the pid. That readlink will not give you path to the executable, but the
old path with '(deleted)' is very reasonable too. So what's the p
Andrew Haley writes:
On 07/19/2012 12:10 PM, Sam Varshavchik wrote:
> Andrew Haley writes:
>
>> On 07/18/2012 11:37 PM, Sam Varshavchik wrote:
>>>
>>> How do you know that the server that gave you a seemingly verified SSL
>>> certificate, that checks out, isn't an impostor that managed to crack
On 07/19/2012 12:29 PM, Andrew Haley wrote:
> On 07/19/2012 12:10 PM, Sam Varshavchik wrote:
>> Andrew Haley writes:
>>
>>> On 07/18/2012 11:37 PM, Sam Varshavchik wrote:
How do you know that the server that gave you a seemingly verified SSL
certificate, that checks out, isn't an imp
On 07/19/2012 12:10 PM, Sam Varshavchik wrote:
> Andrew Haley writes:
>
>> On 07/18/2012 11:37 PM, Sam Varshavchik wrote:
>>>
>>> How do you know that the server that gave you a seemingly verified SSL
>>> certificate, that checks out, isn't an impostor that managed to crack the
>>> right prime.
>>
On Thu, 2012-07-19 at 07:10 -0400, Sam Varshavchik wrote:
> Andrew Haley writes:
>
> > On 07/18/2012 11:37 PM, Sam Varshavchik wrote:
> > >
> > > How do you know that the server that gave you a seemingly verified SSL
> > > certificate, that checks out, isn't an impostor that managed to crack the
On Thu, Jul 19, 2012 at 07:10:18AM -0400, Sam Varshavchik wrote:
> >What's a special-case band-aid about it? It looks perfectly
> >reasonable to me. Why wouldn't you restart init?
>
> Why would you?If there's nothing wrong with with overwriting an
> executable, and, after all, that's how UNIX wo
Andrew Haley writes:
On 07/18/2012 11:37 PM, Sam Varshavchik wrote:
>
> How do you know that the server that gave you a seemingly verified SSL
> certificate, that checks out, isn't an impostor that managed to crack the
> right prime.
Because we know that to do that is at the present, time
compu
On 07/18/2012 11:37 PM, Sam Varshavchik wrote:
> Andrew Haley writes:
>
>> On 07/18/2012 12:06 PM, Sam Varshavchik wrote:
But that's not a use case. There's no way to know why you want to do
this: why you care that another process is running the exact same
executable.
>>>
>>>
Tomas Mraz writes:
On Wed, 2012-07-18 at 07:06 -0400, Sam Varshavchik wrote:
> Because that's the only process I want to talk to. A form of
authentication,
> which I already explained. More than once.
This is by no means a form of authentication exactly for the reasons
others told you alrea
Andrew Haley writes:
On 07/18/2012 12:06 PM, Sam Varshavchik wrote:
>>
>> But that's not a use case. There's no way to know why you want to do
>> this: why you care that another process is running the exact same
>> executable.
>
> Because that's the only process I want to talk to. A form of
a
Chris Adams writes:
Once upon a time, Sam Varshavchik said:
> Chris Adams writes:
> >Once upon a time, Sam Varshavchik said:
> >> Chris Adams writes:
> >> >Is there any value in this "additional check" (that nobody else
> >> >apparently does)? Do you not trust the kernel's credential handling
Once upon a time, Sam Varshavchik said:
> Chris Adams writes:
> >Once upon a time, Sam Varshavchik said:
> >> Chris Adams writes:
> >> >Is there any value in this "additional check" (that nobody else
> >> >apparently does)? Do you not trust the kernel's credential handling?
> >>
> >> I certainly
On Wed, 2012-07-18 at 07:06 -0400, Sam Varshavchik wrote:
> Andrew Haley writes:
>
> > On 07/18/2012 02:25 AM, Sam Varshavchik wrote:
> >>
> > Not exactly. You said:
> >
> > > Can you explain, then, the "correctly" approach by which an
> > > executable can affirm whether another pid is either ru
On 07/18/2012 12:06 PM, Sam Varshavchik wrote:
> Andrew Haley writes:
>
>> On 07/18/2012 02:25 AM, Sam Varshavchik wrote:
>>>
>> Not exactly. You said:
>>
>>> Can you explain, then, the "correctly" approach by which an
>>> executable can affirm whether another pid is either running the same
>>> e
Andrew Haley writes:
On 07/18/2012 02:25 AM, Sam Varshavchik wrote:
Not exactly. You said:
> Can you explain, then, the "correctly" approach by which an
> executable can affirm whether another pid is either running the same
> executable, or the post-prelinked version of the same
> executabl
Michal Schmidt writes:
On 07/18/2012 12:35 AM, Sam Varshavchik wrote:
Really? An example of a "symbolic link pointing to a non-existent
pathname"?
lrwxrwxrwx. 1 root root 15 Jul 17 18:02 /dev/stderr → /proc/self/fd/2
lrwxrwxrwx. 1 root root 15 Jul 17 18:02 /dev/stdin → /proc/self/fd/0
lrwxrwxr
On 07/18/2012 02:25 AM, Sam Varshavchik wrote:
> Chris Adams writes:
>
>> Once upon a time, Sam Varshavchik said:
>>> Chris Adams writes:
Is there any value in this "additional check" (that nobody else
apparently does)? Do you not trust the kernel's credential handling?
>>>
>>> I certa
On 07/18/2012 12:35 AM, Sam Varshavchik wrote:
Really? An example of a "symbolic link pointing to a non-existent
pathname"?
lrwxrwxrwx. 1 root root 15 Jul 17 18:02 /dev/stderr → /proc/self/fd/2
lrwxrwxrwx. 1 root root 15 Jul 17 18:02 /dev/stdin → /proc/self/fd/0
lrwxrwxrwx. 1 root root 15 Jul 17
On 18 July 2012 00:56, Chris Adams wrote:
> I ask again: do you have a legitimate use case?
> Is there _any_ case that other checks can succeed that this invented test of
> yours would catch?
I think we all know the answer to that. I've just added Sam to my
fedora-devel blacklist.
Richard
--
d
Chris Adams writes:
Once upon a time, Sam Varshavchik said:
> Chris Adams writes:
> >Is there any value in this "additional check" (that nobody else
> >apparently does)? Do you not trust the kernel's credential handling?
>
> I certainly trust it. But just because I trust it, it doesn't mean th
Miloslav Trmač writes:
On Wed, Jul 18, 2012 at 12:35 AM, Sam Varshavchik
wrote:
> Miloslav Trmač writes:
>> > Can you explain, then, the "correctly" approach by which an executable
can
>> > affirm whether another pid is either running the same executable, or the
>> > post-prelinked version
Once upon a time, Sam Varshavchik said:
> Chris Adams writes:
> >Is there any value in this "additional check" (that nobody else
> >apparently does)? Do you not trust the kernel's credential handling?
>
> I certainly trust it. But just because I trust it, it doesn't mean that any
> additional c
On Wed, Jul 18, 2012 at 12:35 AM, Sam Varshavchik wrote:
> Miloslav Trmač writes:
>> > Can you explain, then, the "correctly" approach by which an executable can
>> > affirm whether another pid is either running the same executable, or the
>> > post-prelinked version of the same executable.
>>
>>
Chris Adams writes:
Once upon a time, Sam Varshavchik said:
> Well, SCM_RIGHTS/SCM_CREDENTIALS is how you get the peer's pid in the first
> place.
>
> This would be an additional check, on top of that.
Is there any value in this "additional check" (that nobody else
apparently does)? Do you no
Miloslav Trmač writes:
On Tue, Jul 17, 2012 at 4:37 AM, Sam Varshavchik
wrote:
> Scott Schmit writes:
>> And what's the pathname of a deleted file?
>
> My point exactly. There is none. Thanks, prelink!
"Thanks, UNIX". What is the pathname of a file with several links?
Doesn't matter, eith
Miloslav Trmač writes:
On Tue, Jul 17, 2012 at 1:38 AM, Sam Varshavchik
wrote:
> Jan Kratochvil writes:
>> Non-existing /proc/self/exe file is a normal UNIX process state so a UNIX
>
>
> It is anything but "normal". The "normal" state of things is documented by
> proc(5).
Documentation tends
Bryn M. Reeves writes:
On 07/17/2012 12:42 PM, Sam Varshavchik wrote:
> … which can be used to reset the
> application, so that it knows that it's been updated.
Because that is a common need across many packages.
Apparently being notified of a prelink is not such a common need. Even
if such a
Once upon a time, Sam Varshavchik said:
> Well, SCM_RIGHTS/SCM_CREDENTIALS is how you get the peer's pid in the first
> place.
>
> This would be an additional check, on top of that.
Is there any value in this "additional check" (that nobody else
apparently does)? Do you not trust the kernel's
On Tue, Jul 17, 2012 at 4:37 AM, Sam Varshavchik wrote:
> Scott Schmit writes:
>> And what's the pathname of a deleted file?
>
> My point exactly. There is none. Thanks, prelink!
"Thanks, UNIX". What is the pathname of a file with several links?
The pathnames just doesn't mean much in UNIX, and
On Tue, Jul 17, 2012 at 1:38 AM, Sam Varshavchik wrote:
> Jan Kratochvil writes:
>> Non-existing /proc/self/exe file is a normal UNIX process state so a UNIX
>
>
> It is anything but "normal". The "normal" state of things is documented by
> proc(5).
Documentation tends to be written after-the fact
On 07/17/2012 12:42 PM, Sam Varshavchik wrote:
> … which can be used to reset the
> application, so that it knows that it's been updated.
Because that is a common need across many packages.
Apparently being notified of a prelink is not such a common need. Even
if such a thing did exist it coul
Tomasz Torcz writes:
On Tue, Jul 17, 2012 at 07:01:23AM -0400, Sam Varshavchik wrote:
> Andrew Haley writes:
>
> >On 07/17/2012 12:38 AM, Sam Varshavchik wrote:
> >> Jan Kratochvil writes:
> >>
> >>> On Sun, 15 Jul 2012 22:42:00 +0200, Sam Varshavchik wrote:
> And I wouldn't be so presumpti
Bryn M. Reeves writes:
On 07/17/2012 12:01 PM, Sam Varshavchik wrote:
> Andrew Haley writes:
>> Yes, it's the pathname that started this process. Yes, that pathname
>> may point to file that no longer exists. That's UNIX.
>
> No, that's Linux with prelink installed.
And a number of other comm
On 07/17/2012 12:01 PM, Sam Varshavchik wrote:
> Andrew Haley writes:
>> Yes, it's the pathname that started this process. Yes, that pathname
>> may point to file that no longer exists. That's UNIX.
>
> No, that's Linux with prelink installed.
And a number of other common configurations for e.g
Bryn M. Reeves writes:
On 07/17/2012 12:38 AM, Sam Varshavchik wrote:
> Jan Kratochvil writes:
>
>> On Sun, 15 Jul 2012 22:42:00 +0200, Sam Varshavchik wrote:
>>> And I wouldn't be so presumptions as to state authoritatively what
>>> is or is not a bug, in something whose purpose is not known to
On Tue, Jul 17, 2012 at 07:01:23AM -0400, Sam Varshavchik wrote:
> Andrew Haley writes:
>
> >On 07/17/2012 12:38 AM, Sam Varshavchik wrote:
> >> Jan Kratochvil writes:
> >>
> >>> On Sun, 15 Jul 2012 22:42:00 +0200, Sam Varshavchik wrote:
> And I wouldn't be so presumptions as to state authori
Andrew Haley writes:
On 07/17/2012 12:38 AM, Sam Varshavchik wrote:
> Jan Kratochvil writes:
>
>> On Sun, 15 Jul 2012 22:42:00 +0200, Sam Varshavchik wrote:
>>> And I wouldn't be so presumptions as to state authoritatively what
>>> is or is not a bug, in something whose purpose is not known to m
On 07/17/2012 12:38 AM, Sam Varshavchik wrote:
> Jan Kratochvil writes:
>
>> On Sun, 15 Jul 2012 22:42:00 +0200, Sam Varshavchik wrote:
>>> And I wouldn't be so presumptions as to state authoritatively what
>>> is or is not a bug, in something whose purpose is not known to me.
>>
>> Non-existing /
On 07/17/2012 12:38 AM, Sam Varshavchik wrote:
> Jan Kratochvil writes:
>
>> On Sun, 15 Jul 2012 22:42:00 +0200, Sam Varshavchik wrote:
>>> And I wouldn't be so presumptions as to state authoritatively what
>>> is or is not a bug, in something whose purpose is not known to me.
>>
>> Non-existing /
On Mon, Jul 16, 2012 at 5:45 PM, Scott Schmit wrote:
> And what's the pathname of a deleted file? Like it or not, that's a real
> possibility ("normal" as opposed to the result of an error condition or
> a bug), even if it's possibly not typical.
[details snipped]
> It gives you your current path
Scott Schmit writes:
On Mon, Jul 16, 2012 at 07:38:52PM -0400, Sam Varshavchik wrote:
> Jan Kratochvil writes:
>
> >On Sun, 15 Jul 2012 22:42:00 +0200, Sam Varshavchik wrote:
> >> And I wouldn't be so presumptions as to state authoritatively what
> >> is or is not a bug, in something whose purpo
On Mon, Jul 16, 2012 at 07:38:52PM -0400, Sam Varshavchik wrote:
> Jan Kratochvil writes:
>
> >On Sun, 15 Jul 2012 22:42:00 +0200, Sam Varshavchik wrote:
> >> And I wouldn't be so presumptions as to state authoritatively what
> >> is or is not a bug, in something whose purpose is not known to me.
Jan Kratochvil writes:
On Sun, 15 Jul 2012 22:42:00 +0200, Sam Varshavchik wrote:
> And I wouldn't be so presumptions as to state authoritatively what
> is or is not a bug, in something whose purpose is not known to me.
Non-existing /proc/self/exe file is a normal UNIX process state so a UNIX
Gregory Maxwell writes:
On Mon, Jul 16, 2012 at 9:30 AM, Robert Nichols
wrote:
> That would mean that prelink would skip much of a running system, and a
> full prelink could be done only by booting from separate media. Not going
> to happen.
But now that Fedora will have reboot for updates...
Richard W.M. Jones writes:
I suspect there is still a small race window, even if you've got the
right %post hook.
Does it need to be the same executable? Isn't it sufficient to check
that it's the same user (ie. using SO_PEERCRED):
http://www.perlmonks.org/?node_id=952805
Or perhaps somethin
On Mon, Jul 16, 2012 at 01:50:58PM -0400, Adam Jackson wrote:
> On Mon, 2012-07-16 at 08:32 -0700, Toshio Kuratomi wrote:
>
> > In terms of how the Guidelines would look, FPC would probably need to either
> > work on the boilerplate that the collections code uses or link to them
> > for the benefi
On Mon, 2012-07-16 at 08:32 -0700, Toshio Kuratomi wrote:
> In terms of how the Guidelines would look, FPC would probably need to either
> work on the boilerplate that the collections code uses or link to them
> for the benefit of maintainers that want to maintain rpms in EPEL 5 and
> EPEL 6.
It
On Mon, Jul 16, 2012 at 10:03:27AM -0400, Adam Jackson wrote:
> On Sun, 2012-07-15 at 15:45 +0200, Jan Kratochvil wrote:
> > On Sat, 14 Jul 2012 16:19:23 +0200, Sam Varshavchik wrote:
> > > It took me a while to figure out why my daemon kept breaking all the
> > > time, when it couldn't stat its /p
On Sun, 15 Jul 2012 22:42:00 +0200, Sam Varshavchik wrote:
> And I wouldn't be so presumptions as to state authoritatively what
> is or is not a bug, in something whose purpose is not known to me.
Non-existing /proc/self/exe file is a normal UNIX process state so a UNIX
process not being able to c
On Mon, 16 Jul 2012 09:30:47 +0200, Tomas Mraz wrote:
> Definitely not a bug. If it is a bug of anything then of the prelink
> script that it does not check the battery status.
OK, it depends whether you want to make some configuration of cron which
scripts should or should not be run on battery o
Am 15.07.2012 19:58, schrieb Jan Kratochvil:
> On Sun, 15 Jul 2012 19:37:26 +0200, Reindl Harald wrote:
>> you must start openoffice damned often that the benfit beats out
>> the overhead of the /etc/cron.daily/prelink
>
> When you prelink it nightly on AC and run it at least once on battery, th
On Sun, 2012-07-15 at 15:45 +0200, Jan Kratochvil wrote:
> On Sat, 14 Jul 2012 16:19:23 +0200, Sam Varshavchik wrote:
> > It took me a while to figure out why my daemon kept breaking all the
> > time, when it couldn't stat its /proc/self/exe any more.
>
> This is a bug of the daemon. While it is
On Mon, Jul 16, 2012 at 9:30 AM, Robert Nichols
wrote:
> That would mean that prelink would skip much of a running system, and a
> full prelink could be done only by booting from separate media. Not going
> to happen.
But now that Fedora will have reboot for updates... problem solved, right? :)
On 07/15/2012 09:20 PM, Sam Varshavchik wrote:
I think that 99% of the problems that prelink is creating can be easily avoided
simply by having prelink automatically skip executables that are currently
running. This is something that should not be very difficult to do. All the
information is triv
On Sun, Jul 15, 2012 at 08:46:06PM -0400, Sam Varshavchik wrote:
> Chris Adams writes:
>
> >Once upon a time, Sam Varshavchik said:
> >> I would expect that /proc/self/exe symlink gives the name of the running
> >> executable. I don't think it's an unreasonable expectation.
> >
> >There are lots
Miloslav Trmač writes:
On Mon, Jul 16, 2012 at 4:20 AM, Sam Varshavchik
wrote:
> Chris Adams writes:
>
>> Once upon a time, Sam Varshavchik said:
>> > Chris Adams writes:
>> > >Is there anything that actually does that and depends on the result?
>>
>> You skipped this part. Can you name som
On Sun, 2012-07-15 at 19:58 +0200, Jan Kratochvil wrote:
> On Sun, 15 Jul 2012 19:37:26 +0200, Reindl Harald wrote:
> > you must start openoffice damned often that the benfit beats out
> > the overhead of the /etc/cron.daily/prelink
>
> When you prelink it nightly on AC and run it at least once o
On Mon, Jul 16, 2012 at 4:20 AM, Sam Varshavchik wrote:
> Chris Adams writes:
>
>> Once upon a time, Sam Varshavchik said:
>> > Chris Adams writes:
>> > >Is there anything that actually does that and depends on the result?
>>
>> You skipped this part. Can you name something that tries this? I b
Chris Adams writes:
Once upon a time, Sam Varshavchik said:
> Chris Adams writes:
> >Is there anything that actually does that and depends on the result?
You skipped this part. Can you name something that tries this? I bet
somebody can break it if so.
When the code is ready, I'll name it,
Chris Adams writes:
Once upon a time, Sam Varshavchik said:
> Can you explain how two completely different executables could possibly end
> up having the same absolute pathname?
chroot for one.
That would require root's environment, in order to set one up. A non-
privileged process cannot s
Once upon a time, Sam Varshavchik said:
> Chris Adams writes:
> >Is there anything that actually does that and depends on the result?
You skipped this part. Can you name something that tries this? I bet
somebody can break it if so.
--
Chris Adams
Systems and Network Administrator - HiWAAY In
Once upon a time, Sam Varshavchik said:
> Can you explain how two completely different executables could possibly end
> up having the same absolute pathname?
chroot for one.
--
Chris Adams
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that
Chris Adams writes:
Once upon a time, Sam Varshavchik said:
> I would expect that /proc/self/exe symlink gives the name of the running
> executable. I don't think it's an unreasonable expectation.
There are lots of ways that can fail already; prelink is just one.
Running "yum update" can break
Chris Adams writes:
Once upon a time, Sam Varshavchik said:
> A means for authenticating a filesystem domain socket's peer. Receive the
> peer's credentials, then check /proc/pid/exe and /proc/self/exe. If they're
> same, the daemon is talking to another instance of itself.
Is there anything t
Garrett Holmstrom writes:
On 2012-07-15 15:00, Sam Varshavchik wrote:
Benny Amorsen writes:
Perhaps it's just me, but why would the daemon stat /proc/self/exe? I
presume prelink writes a new file and renames into place as a proper
Unix program should, which still leaves the original program in
Once upon a time, Sam Varshavchik said:
> I would expect that /proc/self/exe symlink gives the name of the running
> executable. I don't think it's an unreasonable expectation.
There are lots of ways that can fail already; prelink is just one.
Running "yum update" can break it as well (not ever
Jef Spaleta writes:
On Sun, Jul 15, 2012 at 2:00 PM, Sam Varshavchik
wrote:
> A means for authenticating a filesystem domain socket's peer. Receive the
> peer's credentials, then check /proc/pid/exe and /proc/self/exe. If they're
> same, the daemon is talking to another instance of itself.
T
Once upon a time, Sam Varshavchik said:
> A means for authenticating a filesystem domain socket's peer. Receive the
> peer's credentials, then check /proc/pid/exe and /proc/self/exe. If they're
> same, the daemon is talking to another instance of itself.
Is there anything that actually does th
On 2012-07-15 15:00, Sam Varshavchik wrote:
Benny Amorsen writes:
Perhaps it's just me, but why would the daemon stat /proc/self/exe? I
presume prelink writes a new file and renames into place as a proper
Unix program should, which still leaves the original program intact on
disk until the last
On 07/15/2012 01:10 PM, Jef Spaleta wrote:
Generally speaking do we have a cron-like service that knows how to
taste for onbattery in a high level way? Or do we have to encode that
check into each script that fires from a cron-like service?
In /etc/cron.hourly/0anacron there is a test using /u
On Sun, Jul 15, 2012 at 2:00 PM, Sam Varshavchik wrote:
> A means for authenticating a filesystem domain socket's peer. Receive the
> peer's credentials, then check /proc/pid/exe and /proc/self/exe. If they're
> same, the daemon is talking to another instance of itself.
The "same" in what sense?
Benny Amorsen writes:
Sam Varshavchik writes:
> It took me a while to figure out why my daemon kept breaking all the
> time, when it couldn't stat its /proc/self/exe any more.
Perhaps it's just me, but why would the daemon stat /proc/self/exe? I
presume prelink writes a new file and renames i
Sam Varshavchik writes:
> It took me a while to figure out why my daemon kept breaking all the
> time, when it couldn't stat its /proc/self/exe any more.
Perhaps it's just me, but why would the daemon stat /proc/self/exe? I
presume prelink writes a new file and renames into place as a proper
Uni
Jan Kratochvil writes:
On Sat, 14 Jul 2012 16:19:23 +0200, Sam Varshavchik wrote:
> It took me a while to figure out why my daemon kept breaking all the
> time, when it couldn't stat its /proc/self/exe any more.
This is a bug of the daemon. While it is already suspicious it needs to mess
with
On Sun, Jul 15, 2012 at 9:58 AM, Jan Kratochvil
wrote:
> That prelink is being run on battery I repeat is a bug of cron.
>
> I had a script to disable such jobs automatically, I do it by hand nowadays.
Generally speaking do we have a cron-like service that knows how to
taste for onbattery in a hi
On Sun, 15 Jul 2012 19:37:26 +0200, Reindl Harald wrote:
> you must start openoffice damned often that the benfit beats out
> the overhead of the /etc/cron.daily/prelink
When you prelink it nightly on AC and run it at least once on battery, the
saving has been done.
> to beat the battery drain o
Am 15.07.2012 19:31, schrieb Jan Kratochvil:
> On Sun, 15 Jul 2012 15:50:39 +0200, Reindl Harald wrote:
>> only prelink is good with zero benefit?
>
> Yes, without that "zero benefit". prelink has provable startup performance
> improvement and runtime memory savings.
not practically
>> i did
On Sun, 15 Jul 2012 15:50:39 +0200, Reindl Harald wrote:
> only prelink is good with zero benefit?
Yes, without that "zero benefit". prelink has provable startup performance
improvement and runtime memory savings.
> i did not notice ever any benfit of prelink even by
> starting large applicatio
Am 15.07.2012 15:45, schrieb Jan Kratochvil:
> On Sat, 14 Jul 2012 16:19:23 +0200, Sam Varshavchik wrote:
>> It took me a while to figure out why my daemon kept breaking all the
>> time, when it couldn't stat its /proc/self/exe any more.
>
> This is a bug of the daemon
> On Sat, 14 Jul 2012 16:4
On Sat, 14 Jul 2012 16:19:23 +0200, Sam Varshavchik wrote:
> It took me a while to figure out why my daemon kept breaking all the
> time, when it couldn't stat its /proc/self/exe any more.
This is a bug of the daemon. While it is already suspicious it needs to mess
with "/proc/self/exe" stat work
Am 14.07.2012 16:19, schrieb Sam Varshavchik:
> If prelink chews on a binary that's currently running, its /proc/self/exe
> essentially goes away. Which can be
> undesirable, for a persistent daemon process.
>
> It took me a while to figure out why my daemon kept breaking all the time,
> when
If prelink chews on a binary that's currently running, its /proc/self/exe
essentially goes away. Which can be undesirable, for a persistent daemon
process.
It took me a while to figure out why my daemon kept breaking all the time,
when it couldn't stat its /proc/self/exe any more.
I suppo
93 matches
Mail list logo
