On 2014-11-19 00:27, Philip Amadeo Saeli wrote:

Help!

Every day the last few days at precisely 17:00, my openSUSE-13.1 system begins thrashing furiously and becomes unusable for 1-2 hours or so. I've been trying to figure out what runs at that time, but the system has again become too unresponsive for me to find out. Also, since it appears to be I/O bound, it doesn't show up in the "top" display.

Leave three terminals (xterm) running, one with "top", another with "iotop -o", the last with "tailf /var/log/messages". You may have to install it. Be sure that they are both running before 5. Then, at 5, watch the display.

Yes, the system is using quite a bit of swap space presently, and I am not yet able to kill off any more processes to free up VM space (which I

Then add another xterm, sorted by the "RES" field. It will display memory hungry apps on top. If the machine is too unresponsive, you can try ssh remotely to see the terminals. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

* Carlos E. R. [2014-11-18 18:14]:

On 2014-11-19 00:27, Philip Amadeo Saeli wrote:

...

Help!

Every day the last few days at precisely 17:00, my openSUSE-13.1 system begins thrashing furiously and becomes unusable for 1-2 hours or so. I've been trying to figure out what runs at that time, but the system has again become too unresponsive for me to find out. Also, since it appears to be I/O bound, it doesn't show up in the "top" display.

Leave three terminals (xterm) running, one with "top", another with "iotop -o", the last with "tailf /var/log/messages". You may have to install it. Be sure that they are both running before 5.

Then, at 5, watch the display.

...

Yes, the system is using quite a bit of swap space presently, and I am not yet able to kill off any more processes to free up VM space (which I

Then add another xterm, sorted by the "RES" field. It will display memory hungry apps on top.

If the machine is too unresponsive, you can try ssh remotely to see the terminals.

Good suggestions. Thanks! BTW, the system has returned to normalcy now. I'll set it up before that time tomorrow and see what I can find. "top" didn't show anything: couldn't find any I/O oriented field(s) to sort on. "iotop" looks like what I need. --Phil -- Philip Amadeo Saeli openSUSE, CentOS, RHEL psaeli@zorodyne.com -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 11/18/2014 06:57 PM, Patrick Shanahan wrote:

sounds like you have a job scheduled to run at "17:00", perhaps cron or a database update or ....

What is the daily cron set to run at? See /etc/sysconfig/cron Setting DAILY_TIME -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2014-11-19 02:46, Philip Amadeo Saeli wrote:

Hmmmmm, didn't think of log rotation. Another thing to check.

Indexing. There is plain "updatedb", which simply lists the files, and there are other desktop variants wich also look at the contents, and index them. The second variant is both cpu heavy and i/o heavy. They try to code it so that it runs on iddle periods and stops automatically when other process needs more cpu, but it doesn't always work right. On occasion, they break when trying to analyze some particular document: this is a bug and could cause your symptoms. It can be disabled, of course, or simply adjusted and tuned. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

On 11/19/2014 08:42 AM, Carlos E. R. wrote:

On 2014-11-19 13:07, Cristian Rodríguez wrote:

...

If you identify what task is (probably logrotate but can't be sure) that thrashes the system and it is one provided by the distribution, we could convert it to a systemd timer unit, those can easily be given low priority to access resources, can be monitored, stopped like a regular individual service..in short something not from the stone age ;-)

You can simply ionice logrotate. :-)

According go the way /usr/lib/cron/run-crons is set up, it does: There is says # Priority change for sub scripts. # range: highest -20 ... 19 lowest prioriy # default processes start in level 10 CRON_SCRIPT_NICE_VALUE=15 -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2014-11-19 16:14, Anton Aylward wrote:

On 11/19/2014 08:42 AM, Carlos E. R. wrote:

...

You can simply ionice logrotate. :-)

According go the way /usr/lib/cron/run-crons is set up, it does:

There is says

# Priority change for sub scripts. # range: highest -20 ... 19 lowest prioriy # default processes start in level 10 CRON_SCRIPT_NICE_VALUE=15

No, it does not. Not "nice", but "ionice". Not the same thing :-) -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/19/2014 05:41 AM, Carlos E. R. wrote:

There is plain "updatedb", which simply lists the files, and there are other desktop variants wich also look at the contents, and index them. The second variant is both cpu heavy and i/o heavy. They try to code it so that it runs on iddle periods and stops automatically when other process needs more cpu, but it doesn't always work right.

