Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 53934 - sync'ing via vixie-cron using rsync-gentoo-portage.sh and esync seem to fail
Summary: sync'ing via vixie-cron using rsync-gentoo-portage.sh and esync seem to fail
Status: RESOLVED CANTFIX
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Michael Imhof (RETIRED)
URL:
Whiteboard:
Keywords:
: 134106 (view as bug list)
Depends on:
Blocks:
 
Reported: 2004-06-14 20:33 UTC by Brad Cowan (RETIRED)
Modified: 2009-01-15 21:18 UTC (History)
5 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Brad Cowan (RETIRED) gentoo-dev 2004-06-14 20:33:07 UTC
As the summary says, sync'ing via cron fails basically the connection just unexpectantly closes, but works fine manually. 

Reproducible: Always
Steps to Reproduce:
1.
2.
3.
Comment 1 Don Seiler (RETIRED) gentoo-dev 2004-06-14 20:48:05 UTC
I was discussing this with bcowan in IRC.  However my problem was with esync (from the esearch package).  emerge sync works fine in cron for me.
Comment 2 hollywoodb 2004-06-14 21:04:10 UTC
same issue here, seems rizzo also has same issue...

esync fails as a cronjob, 'emerge sync && eupdatedb' works flawlessly

bcowan, rizzo, and I are also running vixie cron
Comment 3 Tuan Van (RETIRED) gentoo-dev 2004-06-14 21:19:11 UTC
may be try add 'TERM="linux"' to rsync-gentoo-portage.sh
Comment 4 Mr. Bones. (RETIRED) gentoo-dev 2004-06-14 21:27:17 UTC
Also try it without the ...close_stdin.diff patch.
Comment 5 Brad Cowan (RETIRED) gentoo-dev 2004-06-14 22:22:26 UTC
no go on setting the TERM value, I'm not even having any luck from cmd anymore
Comment 6 hollywoodb 2004-06-14 22:47:17 UTC
no luck without close_stdin.diff for esync here either
Comment 7 Tuan Van (RETIRED) gentoo-dev 2004-06-15 09:32:18 UTC
with rsync-gentoo-portage.sh as is, I did
# crontab -e
*/1 * * * * /opt/gentoo-rsync/rsync-gentoo-portage.sh
it works. change it accordingly, obviously you don't want to sync every minute. BTW, I am also using vcron.
Comment 8 Brad Cowan (RETIRED) gentoo-dev 2004-06-15 19:34:01 UTC
I changed a few things, added compression back, upped the timeout to 800 instead of the 300 someone dropped it back too on the latest release, and called it directly from cron and it seems to be working again for me at the moment.
Comment 9 Marius Mauch (RETIRED) gentoo-dev 2004-12-08 21:11:35 UTC
so is this still an issue?
Comment 10 Don Seiler (RETIRED) gentoo-dev 2004-12-09 06:22:43 UTC
Forgot all about this.  I'll try it again.
Comment 11 Don Seiler (RETIRED) gentoo-dev 2004-12-13 07:22:37 UTC
It appears it still fails via cron.  After all weekend I had no new packages to update on the box that is esync'ing.  The box that is 'emerge sync'ing had plenty of new stuff.

After manually esyncing, there were then plenty of packages to emerge.  I'm going to try and capture the error text from cron.
Comment 12 Don Seiler (RETIRED) gentoo-dev 2004-12-13 07:36:24 UTC
Wrapping the esync call in a bash script didn't work either.  What do you people have for scripts that have it working?
Comment 13 Don Seiler (RETIRED) gentoo-dev 2005-02-25 07:41:57 UTC
Looks like this is still an issue.  Any chance on giving it some serious TLC?  Would be nice to just have esync done overnight.
Comment 14 Fabio Bonfante 2006-06-07 16:42:15 UTC
mybe is the same problem with eix-update... it's an environment problem.
Launching script from crontab results starting them with an empty (or at least not   the same of the system) environment.
To resolve this simply write somthing like this 
30 1 * * * source /etc/profile; /usr/sbin/eix-sync > /var/log/eix-sync-last

i think can be a good idea set a configuration option containing the environment script to launch before any other script...
Comment 15 Jakub Moc (RETIRED) gentoo-dev 2007-09-13 20:01:55 UTC
*** Bug 134106 has been marked as a duplicate of this bug. ***