Bugzilla Bug 174225

/var/lib/zope/zope-instance/bin/zopectl start

fails, where:

/var/lib/zope/zope-instance/bin/zopectl foreground

succeeds.


As of today I did:

emerge --sync
rm /usr/portage/distfiles/[zZ]ope-*
rm -r /var/lib/zope/zope-instance
emerge -av =zope-2.9.7
zope-config # installed a new instance

And then still:

shell ~ # /var/lib/zope/zope-instance/bin/zopectl start
daemon process started, pid=18699
shell ~ # /var/lib/zope/zope-instance/bin/zopectl status
daemon manager not running


-- shell ~ # emerge --info

Portage 2.1.2.2 (default-linux/x86/2006.0, gcc-3.4.5, glibc-2.3.5-r2,
2.6.16.13-xenU i686)
=================================================================
System uname: 2.6.16.13-xenU i686 AMD Opteron(tm) Processor 244
Gentoo Base System version 1.6.14
Timestamp of tree: Wed, 11 Apr 2007 19:30:09 +0000
ccache version 2.3 [disabled]
dev-lang/python:     2.3.5-r2, 2.4.2
dev-python/pycrypto: 2.0.1-r5
dev-util/ccache:     2.3
sys-apps/sandbox:    1.2.17
sys-devel/autoconf:  2.13, 2.61
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1, 1.10
sys-devel/binutils:  2.16.1
sys-devel/gcc-config: 1.3.12-r6
sys-devel/libtool:   1.5.22
virtual/os-headers:  2.6.11-r2
ACCEPT_KEYWORDS="x86"
AUTOCLEAN="yes"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-O2 -march=athlon -fomit-frame-pointer -mno-tls-direct-seg-refs"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc"
CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/terminfo"
CXXFLAGS=""
DISTDIR="/usr/portage/distfiles"
FEATURES="distlocks metadata-transfer sandbox sfperms strict"
GENTOO_MIRRORS="http://gentoo.mirrors.tds.net/gentoo "
PKGDIR="/usr/portage/packages"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress
--force --whole-file --delete --delete-after --stats --timeout=180
--exclude=/distfiles --exclude=/local --exclude=/packages
--filter=H_**/files/digest-*"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="alsa apache2 apm arts berkdb bitmap-fonts cgi cli cracklib crypt dba dri
eds emboss encode esd ffmpeg foomaticdb fortran gd gdbm gif gpm gstreamer gtk2
iconv imagemagick imap imlib ipv6 isdnlog jpeg kde libg++ libwww mad maildir
midi mikmod motif mp3 mpeg mysql ncurses nls nptl ogg opengl oss pam pcre perl
php png pppd python qt3 qt4 quicktime readline reflection session spell spl ssl
tcpd truetype truetype-fonts type1-fonts vhost vorbis x86 xml xorg xv zlib"
ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1
emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m
maestro3 trident usb-audio via82xx via82xx-modem ymfpci"
ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file
hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route
share shm softvol" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev"
KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001
mtxorb ncurses text" USERLAND="GNU" VIDEO_CARDS="apm ark ati chips cirrus cyrix
dummy fbdev glint i128 i740 i810 imstt mga neomagic nsc nv rendition s3 s3virge
savage siliconmotion sis sisusb tdfx tga trident tseng v4l vesa vga via vmware
voodoo"
Unset:  CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS,
LINGUAS, MAKEOPTS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS,
PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY

During creation of zope instance with zope-config tool, a script in
/etc/init.d/ should be created (matching name of instance).

Could you please try:
/etc/init.d/SCRIPTNAME start  # where scriptname is name of created instance?

I usually use /etc/init.d/zope-instance start

This has the same effect.

Just to rule out possible problems in the init script is why I reported the bug
with:

/var/lib/zope/zope-instance/bin/zopectl



(In reply to comment #1)
> During creation of zope instance with zope-config tool, a script in
> /etc/init.d/ should be created (matching name of instance).
> 
> Could you please try:
> /etc/init.d/SCRIPTNAME start  # where scriptname is name of created instance?
> 

This problem was identified by Andreas Jung and the 2.9.7 + 2.10.3 releases
were retracted as can be seen here:
http://www.gossamer-threads.com/lists/zope/dev/207371. Shortly there after new
tarballs for the same releases were issued. Notice that the version numbers did
not change!
Grabbing the new source from zope.org and digesting the ebuild should fix the
problem. 2.9.7-r1 and 2.10.3-r1 should be created with the updated md5sums for
the newer tarballs and the defective sources should be purged from the gentoo
mirrors. If that is possible.

Cool, thanks for the link!
(Yea, I was also harping about version numbers not changing... *mumble*)

(In reply to comment #3)
> This problem was identified by Andreas Jung and the 2.9.7 + 2.10.3 releases
> were retracted as can be seen here:
> http://www.gossamer-threads.com/lists/zope/dev/207371. Shortly there after new
> tarballs for the same releases were issued. Notice that the version numbers 
> did not change!

So this means to quickly fix it one can always do:

vi /usr/lib/zope-2.9.7/lib/python/App/ApplicationManager.py

and change line:
       def manage_restart(self, URL1):
to:
       def manage_restart(self, URL1, REQUEST=None):

This did the trick for me! Remember to re-do this fix if you ever re-emerge
unless you get an updated tarball and rebuild the ebuild.

FINAlly fixed :)

Thank you to all parties for patience and perseverence :)

Please give 4h to 24h for mirror://gentoo to fetch proper files. up to then,
md5 check will fail.