Other than updatedb, none of the indexers are likely the root of this problem. Nothing about file-indexing with baloo (and friends) is scheduled to kick off at 5PM. It happens in the background continuously, and since the switch to baloo infrastructure it only indexes /home and has a huge list of file type exclusions, to which you can append your own additions. - -- After all is said and done, more is said than done. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlRs7PoACgkQv7M3G5+2DLLiswCbBqwzm8WBT4P6I0YJVrjZyQLf tR4AoIzylXALZ9x0TZsCJzUCH42q06Lu =07s/ -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2014-11-19 16:20, Anton Aylward wrote:

Now we have then agglomerated into hourly, daily, and a master script that is woken up every 15 minutes.

It is a "must have", to accommodate us home users that do not run our machines 24*7. The alternative was to use anacron instead of cron, and I think some distros do it that way.

And then there's /etc/sysconfig/cron ...

You can configure it so that it logs as each run-cron job is started, so you know which one has problems, or not. ## Type: yesno ## Default: no # # generate syslog message for all scripts in # cron.{hourly,daily,weekly,monthly} # even if they haven't returned an error? (yes/no) # SYSLOG_ON_NO_ERROR="yes" IMO, the default should be "yes".

As far as I can see from the way /usr/lib/cron/run-crons loops over /etc/cron.daily/* at whenever time "daily" is set to run, it is by the shell sort order and it includes everything there.

Yes. But you can choose the time it normally runs. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

On 11/19/2014 09:32 PM, Carlos E. R. wrote:

It is a "must have", to accommodate us home users that do not run our machines 24*7. The alternative was to use anacron instead of cron, and I think some distros do it that way.

Carlos makes an important point, one that aaron should have made. It used to be that *NIX machines were 'always on', but now we are dealing with machines that are turned on and off just like the old PCs. Where is aaron? I don't hear him complaining about how Linux is becoming more like Microsoft Windows? In this he might be able to make a case, although this has NOTHING to do with systemd -- which is probably why he's absenting himself. Either that or Henne is doing an excellent job! So I wonder. Yes, if the model is a PC replacement desktop, I can see the logic. I don't like it, but I can see it. I don't like it because I'm one of those people who leaves his machine turned on all the time. I realise that for many people, especially those using laptops, this isn't practical. But I also wonder is this is just for desktop systems? OK, but what about openSuse in clearly server situations? SLED vs SLES? Is anyone running SLES? Can they tell us how the cron is set up there? -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Am 20.11.2014 um 13:23 schrieb Anton Aylward:

On 11/19/2014 09:32 PM, Carlos E. R. wrote:

...

It is a "must have", to accommodate us home users that do not run our machines 24*7. The alternative was to use anacron instead of cron, and I think some distros do it that way.

Carlos makes an important point, one that aaron should have made. It used to be that *NIX machines were 'always on', but now we are dealing with machines that are turned on and off just like the old PCs. Where is aaron? I don't hear him complaining about how Linux is becoming more like Microsoft Windows? In this he might be able to make a case, although this has NOTHING to do with systemd -- which is probably why he's absenting himself. Either that or Henne is doing an excellent job!

So I wonder. Yes, if the model is a PC replacement desktop, I can see the logic. I don't like it, but I can see it. I don't like it because I'm one of those people who leaves his machine turned on all the time. I realise that for many people, especially those using laptops, this isn't practical.

I have a (for my definition) quite powerful machine and two large screens. They consume energy also when in sleep mode. Even if I have times that I am working 8 to 12 hours on the computer, still most of the time it would consume this energy for nothing. This is why I turn all off with a switch in the cable after shutting down... So I am quite happy that the system does its "things" although it cannot do it at any time. <win comment> The look and feel of linux, especially KDE, has really become more "windowish", although I think (with all sometimes annoying things) that now it's by far better than any win or mac UI (I /must/ work with all of them). The great advantage is, that I can let everybody sit on my computer and let them do their thing without even telling them that it's linux (and most of them don't notice). I really like that. The big difference is still that I have control over the system (or at least I believe so ;-) ), while under win and mac the system has control over me. I just had to install some programs in them and found out that the installer (run as common user) can write files which I cannot remove. I took me hours to find those files and other hours to find a way to remove them. On linux it's all just some clicks... Daniel -- Daniel Bauer photographer Basel Barcelona http://www.daniel-bauer.com room in Barcelona: https://www.airbnb.es/rooms/2416137 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 11/20/2014 08:57 AM, jdd wrote:

Le 20/11/2014 13:23, Anton Aylward a écrit :

...

Is anyone running SLES? Can they tell us how the cron is set up there?

I do not run SLES, but plain openSUSE both on desktop stopped when not used and on hosted computer 7/7 & 24/24 and never had problem to run cronjobs (mainly to rsync to an other server)

documented here

http://dodin.info/wiki/index.php?n=Doc.CompleteBackup

I think you are missing the point. Adding an _extra_ crontab entry to do backups or anything else to SLES, SLED or openSuse does nothing about the THUD! Caused by the extant cron.daily configuration and its running all the jobs together. Carlos has justified why it came about, although I can see ways where it would fail whereas as systemd implementation might work better. Consider: turning the system on for just a short while, to read mail perhaps, then off again multiple times a day, and it being off when the cron.daily is scheduled, is going to break a lot of assumptions. It may also be off when you have your fixed time crontab entry. I grant you that such usage is inappropriate for a PC and more suited to a smartphone, but yes, some pole will use the PC like that. Live with it. While systemd.timer Has the ability to schedule "30 min after boot then once daily" that too gets buqqered up by repeated short boots as mentioned above. In effect the system has no memory unless you go to lengths to record what has been done. The /usr/lib/cron/run-crons program goes part of the way by having a timestamp, but a proper mechanism needs more granularity than that. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2014-11-20 15:17, Anton Aylward wrote:

Carlos has justified why it came about, although I can see ways where it would fail whereas as systemd implementation might work better.

Consider: turning the system on for just a short while, to read mail perhaps, then off again multiple times a day, and it being off when the cron.daily is scheduled, is going to break a lot of assumptions. It may also be off when you have your fixed time crontab entry. I grant you that such usage is inappropriate for a PC and more suited to a smartphone, but yes, some pole will use the PC like that. Live with it.

Well, suppose the jobs ran the last time at 15:15 two days ago. Yesterday it was powered up at 15:05 and powered off at 15:10. The jobs did not run. Today I connect it at 15:10 and power off at 15:20: the jobs will start at 15:15:01. And will be killed at 15:20 if not finished. If instead I power it up today at 20:25, the jobs will run at 20:30. From then on, they will always run at 20:30 unless not running at that time, instead than 15:15. If it is never up at XX:00, XX:15 XX:30, XX:45, then they will never run. That was the situation till recently. Now the difference is that you choose a preferred time to run the jobs (all). If the machine is not running that time (on the quarter), it will wait till the next day, and the next, and the next, waiting for it to be up at the preferred time - up till 15 days (configurable), and then it will run at the first available quarter.

While systemd.timer Has the ability to schedule "30 min after boot then once daily" that too gets buqqered up by repeated short boots as mentioned above. In effect the system has no memory unless you go to lengths to record what has been done. The /usr/lib/cron/run-crons program goes part of the way by having a timestamp, but a proper mechanism needs more granularity than that.

A systemd method would be acceptable, IF there is a single place to configure it. Not having to go in a chase on several, difficult to find, directories and files and symlinks and commands. Features like controlling the amount of resources are interesting. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

On Thu, Nov 20, 2014 at 03:54:58PM +0100, Carlos E. R. wrote:

On 2014-11-20 15:17, Anton Aylward wrote:

You can add them to the startup scripts if there were some... Ruben

...

Carlos has justified why it came about, although I can see ways where it would fail whereas as systemd implementation might work better.

Consider: turning the system on for just a short while, to read mail perhaps, then off again multiple times a day, and it being off when the cron.daily is scheduled, is going to break a lot of assumptions. It may also be off when you have your fixed time crontab entry. I grant you that such usage is inappropriate for a PC and more suited to a smartphone, but yes, some pole will use the PC like that. Live with it.

Well, suppose the jobs ran the last time at 15:15 two days ago.

Yesterday it was powered up at 15:05 and powered off at 15:10. The jobs did not run.

Today I connect it at 15:10 and power off at 15:20: the jobs will start at 15:15:01. And will be killed at 15:20 if not finished.

If instead I power it up today at 20:25, the jobs will run at 20:30. From then on, they will always run at 20:30 unless not running at that time, instead than 15:15.

If it is never up at XX:00, XX:15 XX:30, XX:45, then they will never run.

That was the situation till recently.

Now the difference is that you choose a preferred time to run the jobs (all). If the machine is not running that time (on the quarter), it will wait till the next day, and the next, and the next, waiting for it to be up at the preferred time - up till 15 days (configurable), and then it will run at the first available quarter.

...

While systemd.timer Has the ability to schedule "30 min after boot then once daily" that too gets buqqered up by repeated short boots as mentioned above. In effect the system has no memory unless you go to lengths to record what has been done. The /usr/lib/cron/run-crons program goes part of the way by having a timestamp, but a proper mechanism needs more granularity than that.

A systemd method would be acceptable, IF there is a single place to configure it. Not having to go in a chase on several, difficult to find, directories and files and symlinks and commands. Features like controlling the amount of resources are interesting.

-- Cheers / Saludos,

Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

-- So many immigrant groups have swept through our town that Brooklyn, like Atlantis, reaches mythological proportions in the mind of the world - RI Safir 1998 http://www.mrbrklyn.com DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002 http://www.nylxs.com - Leadership Development in Free Software http://www2.mrbrklyn.com/resources - Unpublished Archive http://www.coinhangout.com - coins! http://www.brooklyn-living.com Being so tracked is for FARM ANIMALS and and extermination camps, but incompatible with living as a free human being. -RI Safir 2013 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Le 22/11/2014 16:25, Linda Walsh a écrit :

cronie-1.4.8-50.1.2.x86_64 cron-4.2-50.1.2.x86_64

Just use both. Wait, don't tell me, yast:

" cron - Auxiliary package Auxiliary package, needed for proper update from vixie-cron 4.1 to cronie 1.4.4" jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 11/22/2014 10:25 AM, Linda Walsh wrote:

Like "jdd's" comment on using film based pictures vs. electronic, you seem to miss based humor.

Oh really? perhaps because I missed the humor I failed to reply with my own 'humour' about stem powered PDP-11s and how they are responsible for Global Warming. "Funny" that, eh? -- /"\ \ / ASCII Ribbon Campaign X Against HTML Mail / \ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 11/22/2014 10:25 AM, Linda Walsh wrote:

If you use 'crontabs', they run like the old cron. Only things put in /etc/cron.{timeperiod}, get run under the new method.

Yes, that's the point I and others are trying to make. It's all those "only" things that are so involved with system administration & maintenance that are there 'out of the box'. Of course us 'experts' like thee, John, Carlos ... Others ... And myself ... Can hack the system about any which way we want and make it sit up and reg and roll over and invite us to rub it tummy, good dog, good dog, but the OP was the guy that got hit THUD! by these "only" things rendering his system unusable and asking us for help. You and I can set up cron job or systemd.timer jobs to our hearts content. You and I can pull scripts away from the cron.daily directory and put them elsewhere and run them under our own cron scheduling. Yes, that's the point: **WE** can. We have the know how. Do not assume that everyone else has our knowledge and experience; do not assume everyone has had the time to dig into how the system works. There are may people here who don't have our knowledge and experience and that's why they ask here for our help and guidance. -- /"\ \ / ASCII Ribbon Campaign X Against HTML Mail / \ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 11/22/2014 10:25 AM, Linda Walsh wrote:

...

rpm -qa|grep cron

cronie-1.4.8-50.1.2.x86_64 cron-4.2-50.1.2.x86_64

Just use both. Wait, don't tell me, the new Xd doesn't allow this?

Hmmmm $ rpm -ql cron /usr/share/doc/packages/cron /usr/share/doc/packages/cron/cron_to_cronie.README Hmmmm ============================================================= $ more /usr/share/doc/packages/cron/cron_to_cronie.README package cron 4.2 is only auxiliary package needed for proper renaming package cron to cronie usefull links : http://en.opensuse.org/Cron_replace http://en.opensuse.org/Cron_rename ============================================================== Neither of those two URLs are about the the issues this thread has been discussing. So if I remove the package cron its not going to make much difference? $ rpm -q --whatrequires cron cronie-1.4.8-50.1.2.x86_64 logrotate-3.8.7-4.8.1.x86_64 That's lame! Why should they depend on a README file? Of course some dependencies are circular $ rpm -q --whatrequires cronie cron-4.2-50.1.2.x86_64 And removing a README file causes a lot more to be removed as well $ rpm -q --whatrequires logrotate syslog-service-2.0-772.1.2.noarch mcelog-1.0pre3.6e4e2a000124-19.4.1.x86_64 xdm-1.1.11-126.1.x86_64 kdm-4.11.14-3.4.x86_64 All of which seems rather strange. But then I've grown used to the 'requirements' in openSuse being odd. -- /"\ \ / ASCII Ribbon Campaign X Against HTML Mail / \ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 11/22/2014 12:17 PM, jdd wrote:

Le 22/11/2014 18:13, Anton Aylward a écrit :

...

but the OP was the guy that got hit THUD! by these "only" things rendering his system unusable and asking us for help.

being the only time I see this for years, I doubt of the diagnostic. There must be something else

Well go back over the thread. The OP describes something happening every day at the same time. That tends to indicate its something regularly scheduled. What else but cron? We've looked at the cron.daily/ scripts and found some possible candidates: log rotation, nearly full disk, database backup ... As for the "there must be something else", I'm sure I'm not the only one who would be interested in alternatives. Do you have suggestions? Perhaps the OP should get back to us and tell us what he's found? -- /"\ \ / ASCII Ribbon Campaign X Against HTML Mail / \ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 11/22/2014 09:29 AM, Anton Aylward wrote:

On 11/22/2014 12:17 PM, jdd wrote:

...

Le 22/11/2014 18:13, Anton Aylward a écrit :

...

but the OP was the guy that got hit THUD! by these "only" things rendering his system unusable and asking us for help. being the only time I see this for years, I doubt of the diagnostic. There must be something else Well go back over the thread. The OP describes something happening every day at the same time. That tends to indicate its something regularly scheduled. What else but cron?

We've looked at the cron.daily/ scripts and found some possible candidates: log rotation, nearly full disk, database backup ...

As for the "there must be something else", I'm sure I'm not the only one who would be interested in alternatives. Do you have suggestions?

Perhaps the OP should get back to us and tell us what he's found?

I'm not OP, and I'm also a bit late to this thread, but I recall an annoying issue with updatedb causing balkiness not too long ago. It wasn't immediately obvious what was going on and I doubt if a non-technical user would have figured it out. Regards, Lew -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 11/22/2014 10:46 AM, Carlos E. R. wrote:

On 2014-11-22 19:34, Lew Wolfgang wrote:

...

I'm not OP, and I'm also a bit late to this thread, but I recall an annoying issue with updatedb causing balkiness not too long ago. It wasn't immediately obvious what was going on and I doubt if a non-technical user would have figured it out. It can easily happen. That's why the current cron job nices and ionices it.

/etc/cron.daily/mlocate.cron:

# alter the priority of the updatedb process if [ -x /usr/bin/renice ]; then /usr/bin/renice +${NICE:-19} -p $$ > /dev/null 2>&1 fi if [ -x /usr/bin/ionice ] && /usr/bin/ionice -c3 true 2>/dev/null; then /usr/bin/ionice -c${IONICE_CLASS:-2} -n${IONICE_PRIORITY:-7} -p $$ > /dev/null 2>&1 fi

You can go further and use class 3. Although I don't understand some of the constructs above.

I just edited /etc/sysconfig/cron so that "DAILY_TIME" ran at 03:00 instead of 15-minutes after booting. This was for an always-on desktop. Regards, Lew -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Anton Aylward wrote:

On 11/22/2014 10:25 AM, Linda Walsh wrote:

...

If you use 'crontabs', they run like the old cron. Only things put in /etc/cron.{timeperiod}, get run under the new method.

Yes, that's the point I and others are trying to make. It's all those "only" things that are so involved with system administration & maintenance that are there 'out of the box'. Of course us 'experts' ... but the OP was the guy that got hit THUD! by these "only" things rendering his system unusable and asking us for help.

But but but... you said: On Wed, 19 Nov 2014 22:38:34 -0500, Anton Aylward wrote:

Yes, that's the problem with this implementation. It BANG! BANG! BANG! BANG! one after the other.

You can't, as John asks, determine the time each specific one runs at. ^^^^---- ??? You can only set the time that cron.{daily,weekly,monthly} runs at, and that to 15 minute granularity.

You can't, as is possible with ...the real cron ... ^^^^^----???? run something "only on Monday" or "not on weekends" or "on the last Friday of the month".

You asserted that the exact scheduling wasn't available with the current cron that supports the anacron (batch) scheduling feature, but cronie supports both and AFAIK, it's the latest version of a cron to ship on openSuse systems (no?)

Do not assume that everyone else has our knowledge and experience; do not assume everyone has had the time to dig into how the system works.

I didn't assume -- I just looked at the manpage and saw it supported both. You asserted that the current cron didn't have this capability. I am seeing your statements as internally inconsistent.

There are may people here who don't have our knowledge and experience

--- nor the ability to both contradict one's self in the same discussion, yet not recognize it.

and that's why they ask here for our help and guidance.

Sorry, but I find the information you provided a bit confusing. I'm sure it was clear to you, but I'm just saying... (obligatory disclaimer: some people claim my descriptions are, at times, confusing, so I am not speaking from 'sainthood' ;-)) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 11/23/2014 04:03 AM, Linda Walsh wrote:

If you use 'crontabs', they run like the old cron. Only things put in /etc/cron.{timeperiod}, get run under the new method. .............

Hello List , my crontab looks like : # DO NOT EDIT THIS FILE - edit the master and reinstall. # (/tmp/crontab.8358 installed on Sun Jun 9 04:27:51 2002) # (Cron version -- $Id: crontab.c,v 2.13 1994/01/17 03:20:37 vixie Exp $) SHELL=/bin/sh # MAILTO=root@localhost MAILTO=root # 30 12 * * * exec /usr/bin/rkhunter --cronjob --update --rwo 45 12 * * * exec /root/thumb # 2 6 * * * exec /root/cronetc ..................... - How please should a new 'home-made' cron-job be formatted for entry into /etc/cron.daily - an example please ?? thanks regards -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2014-11-23 03:03, Linda Walsh wrote:

But but but... you said:

On Wed, 19 Nov 2014 22:38:34 -0500, Anton Aylward wrote:

...

Yes, that's the problem with this implementation. It BANG! BANG! BANG! BANG! one after the other.

...

You can't, as John asks, determine the time each specific one runs at. ^^^^---- ???

Certainly, you can not, unless you modify extensively how the system "periodic scripts" are inserted today. As it is now, they are all executed one after the other, as fast as possible, starting the group at a time you can select. That's how the system is setup today, and very similarly since way more than a decade. You can, of course, move the jobs out of ...daily, and create traditional cronjobs, and thus define the exact time for them to run. Or perhaps, if you know how, setup anacron entries instead. Of course you can do many things if you know how and have the time. But we are talking of how the system comes configured out of installation.

You asserted that the exact scheduling wasn't available with the current cron that supports the anacron (batch) scheduling feature, but cronie supports both and AFAIK, it's the latest version of a cron to ship on openSuse systems (no?)

No. He says that it is not available via the SuSE run-cron job.

...

Do not assume that everyone else has our knowledge and experience; do not assume everyone has had the time to dig into how the system works.

---

I didn't assume -- I just looked at the manpage and saw it supported both. You asserted that the current cron didn't have this capability. I am seeing your statements as internally inconsistent.

Because you are mixing paragraphs. To make use of anacron type entries you have to create, it seems, /etc/anacrontab: +++····················· Cron checks these files and directories: /etc/anacrontab system crontab, usually used to run daily, weekly, monthly jobs. See anacrontab(5) for more details. /etc/cron.d/ directory that contains system cronjobs stored for different users. /var/spool/cron directory that contains user crontables created by the crontab command. ·····················++- But there is no "man anacrontab". Although it is the first time, in years, that I even notice anacron being mentioned in the openSUSE man pages. So, again, it may be possible to do many things. But you need knowledge, expertise, and TIME, to set up the system differently than the way it comes. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

On 2014-11-23 12:29, jdd wrote:

Le 23/11/2014 12:19, Carlos E. R. a écrit :

...

But there is no "man anacrontab". Although it is the first time, in years, that I even notice anacron being mentioned in the openSUSE man pages.

may be have to be installed?

Ah, maybe.

for any reason, anacron, even being part of cronie is not installed by default (30ko :-))

I considered doing it some time ago and decided against. What I read did not convince me, at the time, that it was compatible or a good thing.

quoting yast:

cronie-anacron - Utility for running regular jobs

Anacron becames part of cronie. Anacron is used only for running regular jobs. The default settings execute regular jobs by anacron, however this could be overloaded in settings.

The wording is unclear. I don't get it, whether existing jobs switch over automatically to anacron, or not. I do not want them to switch, but I might consider creating my own new jobs anacron mode. That the suse devs did not move their own jobs to it, and keep using run-crons, is a consideration. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)