Re: [gentoo-user] emerging squid indefinitely

[lee <lee@yagibdah.de>]

Alan McKinnon <alan.mckinnon@gmail.com> writes:

> On 23/11/2015 23:04, lee wrote:
>> Alan McKinnon <alan.mckinnon@gmail.com> writes:
>> 
>>> On 23/11/2015 17:02, lee wrote:
>>>>
>>>> Hi,
>>>>
>>>> emerging squid doesn't seem to ever finish:
>>>>
>>>>
>>>> [...]
>>>>>>> Emerging (9 of 9) net-proxy/squid-3.5.6::gentoo
>>>>>>> Jobs: 8 of 9 complete, 1 running                Load avg: 0.37, 0.61, 0.53
>>>>
>>>>
>>>> What would I look at, without interrupting emerge, to find out what's
>>>> going on?
>>>>
>>>
>>>
>>> tail the build log
>> 
>> Which is where?  There isn't anything in
>> /var/log/portage/elog/summary.log, and /var/log/emerge.log only says:
>> 
>> 
>> 1448288177:  ::: completed emerge (8 of 9) net-libs/gnutls-3.3.17.1 to /
>> 1448288177:  >>> emerge (9 of 9) net-proxy/squid-3.5.6 to /
>> 1448288177:  === (9 of 9) Cleaning (net-proxy/squid-3.5.6::/usr/portage/net-proxy/squid/squid-3.5.6.ebuild)
>> 1448288177:  === (9 of 9) Compiling/Merging (net-proxy/squid-3.5.6::/usr/portage/net-proxy/squid/squid-3.5.6.ebuild)
>> 
>> 
>> It's still pretending that it's compiling, hours later ...
>> 
>
>
> the build logs are the same place they have always been, in
> /var/tmp/portage/.....
>
> that location is a symlink to:
>
> /var/log/portage/<cat>:<pkg>-<ver>:<timestamp>.log
>
> and that info is dumped to the console in volume every time emerge fails
> for any reason.
>
> /var/log/portage/elog/summary.log and /var/log/emerge.log are emerge's
> logs and contains logs of what emerge is doing. You want build logs to
> find out what make and gcc etc are doing.

Cool, let's see what it does (It's still emerging.):


,----
| dawn ~ # cat /var/tmp/portage/net-proxy/squid-3.5.6/temp/build.log                                                                                                                                                                        
|  * Package:    net-proxy/squid-3.5.6
|  * Repository: gentoo
|  * Maintainer: eras@gentoo.org
|  * USE:        abi_x86_64 amd64 caps elibc_glibc htcp ipv6 kernel_linux pam ssl userland_GNU wccp wccpv2
|  * FEATURES:   preserve-libs sandbox userpriv usersandbox
|  * Adding group 'squid' to your system ...
|  *  - Groupid: next available
`----


,----
| dawn ~ # ps xa | grep gro
| 10563 pts/0    T      0:00 groupadd -r squid
| 11315 pts/0    S+     0:00 grep --colour=auto gro
| dawn ~ # 
`----


It shouldn't take /that/ long to add a group, not even for a system
group.


,----
| dawn ~ # grep squid /etc/group
| squid:x:245:
| dawn ~ # 
`----


So the group has already been created.  Let's create a test group:


,----
| dawn ~ # time groupadd -r test
| groupadd: cannot lock /etc/group; try again later.
| 
| real    0m15.003s
| user    0m0.000s
| sys     0m0.000s
| dawn ~ # grep test /etc/group
| dawn ~ # ls -la /etc/group*
| -rw-r--r-- 1 root root 552 Nov 23 15:16 /etc/group
| -rw------- 1 root root 539 Nov  8 19:23 /etc/group-
| -rw------- 1 root root   6 Nov 23 15:16 /etc/group.lock
| dawn ~ # 
`----


Well, ok, the file is still locked.

'group-' looks like a backup, and 'group.lock' contains 10563, which is
the pid of groupadd.  I'd think that's ok.

So what all does it take to create a system group?  I suppose I could
kill groupadd and the emerging might go on, though I wonder what the
problem might be and if something else besides making an entry to
/etc/group needs to be done.  What might require an indefinite delay
here?

Any ideas?