Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 25223

Summary:	up2date emails extraordinarily long
Product:	[Retired] Red Hat Linux	Reporter:	William D. Hamblen <whamblen>
Component:	up2date	Assignee:	Preston Brown <pbrown>
Status:	CLOSED DUPLICATE	QA Contact:	Jay Turner <jturner>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	6.2	CC:	hugo.van.der.kooij, srevivo
Target Milestone:	---
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2001-02-20 01:34:51 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description William D. Hamblen 2001-01-29 21:06:46 UTC

I'm using up2date-2.1.7-0.6.x on a fully patched RedHat 6.2 system.  The
machine is registered anonymously because our Priority FTP access is
actually for a lab with about a 15 machines - more than the RHN will allow
me to register.  I run the following cron job:

----
#!/bin/sh
/usr/sbin/up2date -u --nosig
----

And it works beautifully except that the email up2date sends back to me (as
the administrator) contains every status line update as well as the
important stuff.  On a run where up2date has actually downloaded and
installed some packages the email can be very large (several hundred KB). 
Here is a very tiny snippet:

----
Retrieving list of all available packages...

Removing installed packages from list of updates...

0.162%
0.243%
0.325%
...
99.91%
100.0%
There are no packages available for update.
----

Comment 1 Need Real Name 2001-01-30 01:17:09 UTC

Same problem occurs on Red Hat Linux 7.0 with a crontab entry like:
2 1 * * *       /usr/sbin/up2date -u 2> /dev/null

The update info should be redirected to stderr instead of stdout for console
operations.

Comment 2 William D. Hamblen 2001-02-01 01:28:54 UTC

Unfortunately that doesn't work for me.  Everything seems to be sent to stdout
with nothing going to stderr.   If I redirect everything,  I get no email.  If I
redirect just stderr it's the same email as with no redirection at all.  In any
case, it seems like up2date ought to do the correct thing without any special
processing on my part.  It used to work that way before all the RHN stuff became
necessary.

Comment 3 Adrian Likins 2001-02-08 05:00:48 UTC

Sounds like you need a "--quiet" mode. We'll consider it
as a feature request for the next release.

Comment 4 Preston Brown 2001-02-09 03:41:17 UTC

a reasonable request.

Comment 5 Preston Brown 2001-02-09 05:27:02 UTC

*** Bug 23694 has been marked as a duplicate of this bug. ***

Comment 6 Adrian Likins 2001-02-14 05:14:33 UTC

up2date should now detect if is running on a tty, and
if not, it doesnt print out all the percentage updating
stuff. Makes the log's much prettier. 

I'll see about still adding a --quiet as well.

Comment 7 William D. Hamblen 2001-02-14 13:16:03 UTC

That new functionality sounds like what I want.  Though, given this, I'm not sure what use a --quiet switch is.  If you want nothing it's easy enough to 
redirect everything to /dev/null. Or, if I remember right, you can tell up2date not to send any email.  And the current behavior is fine if it's running on a 
tty.  So what am I missing?

Also I didn't see a new up2date RPM anywhere.  I'd like to try this! :-)  Is that forthcoming soon?

Comment 8 Cristian Gafton 2001-02-20 01:34:47 UTC

Assigned QA to jturner

Comment 9 Preston Brown 2001-02-26 23:40:24 UTC


*** This bug has been marked as a duplicate of 19646 ***

Comment 10 Adrian Likins 2001-04-11 21:10:50 UTC

*** Bug 35614 has been marked as a duplicate of this bug. ***