Re: Removing stale pidfile

Hello!

2014-03-21 10:53 UTC+04:00, [email protected] <[email protected]>:
> I'm using polipo as caching proxy in the middle between privoxy and tor.

I'm also using polipo to connect through tor, but rather directly,
without privoxy (because it's not relevant for me now).

> >From time to time, i'm getting in trouble. Then i've to restart polipo
> ('service polipo restart'). In the terminal i'm getting the msg
> "Removing stale pidfile". After that, all turns to work correctly.

Me, too. With polipo-1.0.4.

Which version do you use?

After I learned how to turn on core dumps in my system
(http://www.altlinux.org/Features/Core ), and invented a way to
intercept and log the requests going to polipo (with a combination of
xinetd, tee, and netcat; simply using netcat, and tee, and netcat was
not that good because it failed to listen to "parallel" incoming
connections), I was able to find out the "bad" request that caused
polipo to crash, and to write this report:
https://bugzilla.altlinux.org/show_bug.cgi?id=29900

It turned out to be a request from the Android system (for a backup)
that made polipo crash.



> This error,it's only since recently, that it happens (maybe because i
> changed distro) ...

As for me, it started happening only recently, because only recently I
had the Android tablet use the proxy and TOR for web connections all
around the day (so I started hitting the automatic backup request).
(Because the bandits ruling Russia,where I live, started to
aggressively censor connections to important web sites, such as news
and blogs, even without any court decisions --
https://www.eff.org/deeplinks/2014/03/russia-blocks-access-major-independent-news-sites
, https://en.wikipedia.org/wiki/Ilya_Ponomarev#Censorship_of_Internet
.)

> Now, what's that "stale pidfile" and how - respectively why - it
> apparently interferes with polipo?

The pidfile is a way for the service program know the controlled
daemon: the daemon's PID is saved there, so when one needs to stop it,
or check that it is running, one looks into the pidfile, and performs
the action by PID.

Whenever the service command stops the daemon, it removed the pidfile,
of course.

A "stale" pidfile simply means that the daemon crashed silently,
without any intended stop command: so, ther is no process anymore, but
the pidfile is still there.

You simply do a "service polipo restart" to start it again. The stale
pidfile is not a problem by itself.

But polipo might crash again, as it does in my case, quite regularly.
So we'd better explore what causes it to crash and try to fix it, so
that its work becomes more stable and reliable.

If core dumps are saved in your system, and you have all the
information (symbols) needed for debugging, you can run gdb on the
corrsponding core file to inspect what was happening when it crashed.
Also it's interecting to log the requests as I did. I'll post my way
to do that a bit later.

I'm going to try the most fresh HEAD version from polipo's VCS and see
whether the problem remains. BTW, I saw people talking in this mailing
list about making a release out of it already, so it must be a rather
stable version.

As a final note, here's my backtrace. Perhaps, teh problem looks
familiar to someone on the list and it is known whether it has been
fixed already (I'm sorry, I haven't yet the symbols from polipo
itself, only from glibc; but still the assertion that failed can be
read):

[imz@localhost after-core-2]$ gdb -c core.polipo.30971 -e /usr/bin/polipo
GNU gdb (GDB) 7.5.0.20121002-alt3 (ALT Linux)
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i586-alt-linux".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
[New LWP 30971]
Core was generated by `/usr/bin/polipo'.
Program terminated with signal 6, Aborted.
#0  0xb7e210c5 in __GI_raise (sig=sig@entry=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:56
56      return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig);
(gdb) bt
#0  0xb7e210c5 in __GI_raise (sig=sig@entry=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1  0xb7e228b3 in __GI_abort () at abort.c:90
#2  0xb7e19fd6 in __assert_fail_base (fmt=0xb7f2a964 "%s%s%s:%u: %s%sAssertion
`%s' failed.\n%n", assertion=assertion@entry=0x80690bf
"!object->chunks[i].locked", file=file@entry=0x8068f3c "object.c",
    line=line@entry=655, function=function@entry=0x80692ec "destroyObject") at
assert.c:92
#3  0xb7e1a087 in __GI___assert_fail (assertion=0x80690bf
"!object->chunks[i].locked", file=0x8068f3c "object.c", line=655,
function=0x80692ec "destroyObject") at assert.c:101
#4  0x0804ed8e in ?? ()
#5  0x080595d8 in ?? ()
#6  0x08059c79 in ?? ()
#7  0x0804c00e in ?? ()
#8  0x0804c386 in ?? ()
#9  0x0804c5c1 in ?? ()
#10 0x08059e29 in ?? ()
#11 0x08058c74 in ?? ()
#12 0x08059c79 in ?? ()
#13 0x0804c00e in ?? ()
#14 0x0804c386 in ?? ()
#15 0x0804c5c1 in ?? ()
#16 0x08059e29 in ?? ()
#17 0x08059e52 in ?? ()
#18 0x0805887d in ?? ()
#19 0x08058bd4 in ?? ()
#20 0x0804b63b in ?? ()
#21 0x0804b810 in ?? ()
#22 0x08049d0c in ?? ()
#23 0xb7e0c605 in __libc_start_main (main=0x1, argc=134520116, ubp_av=0x0,
init=0x8049d55, fini=0x8049970, rtld_fini=0x1, stack_end=0xbf890f04) at
libc-start.c:258
#24 0xb7facfc4 in _DYNAMIC () from /lib/ld-linux.so.2
#25 0x00000001 in ?? ()
#26 0x08049d34 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb)



Best regards,
-- 
Ivan

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech