Read this forum thread: http://forums.gentoo.org/viewtopic.php?t=56745 Reproducible: Always Steps to Reproduce: 1. Download and install glftpd with install script. Probably the same result with ebuild too but I have not tried that. 2. Change glftpd.conf to use: post_check /bin/zipscript dirlog /site/Incoming/* calc_crc * 3. Copy a file and watch /glftpd/jail/glftpd/ftp-data/logs/error.log: Sun Jul 6 20:32:01 2003 [2399 ] Error: zipscript could not be executed, file /site/incoming/Mp3/The_Stoker/08 - Hard To Explain.mp3 not tested. Return value 1 Sun Jul 6 20:32:01 2003 [2399 ] Error: zipscript could not be executed, file /site/incoming/Mp3/The_Stoker/01 - Is This It.mp3 not tested. Return value 1 4. It works with baselayout-1.8.6.7.ebuild without any other changes. Actual Results: No files are checked but filetransfer works as usual but with errors in error.log. Expected Results: I use this zipscript http://freshmeat.net/projects/jzipscript/?topic_id=89 and you can see race stats and incomplete or complete release. When I tried the zipscript that comes with glftpd I got the same result in error.log. This is my first bug report. :-)
do me a favor and see if 1.8.6.10 still has this bug ?
baselayout-1.8.6.10 has the same bug.
Additional information, baselayout-1.8.6.8-r1 and onward breaks glftpd ability to execute anything. It will say "530 Error executing command." on even the simpliest bash scripts or bins.
*** Bug 28542 has been marked as a duplicate of this bug. ***
Can someone please upgrade this bug to critical, since it's critical to me. I don't think glftpd is the only program that would 'fail' to run anything from it's chroot'ed environment because of the changes in the baselayout.
this is because the enivornment of xinetd starts up with function definitions for some reason, zipscript doesnt like function definitions in the environment ... i'd imagine it's probably because it crawls the environment before executing and then segfaults heh but at any rate, heres how i was able to 'fix' the problem for now: root@rux0r 0 init.d # diff -ur /usr/portage/sys-apps/xinetd/files/xinetd.rc6 xinetd --- /usr/portage/sys-apps/xinetd/files/xinetd.rc6 2003-05-19 12:48:39.000000000 -0400 +++ xinetd 2003-09-15 20:24:40.000000000 -0400 @@ -11,8 +11,11 @@ start() { ebegin "Starting xinetd" + ( + unset -f `set | egrep '^[a-zA-Z][^=]*\(\) $'` # filter out functions start-stop-daemon --start --quiet --exec /usr/sbin/xinetd \ -- -pidfile /var/run/xinetd.pid ${XINETD_OPTS} + ) eend $? }
az: any thoughts on this one ? and a better statement for the unset cmd is this: unset -f `declare -F | sed 's:declare -f::g'`
The problem occurrs if you're using "standard" inetd as well though. So it's not just Xinetd...
i didnt realize that anyone actually used that pos anymore :) the fix should still be the same though
I could have sworn I did comment tot this bug, maybe I did but did not submit or something :P Anyhow, cutting down the environment at this stage will mean redoing much. Also, filtering all functions when calling start, etc could work, but might break some stuff - maybe we could add a function or such for now, or a wrapper for start-stop-daemon maybe ?
heres what i thought of while doing something totally unrelated ... the reason Gentoo experiences these environment issues while other init systems do not (redhat and such) is that their init scripts are just bash scripts. our init scripts are controlled by the runscript guy. this runscript fills the environment with stuff it needs and even provides the init scripts with a lot of nifty functions (einfo, ebegin, and eend are some examples) ... the problem is, any binary we start inside of an init script should not have any of this in their environment ... in other words, i'd like to see a function added to the baselayout setup that works like this: run_prog program <arguments> this function would run the program and the given arguments while providing the program with a 'virgin' environment ... the problem that currently exists is that the active environment affects the runscript binary which in turn affects every init script run ...
> in other words, i'd like to see a function added to the baselayout setup that > works like this: > run_prog program <arguments> What I thought. Only thing now is what is 'virgin environment' ? Some things might depend on a variable set in the rc-script or a conf file (/etc/conf.d), or another file sourced (for instance the X DM stuff might break). I think the fix is to fix the problem and not add more hacks. Please just fix this for the time being - I am aware of the problem, and this is not the only thing breaking, so will as soon as I can think of a better way to manage thing do a rewrite of core things - *again* =)
Could it be that it somehow has to do with a chrooted environment? Not that I use the .ebuild /jail setup, but this bug report has me thinking. I'm currently running, but not using, a manually installed glftpd (v1.31-TLS) under daemontools using a slightly tweaked run script and get the same results. Not one single site script works which strikes me as odd.
nothing seems to get this to work huh? scripts i mean .. i cant get zipscript either to get working correctly ... any other suggestions? can we raise the level here?
well, ive added the workarounds per az's suggestion to xinetd, inetd, and daemontools no i havent version bumped them, you'll have to re-emerge them yourselves :P
>well, ive added the workarounds per az's suggestion to xinetd, inetd, and daemontools what fixes? i tried what you posted as a fix, but nothing .. >no i havent version bumped them, you'll have to re-emerge them yourselves :P re-emerge what? baselayout? glftpd? xinetd? another thing .. should xinetd be running and inetd? as i understand xinetd is all thats needed and glftpd is dependent of it .. thanks .. btw my baselayout ver is baselayout-1.8.6.10-r1
you re-emerge whichever daemon service you are using as for the fix, can anyone else confirm that my ( unset ) patch works ? it fixed the problem for me while using xinetd
>you re-emerge whichever daemon service you are using xinetd? glftpd? why re-emerge it? it wont change anything correct? >as for the fix, can anyone else confirm that my ( unset ) patch works ? it fixed the problem for me while using xinetd your unset patch is similar to below? this is what i have when i do diff -ur /usr/portage/sys-apps/xinetd/files/xinetd.rc6 xinetd should i change anything? diff -ur /usr/portage/sys-apps/xinetd/files/xinetd.rc6 xinetd --- /usr/portage/sys-apps/xinetd/files/xinetd.rc6 2003-05-19 12:48:39.000000000 -0400 +++ xinetd 2003-10-06 14:54:24.000000000 -0400 @@ -9,13 +9,16 @@ need net } -start() { - ebegin "Starting xinetd" - start-stop-daemon --start --quiet --exec /usr/sbin/xinetd \ - -- -pidfile /var/run/xinetd.pid ${XINETD_OPTS} - eend $? -} - +start() { + ebegin "Starting xinetd" + ( + unset -f `set | egrep '^[a-zA-Z][^=]*\(\) $'` # filter out functions + start-stop-daemon --start --quiet --exec /usr/sbin/xinetd\ + -- -pidfile /var/run/xinetd.pid ${XINETD_OPTS} + ) + eend $? +} + stop() { ebegin "Stopping xinetd" start-stop-daemon --stop --quiet --pidfile /var/run/xinetd.pid
is anyone working at all to fix this? not that its a major deal .. but, it would be nice to have a package woring correctly .. i know no one is under demand to fix these things, so please no flamming :0 .. just asking.. at what point do bugs get fixed? does the person assigned the bug have to come up with a fix?
Well, Mike's (Spanky) changes works this side. The real problem is the 'set -a' 's in functions.sh, rc-services.sh and rc-daemon.sh. For some reason I ran into snags where some people's bash misbehaved. I removed them again, and it still works fine here, as well as fix this issue, so I will do more testing and add it to the next baselayout.
Ok, it should work again without any wacky patches with baselayout-1.8.6.12 ..
So we are saying that this is all fixed and should function correctly with the new base layout? Also is this in the x86 tree or stable .. i dont use the x86 ..
can people try out latest baselayout and glftpd ? sys-apps/baselayout-1.8.6.12-r2 net-ftp/glftpd-1.32
No .. i have upgraded to both versions and still get the error 226- Error: post_check script (zipscript) could not be executed, file not tested.
ok .. removed everything .. had to reconfig most .. zipscript-c works partially .. it works sometimes and sometimes it doesnt .. there are also functions that should be done after postcheck and they are not .. i suspect this has to do with this overall problem .. I can not use Freddies zipscript as i get the regular error of not being able to run the postcheck file .. 226- Error: post_check script (zipscript) could not be executed, file not tested so .. its not completly working .. glad no one else uses zipscript or else they would be going crazy as i am to get this working .. thanks ..
well for you people who are having the problem, does it happen if you restart xinetd ? like, login as root after booting, restart xinetd, and see if it bugs ...
I'm having the same problem with a manual install of Glftpd. I'm using baselayout 1.8.5.9 now, and rely on the GL install for this machine. So i can't upgrade my gentoo now, as it means breaking Glftpd. No zipscript or other site script will work at all with the newer layouts.
I installed sys-apps/baselayout-1.8.6.12-r3 and glftpd (not with emerge) with GL install script and told it to use inetd. After that I installed the zipscript and it seems to work but I am not a guru so it would be nice if someone with more experience tried it.
i hate to ask, but has anyone tested with sys-apps/baselayout-1.8.6.13 ?
I have been reluctant to upgrade baselayout because it messes with my config files alot, but I also really do want to keep my Gentoo up to date without losing glftpd functionality that I need. But, good news, I have just emerged baselayout-1.8.6.13 and all my site scripts, including zipscript, seem to work just fine! Maybe someone else should try it and verify, but to me this bug is history.
if the latest stable baselayout (1.8.6.13) is still broken please pipe up
I opened this bug and there is no problem with baselayout 1.8.6.13 on my server using inetd and manually installed glftpd. This bug is ok now. Thank you! Should I mark the bug as closed?
Just to add to this, i have no problems so far either with baselayout-1.8.6.13
nope, everything should be all set thanks guys :)
This code produces this output when /bin/sh is dash, /lib64/rc/sh/runscript.sh: 1: /lib64/rc/sh/runscript.sh: declare: not found [ ok ]
(In reply to Mikael Magnusson from comment #35) this bug is extremely old. if you have new problems, please file new bugs.
