Chris Adams writes:
Once upon a time, Sam Varshavchik mr...@courier-mta.com 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
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.
There
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 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.
Because that's the only
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
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 worked
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
right
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.
Because we know
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 impostor that managed
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 the
right
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
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
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 would
Once upon a time, Sam Varshavchik mr...@courier-mta.com 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
Chris Adams writes:
Once upon a time, Sam Varshavchik mr...@courier-mta.com 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
On 07/20/2012 12:57 AM, Sam Varshavchik wrote:
Chris Adams writes:
Once upon a time, Sam Varshavchik mr...@courier-mta.com 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
Once upon a time, Sam Varshavchik mr...@courier-mta.com 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 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
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
On 18 July 2012 00:56, Chris Adams cmad...@hiwaay.net 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
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 07/18/2012 02:25 AM, Sam Varshavchik wrote:
Chris Adams writes:
Once upon a time, Sam Varshavchik mr...@courier-mta.com 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
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
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
executable.
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
executable, or the
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 running the same
Once upon a time, Sam Varshavchik mr...@courier-mta.com said:
Chris Adams writes:
Once upon a time, Sam Varshavchik mr...@courier-mta.com 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
Chris Adams writes:
Once upon a time, Sam Varshavchik mr...@courier-mta.com said:
Chris Adams writes:
Once upon a time, Sam Varshavchik mr...@courier-mta.com said:
Chris Adams writes:
Is there any value in this additional check (that nobody else
apparently does)? Do you not trust the
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
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
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 /proc/self/exe
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 /proc/self/exe
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 me.
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 authoritatively what
is
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 me.
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. a
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 common
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 presumptions as to state
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 could
On Tue, Jul 17, 2012 at 1:38 AM, Sam Varshavchik mr...@courier-mta.com 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
On Tue, Jul 17, 2012 at 4:37 AM, Sam Varshavchik mr...@courier-mta.com 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
Once upon a time, Sam Varshavchik mr...@courier-mta.com 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
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
Miloslav Trmač writes:
On Tue, Jul 17, 2012 at 1:38 AM, Sam Varshavchik mr...@courier-mta.com
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).
Miloslav Trmač writes:
On Tue, Jul 17, 2012 at 4:37 AM, Sam Varshavchik mr...@courier-mta.com
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?
Chris Adams writes:
Once upon a time, Sam Varshavchik mr...@courier-mta.com 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
Once upon a time, Sam Varshavchik mr...@courier-mta.com 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
Miloslav Trmač writes:
On Wed, Jul 18, 2012 at 12:35 AM, Sam Varshavchik mr...@courier-mta.com
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
Chris Adams writes:
Once upon a time, Sam Varshavchik mr...@courier-mta.com 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
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 on
Miloslav Trmač writes:
On Mon, Jul 16, 2012 at 4:20 AM, Sam Varshavchik mr...@courier-mta.com
wrote:
Chris Adams writes:
Once upon a time, Sam Varshavchik mr...@courier-mta.com said:
Chris Adams writes:
Is there anything that actually does that and depends on the result?
You skipped
On Sun, Jul 15, 2012 at 08:46:06PM -0400, Sam Varshavchik wrote:
Chris Adams writes:
Once upon a time, Sam Varshavchik mr...@courier-mta.com 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
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
On Mon, Jul 16, 2012 at 9:30 AM, Robert Nichols
rnicholsnos...@comcast.net 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...
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
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, the
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 or
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
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
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 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 benefit of
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
Gregory Maxwell writes:
On Mon, Jul 16, 2012 at 9:30 AM, Robert Nichols
rnicholsnos...@comcast.net 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
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
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.
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 purpose is not
On Mon, Jul 16, 2012 at 5:45 PM, Scott Schmit i.g...@comcast.net 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
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 works
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:43:13
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 applications
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 not
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 of
On Sun, Jul 15, 2012 at 9:58 AM, Jan Kratochvil
jan.kratoch...@redhat.com 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
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
Sam Varshavchik mr...@courier-mta.com 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
Benny Amorsen writes:
Sam Varshavchik mr...@courier-mta.com 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
On Sun, Jul 15, 2012 at 2:00 PM, Sam Varshavchik mr...@courier-mta.com 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
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
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
Once upon a time, Sam Varshavchik mr...@courier-mta.com 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
Jef Spaleta writes:
On Sun, Jul 15, 2012 at 2:00 PM, Sam Varshavchik mr...@courier-mta.com
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
Once upon a time, Sam Varshavchik mr...@courier-mta.com 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
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
Chris Adams writes:
Once upon a time, Sam Varshavchik mr...@courier-mta.com 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.
Chris Adams writes:
Once upon a time, Sam Varshavchik mr...@courier-mta.com 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
Once upon a time, Sam Varshavchik mr...@courier-mta.com said:
Can you explain how two completely different executables could possibly end
up having the same absolute pathname?
chroot for one.
--
Chris Adams cmad...@hiwaay.net
Systems and Network Administrator - HiWAAY Internet Services
I
Once upon a time, Sam Varshavchik mr...@courier-mta.com 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 cmad...@hiwaay.net
Systems
Chris Adams writes:
Once upon a time, Sam Varshavchik mr...@courier-mta.com 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-
On Mon, Jul 16, 2012 at 4:20 AM, Sam Varshavchik mr...@courier-mta.com wrote:
Chris Adams writes:
Once upon a time, Sam Varshavchik mr...@courier-mta.com said:
Chris Adams writes:
Is there anything that actually does that and depends on the result?
You skipped this part. Can you name
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
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 it
91 matches
Mail list logo
