memory usage

[Michael Havens]

I thought that was a good idea!

bmike1 at c521 ~ $ sudo crontab -u bmike1 -l
no crontab for bmike1
bmike1 at c521 ~ $ sudo crontab -u root -l
no crontab for root
bmike1 at c521 ~ $

But not in my case. Unless of course there is another user it is run under.
So the mouse wheel in my mind started to creak..... So I inspected the man
for crontab.... which inspired  me to cat /etc/cron*....
which lead me down the path to ls /etc/cron.daily/
and in that directory is a file! /etc/cron.daily/apt/

So How to edit the file? Ask PLUG or ask the web? I opted to ask the web.
It told me: edit crontab with crontab -e
So I tried:
bmike1 at c521 /etc/cron.daily $ crontab -e /etc/cron.daily/apt
bmike1 at c521 /etc/cron.daily $ crontab /etc/cron.daily/apt -e
bmike1 at c521 /etc/cron.daily $ sudo crontab /etc/cron.daily/apt -e
and
bmike1 at c521 /etc/cron.daily $ sudo crontab -u bmike1 /etc/cron.daily/apt/ -e
all of which responded with:
crontab: usage error: no arguments permitted after this option
usage: crontab [-u user] file
crontab [ -u user ] [ -i ] { -e | -l | -r }
(default operation is replace, per 1003.2)
-e (edit user's crontab)
-l (list user's crontab)
-r (delete user's crontab)
-i (prompt before deleting user's crontab)
bmike1 at c521 /etc/cron.daily $
so I looked a little more in the web and so tried:
sudo *crontab -e* bmike1
which gave the same error.
So now I need to ask what I'm doing wrong.


On Mon, Sep 21, 2015 at 9:19 PM, Michael Butash <michael at butash.net> wrote:

> I've noticed on lower-end systems, that daily cron will peg a system for a
> bit while that occurs.  I had an ancient imac with ubuntu installed that
> the apt update would hang the system for like a half-hour with an old
> 400mhz ppc proc, consuming all cpu and memory, then swap and thus disks
> too.  I finally just disabled it, and shortly thereafter retired the
> outdated system itself that it obviously had outlived its usefulness vs.
> power drawn.
>
> You likely have the same issue, just when using it, the update will slam
> the system.  Might be better off doing it manually, or setting the update
> time for the cronjob to overnight when not using it.
>
> -mb
>
>
> On 09/19/2015 09:25 AM, Michael Havens wrote:
>
>> the problem seems to have been checkapt.py . I tried to figure out what
>> it does and it seems that it locks a database (apt's?). But it couldn't of
>> been apt's as I wasn't running apt. Then I ran top again and it seemed to
>> have corrected itself after 10 or fifteen minutes. Am I correct in what I
>> think it does? Is it safe to kill if this happens again?
>>
>
> ---------------------------------------------------
> PLUG-discuss mailing list - PLUG-discuss at lists.phxlinux.org
> To subscribe, unsubscribe, or to change your mail settings:
> http://lists.phxlinux.org/mailman/listinfo/plug-discuss
>



-- 
:-)~MIKE~(-:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.phxlinux.org/pipermail/plug-discuss/attachments/20150921/7faece66/attachment.html>