Re: Building GCC on AIX 5.3 w/libiconv
On Tue, Aug 16, 2005, Doug Summers wrote:
Had to jump through a couple of hoops but I finally got it to compile:
1) Built empty binutils package
Yes, some packages require binutils. And even when they are only
conditionally required, openpkg build eventually installs them.
I think the dummy package should have a very large version number, so
that it is not overruled by an official version.
2) Added '--with-libiconv-prefix=/usr \' to configure section of gcc.spec
What could be the definite solution for this infamous libiconv problem ?
Always use the system supplied version ? Add an option with_libiconv_prefix
to the gcc package ? Use --with-libiconv-prefix=%{l_prefix} and require
libiconv ?
My attempt was, to try to disable the usage of libiconv in gcc. There
are already provisions (the echo am_cv_func_iconv=no etc config.cache).
This config.cache has to be copied into the directories of some sub-
configures to become effective. But this still doesn't disable the usage
completely and i don't know exactly, whether important functionality
is lost. It looks too ugly.
(mk)
--
Matthias Kurz; Fuldastr. 3; D-28199 Bremen; VOICE +49 421 53 600 47
Im prämotorischen Cortex kann jeder ein Held sein. (bdw)
__
The OpenPKG Projectwww.openpkg.org
User Communication List openpkg-users@openpkg.org
Re: Building GCC on AIX 5.3 w/libiconv
On Wed, 17 Aug 2005, Matthias Kurz wrote: My attempt was, to try to disable the usage of libiconv in gcc. There are already provisions (the echo am_cv_func_iconv=no etc config.cache). This config.cache has to be copied into the directories of some sub- configures to become effective. But this still doesn't disable the usage completely and i don't know exactly, whether important functionality is lost. It looks too ugly. an export am_cv_func_iconv=no (for bash) would be maybe easier to do system-wide Peter -- Peter S. Mazinger ps dot m at gmx dot net ID: 0xA5F059F2 Key fingerprint = 92A4 31E1 56BC 3D5A 2D08 BB6E C389 975E A5F0 59F2 __ The OpenPKG Projectwww.openpkg.org User Communication List openpkg-users@openpkg.org
Cron Jobs Hanging
I'm getting the daily cron jobs from OpenPKG hanging on some machines, sometimes nearly killing the CPU. Here's a sample from one machine that was unusable: ps -ef | grep openpkg root 1691 1 0 Aug15 ?00:00:00 /openpkg/sbin/saslauthd -a shadow -n 2 root 1733 1691 0 Aug15 ?00:00:00 /openpkg/sbin/saslauthd -a shadow -n 2 root 1785 1 0 Aug15 ?00:00:00 /openpkg/sbin/cfservd --no-fork root 1787 1 0 Aug15 ?00:00:12 /openpkg/sbin/cfenvd --no-fork root 1992 1 0 Aug15 ?00:00:00 /openpkg/bin/sshd root 2394 1 0 Aug15 ?00:00:00 /openpkg/libexec/postfix/master root 6362 6361 0 Aug16 ?00:00:00 /bin/bash -c [ -f /openpkg/etc/rc ] /openpkg/etc/rc all daily root 6366 6362 0 Aug16 ?00:00:00 /openpkg/lib/openpkg/bash --noprofile /openpkg/etc/rc all daily root 7247 6366 0 Aug16 ?00:00:00 /openpkg/lib/openpkg/bash /tmp/rc-2005081600-6366/rc.tmp root 7251 7247 0 Aug16 ?00:00:00 /bin/sh /openpkg/bin/updatedb --localpaths=/ --netpaths= --prunepaths=/tmp /usr/tmp /var/tmp /afs --prunefs=devfs proc sysfs devpts tmpfs usbfs supermount ocfs auto autofs hsfs iso9660 afs ncpfs nfs NFS smbfs --localuser=root --netuser=root root 7295 7251 0 Aug16 ?00:00:00 /bin/sh /openpkg/bin/updatedb --localpaths=/ --netpaths= --prunepaths=/tmp /usr/tmp /var/tmp /afs --prunefs=devfs proc sysfs devpts tmpfs usbfs supermount ocfs auto autofs hsfs iso9660 afs ncpfs nfs NFS smbfs --localuser=root --netuser=root root 7296 7295 0 Aug16 ?00:00:00 su root -c /openpkg/bin/find / \( -fstype devfs -o -fstype proc -o -fstype sysfs -o -fstype devpts -o -fstype tmpfs -o -fstype usbfs -o -fstype supermount -o -fstype ocfs -o -fstype auto -o -fstype autofs -o -fstype hsfs -o -fstype iso9660 -o -fstype afs -o -fstype root 7299 7296 91 Aug16 ?1-06:50:42 /openpkg/bin/find / ( -fstype devfs -o -fstype proc -o -fstype sysfs -o -fstype devpts -o -fstype tmpfs -o -fstype usbfs -o -fstype supermount -o -fstype ocfs -o -fstype auto -o -fstype autofs -o -fstype hsfs -o -fstype iso9660 -o -fstype afs -o -fstype ncpfs -o -fstype root 16690 16689 0 00:00 ?00:00:00 /bin/bash -c [ -f /openpkg/etc/rc ] /openpkg/etc/rc all daily root 16691 16690 0 00:00 ?00:00:00 /openpkg/lib/openpkg/bash --noprofile /openpkg/etc/rc all daily root 17602 16691 0 00:00 ?00:00:00 /openpkg/lib/openpkg/bash /tmp/rc-2005081700-16691/rc.tmp root 17606 17602 0 00:00 ?00:00:00 /bin/sh /openpkg/bin/updatedb --localpaths=/ --netpaths= --prunepaths=/tmp /usr/tmp /var/tmp /afs --prunefs=devfs proc sysfs devpts tmpfs usbfs supermount ocfs auto autofs hsfs iso9660 afs ncpfs nfs NFS smbfs --localuser=root --netuser=root root 17650 17606 0 00:00 ?00:00:00 /bin/sh /openpkg/bin/updatedb --localpaths=/ --netpaths= --prunepaths=/tmp /usr/tmp /var/tmp /afs --prunefs=devfs proc sysfs devpts tmpfs usbfs supermount ocfs auto autofs hsfs iso9660 afs ncpfs nfs NFS smbfs --localuser=root --netuser=root root 17651 17650 0 00:00 ?00:00:00 su root -c /openpkg/bin/find / \( -fstype devfs -o -fstype proc -o -fstype sysfs -o -fstype devpts -o -fstype tmpfs -o -fstype usbfs -o -fstype supermount -o -fstype ocfs -o -fstype auto -o -fstype autofs -o -fstype hsfs -o -fstype iso9660 -o -fstype afs -o -fstype root 17653 17651 84 00:00 ?08:18:05 /openpkg/bin/find / ( -fstype devfs -o -fstype proc -o -fstype sysfs -o -fstype devpts -o -fstype tmpfs -o -fstype usbfs -o -fstype supermount -o -fstype ocfs -o -fstype auto -o -fstype autofs -o -fstype hsfs -o -fstype iso9660 -o -fstype afs -o -fstype ncpfs -o -fstype n This machine has only been up for 2 days and the find commands are locked up tight. I've had this happen on both a HPUX 11.11 and RHEL3 machine (this output is from RHEL3). Doug __ The OpenPKG Projectwww.openpkg.org User Communication List openpkg-users@openpkg.org
Re: Cron Jobs Hanging
Matthias Kurz wrote: On Wed, Aug 17, 2005, Doug Summers wrote: I'm getting the daily cron jobs from OpenPKG hanging on some machines, sometimes nearly killing the CPU. Here's a sample from one machine that was unusable: ps -ef | grep openpkg [...] root 7299 7296 91 Aug16 ?1-06:50:42 /openpkg/bin/find / ( -fstype devfs -o -fstype proc -o -fstype sysfs -o -fstype devpts -o -fstype tmpfs -o -fstype usbfs -o -fstype supermount -o -fstype ocfs -o -fstype auto -o -fstype autofs -o -fstype hsfs -o -fstype iso9660 -o -fstype afs -o -fstype ncpfs -o -fstype [...] root 17653 17651 84 00:00 ?08:18:05 /openpkg/bin/find / ( -fstype devfs -o -fstype proc -o -fstype sysfs -o -fstype devpts -o -fstype tmpfs -o -fstype usbfs -o -fstype supermount -o -fstype ocfs -o -fstype auto -o -fstype autofs -o -fstype hsfs -o -fstype iso9660 -o -fstype afs -o -fstype ncpfs -o -fstype n This machine has only been up for 2 days and the find commands are locked up tight. I've had this happen on both a HPUX 11.11 and RHEL3 machine (this output is from RHEL3). This are apparently updatedb processes from the findutils. You can try to look with strace (e.g. strace -p 7299), what they are doing. Did you modify rc.findutils ? (mk) Nope, never touched them. It's weird that the same set of compiled rpm's would cause some machines to hang and others to function normally. Doug __ The OpenPKG Projectwww.openpkg.org User Communication List openpkg-users@openpkg.org
Re: Cron Jobs Hanging
On Wed, Aug 17, 2005, Bill Campbell wrote:
On Wed, Aug 17, 2005, Matthias Kurz wrote:
On Wed, Aug 17, 2005, Doug Summers wrote:
I'm getting the daily cron jobs from OpenPKG hanging on some machines,
sometimes nearly killing the CPU. Here's a sample from one machine that
was unusable:
ps -ef | grep openpkg
[...]
root 7299 7296 91 Aug16 ?1-06:50:42 /openpkg/bin/find / (
-fstype devfs -o -fstype proc -o -fstype sysfs -o -fstype devpts -o
-fstype tmpfs -o -fstype usbfs -o -fstype supermount -o -fstype ocfs -o
-fstype auto -o -fstype autofs -o -fstype hsfs -o -fstype iso9660 -o
-fstype afs -o -fstype ncpfs -o -fstype
[...]
root 17653 17651 84 00:00 ?08:18:05 /openpkg/bin/find / (
-fstype devfs -o -fstype proc -o -fstype sysfs -o -fstype devpts -o
-fstype tmpfs -o -fstype usbfs -o -fstype supermount -o -fstype ocfs -o
-fstype auto -o -fstype autofs -o -fstype hsfs -o -fstype iso9660 -o
-fstype afs -o -fstype ncpfs -o -fstype n
This machine has only been up for 2 days and the find commands are
locked up tight. I've had this happen on both a HPUX 11.11 and RHEL3
machine (this output is from RHEL3).
This are apparently updatedb processes from the findutils.
You can try to look with strace (e.g. strace -p 7299), what they are
doing. Did you modify rc.findutils ?
I had posted a suggestion several month ago recommending that we implement
processing locking on programs like findutils which may run for extended
periods of time. We often use the ``shlock'' program from the inn news
software to handle this locking in shell scripts.
Using lock files like %{l_prefix}/var/$package/run/hourly.lock with shlock
is reasonably safe given the minimum time interval is fifteen minutes for
quarterly cron jobs.
Good idea. Is there a portable and stand-alone implementation of shlock?
If not we can hand-craft it with a few lines of C code, of course.
But perhaps there is already an implementation (outside of INN) which
has the necessary Autoconf stuff in place to be able to use fcntl(2),
flock(2) and as a fallback UUCP-style lock files.
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelschall.com
__
The OpenPKG Projectwww.openpkg.org
User Communication List openpkg-users@openpkg.org
Re: Cron Jobs Hanging
Apparently updatedb's find hangs when it hits a certain filesystem.
As Matthias already wrote, find out which one it is. Assuming the
file system in question of /foo/bar or is of file system type
quuxfs, you will find two interessting configuration parameters
'findutils_prunefs' and 'findutils_prunepaths' which can be overriden in
%{l_prefix}/etc/rc.conf.
You probably want to set
findutils_prunefs=$findutils_prunefs quuxfs
or
findutils_prunepaths=$findutils_prunepaths /foo/bar
in your %{l_prefix}/etc/rc.conf. After that, recheck those values with
$ %{l_prefix}/etc/rc -q findutils_prunefs
or
$ %{l_prefix}/etc/rc -q findutils_prunepaths
At next updatedb run, configured paths and file systems are being
skipped.
--
christoph schug [EMAIL PROTECTED]
__
The OpenPKG Projectwww.openpkg.org
User Communication List openpkg-users@openpkg.org
Re: Cron Jobs Hanging
On Wed, Aug 17, 2005, Ralf S. Engelschall wrote:
On Wed, Aug 17, 2005, Bill Campbell wrote:
...
I had posted a suggestion several month ago recommending that we implement
processing locking on programs like findutils which may run for extended
periods of time. We often use the ``shlock'' program from the inn news
software to handle this locking in shell scripts.
Using lock files like %{l_prefix}/var/$package/run/hourly.lock with shlock
is reasonably safe given the minimum time interval is fifteen minutes for
quarterly cron jobs.
Good idea. Is there a portable and stand-alone implementation of shlock?
If not we can hand-craft it with a few lines of C code, of course.
But perhaps there is already an implementation (outside of INN) which
has the necessary Autoconf stuff in place to be able to use fcntl(2),
flock(2) and as a fallback UUCP-style lock files.
I'm attaching the version that I'm using which is very slightly modified
from inn to get it to compile standalone.
This doesn't use fancy locking, but creates a standard file with the suffix
.lock containing the pid of the locking process. It is designed to be used
from standard shell scripts, and I've never had any problems with it on
cron jobs which typically run infrequently enough that they don't have to
worry about race conditions. It also is compatible with other locking
programs including the perl LockFile::Simple from CPAN.
Bill
--
INTERNET: [EMAIL PROTECTED] Bill Campbell; Celestial Systems, Inc.
UUCP: camco!bill PO Box 820; 6641 E. Mercer Way
FAX:(206) 232-9186 Mercer Island, WA 98040-0820; (206) 236-1676
URL: http://www.celestial.com/
A government which robs Peter to pay Paul can always depend on the support
of Paul -- George Bernard Shaw
/* $Revision: 3.3 $
**
** Produce reliable locks for shell scripts, by Peter Honeyman as told
** to Rich $alz.
*/
#include strings.h
/* #include configdata.h */
#include errno.h
#include fcntl.h
#include sys/stat.h
#include getopt.h
#define PID_T int
#define POINTER void*
#define SIZE_T size_t
#define NORETURN void
private boolBinaryLock;
private charCANTUNLINK[] = Can't unlink \%s\, %s\n;
private charCANTOPEN[] = Can't open \%s\, %s\n;
/*
** See if the process named in an existing lock still exists by
** sending it a null signal.
*/
private bool
ValidLock(name, JustChecking)
char*name;
boolJustChecking;
{
register intfd;
register inti;
PID_T pid;
charbuff[BUFSIZ];
/* Open the file. */
if ((fd = open(name, O_RDONLY)) 0) {
if (JustChecking)
return FALSE;
(void)fprintf(stderr, CANTOPEN, name, strerror(errno));
return TRUE;
}
/* Read the PID that is written there. */
if (BinaryLock) {
if (read(fd, (char *)pid, sizeof pid) != sizeof pid) {
(void)close(fd);
return FALSE;
}
}
else {
if ((i = read(fd, buff, sizeof buff - 1)) = 0) {
(void)close(fd);
return FALSE;
}
buff[i] = '\0';
pid = (PID_T) atol(buff);
}
(void)close(fd);
if (pid = 0)
return FALSE;
/* Send the signal. */
if (kill(pid, 0) 0 errno == ESRCH)
return FALSE;
/* Either the kill worked, or we're optimistic about the error code. */
return TRUE;
}
/*
** Unlink a file, print a message on error, and exit.
*/
private NORETURN
UnlinkAndExit(name, x)
char*name;
int x;
{
if (unlink(name) 0)
(void)fprintf(stderr, CANTUNLINK, name, strerror(errno));
exit(x);
}
/*
** Print a usage message and exit.
*/
private NORETURN
Usage()
{
(void)fprintf(stderr, Usage: shlock [-u|-b] -f file -p pid\n);
exit(1);
/* NOTREACHED */
}
int
main(ac, av)
int ac;
char*av[];
{
register inti;
register char *p;
register intfd;
chartmp[BUFSIZ];
charbuff[BUFSIZ];
char*name;
PID_T pid;
boolok;
boolJustChecking;
/* Set defaults. */
pid = 0;
name = NULL;
JustChecking = FALSE;
/* (void)umask(NEWSUMASK); */
/* Parse JCL. */
while ((i = getopt(ac, av, bcup:f:)) != EOF)
switch (i) {
default:
Usage();
/* NOTREACHED */
case 'b':
case 'u':
BinaryLock = TRUE;
break;
case 'c':
JustChecking = TRUE;
break;
case 'p':
pid = (PID_T) atol(optarg);
break;
case 'f':
name = optarg;
break;
}
ac -= optind;
av += optind;
if (ac || pid == 0 || name == NULL)
Usage();
/* Create the temp file in the same directory as the destination. */
if ((p = strrchr(name,
