Alan McKinnon <[email protected]> writes:
> On 23/11/2015 23:04, lee wrote:
>> Alan McKinnon <[email protected]> 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: [email protected]
| * 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?
