I have seen similar behaviour in our test environment. (sparc Solaris 9) Comparing a truss (of an attempt to shutdown the proxy) between a working (20050525) and non-working (20050621) nightly build shows Squid dropping its privileges before sending the kill signal through. (As Lloyd has indicated, this is where the problem occurs.) Another work-around I found was to 'su' down to squid (in our startup script) to start the proxy. But that might break other depending on whether Squid needed any root privileges during startup. Regards, David. __ David Gameau ISTS - Unix Systems University of South Australia email: david.gameau@xxxxxxxxxxxx phone: +61 8 302 3533 fax: +61 8 302 5800 Disclaimer: I didn't do it. Nobody saw me do it. You can't prove anything. > -----Original Message----- > From: Lloyd Parkes [mailto:Lloyd.Parkes@xxxxxxxxxxx] > Sent: Monday, 27 June 2005 9:04 AM > To: squid-users@xxxxxxxxxxxxxxx > Subject: Re: Problems with effective user > > > I've got back in the country and I've started doing more work > on this. I've found answers to these questions before I found > these questions. The squid-users mailing list is a bit busier > than I expected and I only found this message by chance. > > I've thrown truss at the problem and I now have a much > clearer idea of what is going on. > > >>> Henrik Nordstrom <hno@xxxxxxxxxxxxxxx> 06/25/05 9:25 AM >>> > >On Mon, 20 Jun 2005, Lloyd Parkes wrote: > >> Only one of the two squid processes runs as 'squid' the > parent still > >> runs as 'root' > >This is the way it should be. > > I agree. I can see that the command line squid is trying to > signal the child squid that is running as squid and not the > parent that is running as root. > > >I would suspect you are running a nightly snapshot or > STABLE10 patched > >with the chroot -k patch, and that there maybe is problems with this > >patch. > > You are entirely correct. I've had a lot of luck in the past > with adding patches from squid-cache.org to STABLE releases > of squid, so I threw in all the patches (six of them). > > I noticed that my test machine worked fine, so I ran "truss > /usr/local/squid/sbin/squid -k reconfigure 2> truss.out" on > each machine and compared the output. The production machine > was doing completely different stuff from my test machine. I > quickly confirmed that I had different binaries on the two > machines (bad me). > > Both squids read in the config file, but with the chroot > patch, the config file gets 'activated'. I'm guessing it's > the call to configDoConfigure() that does it. Later on squid > calls setuid(squid) which sets the real, effective and saves > user id to squid. It then tries to send the signal to the > child squid. Unfortunately the child squid is running as > USER RUSER PID PPID PGID SID COMMAND > squid root 768 766 766 766 (squid) -sDYf > /usr/local/squid/etc/squid.conf > > and the real user id of the two processes need to match if > the signal is to be delivered. > > This is all on Solaris 9, but other systems should be broadly similar. > > I can fix this by simply not using any of the extra patches. > Hopefully this info will help with any future work on the > chroot patch.
