Re: cronitor.io for monitoring cron jobs
On Tue, Sep 12, 2023 at 00:54 Kushal Kumaran wrote: > On Mon, Sep 11 2023 at 05:59:37 AM, Tom Browder > wrote: > > Anyone using that system? It looks interesting to me. > > > I prefer healthchecks.io, mainly because cron job monitoring was all I > was looking for, and the software is open source. Thank you, Kushal. Best regards, -Tom
Re: cronitor.io for monitoring cron jobs
On Mon, Sep 11 2023 at 05:59:37 AM, Tom Browder wrote: > Anyone using that system? It looks interesting to me. > I prefer healthchecks.io, mainly because cron job monitoring was all I was looking for, and the software is open source. There is a comparison with cronitor at https://healthchecks.io/docs/healthchecks_cronitor_comparison/. That page only talks about cron job monitoring, though, and cronitor has other functionality as well. Source for healthchecks.io is at https://github.com/healthchecks/healthchecks, so you could potentially host it somewhere yourself. I like having that possibility, but at the moment, I'm just using the instances at healthchecks.io. -- regards, kushal
[outrageously off-topic] All those Thomas [was: cronitor.io for monitoring cron jobs]
On Mon, Sep 11, 2023 at 05:08:04PM +, Andrew M.A. Cater wrote: > On Mon, Sep 11, 2023 at 06:49:00PM +0200, to...@tuxteam.de wrote: > > On Mon, Sep 11, 2023 at 05:31:45PM +0200, Thomas Schmitt wrote: > > > Hi, > > > > > > to...@tuxteam.de wrote: > > > > and we're all twins [1] ;-) > > > > [1] https://en.wikipedia.org/wiki/Thomas_(name) > > > > > > But paradoxly less than half of all twins bear this very cool name. > > > > Which is a pity, ain't it ;-) > > > > Imagine the clerk at the civil registration office: > > > > Q: "But... but both your kids are called Thomas?" > > A: "Well, yes. They are twins!" > > > > Everyone's called Thomas? I doubt it ... > https://en.wikipedia.org/wiki/Doubting_Thomas ;-) > [In Wales, Thomas is quite a common family name - there are probably *lots* > of sets of twins surnamed Thomas :) ] In Germany, this isn't unheard of either. Interestingly, in Spain I haven't met any. Go figure. Cheers -- t signature.asc Description: PGP signature
Re: cronitor.io for monitoring cron jobs
On Mon, Sep 11, 2023 at 06:49:00PM +0200, to...@tuxteam.de wrote: > On Mon, Sep 11, 2023 at 05:31:45PM +0200, Thomas Schmitt wrote: > > Hi, > > > > to...@tuxteam.de wrote: > > > and we're all twins [1] ;-) > > > [1] https://en.wikipedia.org/wiki/Thomas_(name) > > > > But paradoxly less than half of all twins bear this very cool name. > > Which is a pity, ain't it ;-) > > Imagine the clerk at the civil registration office: > > Q: "But... but both your kids are called Thomas?" > A: "Well, yes. They are twins!" > Everyone's called Thomas? I doubt it ... https://en.wikipedia.org/wiki/Doubting_Thomas [In Wales, Thomas is quite a common family name - there are probably *lots* of sets of twins surnamed Thomas :) ] Andy > Cheers > -- > t
Re: cronitor.io for monitoring cron jobs
On Mon, Sep 11, 2023 at 05:31:45PM +0200, Thomas Schmitt wrote: > Hi, > > to...@tuxteam.de wrote: > > and we're all twins [1] ;-) > > [1] https://en.wikipedia.org/wiki/Thomas_(name) > > But paradoxly less than half of all twins bear this very cool name. Which is a pity, ain't it ;-) Imagine the clerk at the civil registration office: Q: "But... but both your kids are called Thomas?" A: "Well, yes. They are twins!" Cheers -- t signature.asc Description: PGP signature
Re: cronitor.io for monitoring cron jobs
Hi, to...@tuxteam.de wrote: > and we're all twins [1] ;-) > [1] https://en.wikipedia.org/wiki/Thomas_(name) But paradoxly less than half of all twins bear this very cool name. Have a nice day :) Thomas
Re: cronitor.io for monitoring cron jobs
On Mon, Sep 11, 2023 at 07:46:35AM -0500, Tom Browder wrote: [...] > > "Apt search monitor" and subsequent filtering with "web" yields half > > a dozen other interesting hits. > > > Thanks, Tomas, I was not savy enough to think of that! Glad to help :) > P.S. We share a good, Biblical name, don't we? and we're all twins [1] ;-) Cheers [1] https://en.wikipedia.org/wiki/Thomas_(name) -- t signature.asc Description: PGP signature
Re: cronitor.io for monitoring cron jobs
On Mon, Sep 11, 2023 at 07:25 wrote: > On Mon, Sep 11, 2023 at 06:46:43AM -0500, Tom Browder wrote: > > On Mon, Sep 11, 2023 at 06:22 wrote: > > > > > On Mon, Sep 11, 2023 at 05:59:37AM -0500, Tom Browder wrote: > > > > Anyone using that system? It looks interesting to me. > > > > > > Gah. My eyes hurt now after having looked at the web site. > > > > > > Do you recommend any other prebuilt system to automate such monitoring > and > > gathering of data and presenting it on a website? (Other than building > from > > scratch., yuk.) > > Not much experience myself, but icinga (packaged with Debian) comes > to mind (it can do much more, though). > > "Apt search monitor" and subsequent filtering with "web" yields half > a dozen other interesting hits. Thanks, Tomas, I was not savy enough to think of that! -Thomas P.S. We share a good, Biblical name, don't we?
Re: cronitor.io for monitoring cron jobs
On Mon, Sep 11, 2023 at 05:59:37AM -0500, Tom Browder wrote: > Anyone using that system? It looks interesting to me. Gah. My eyes hurt now after having looked at the web site. Besides, it looks a bit like a bait-and-switch SaSS. No, I wouldn't use it. Cheers -- t signature.asc Description: PGP signature
cronitor.io for monitoring cron jobs
Anyone using that system? It looks interesting to me. -Tom
Re: Cron Jobs and Time Zones Has Anything Changed?
On Du, 06 dec 20, 12:23:43, Martin McCormick wrote: > > An on-going problem about self-education is that it's > easy to limit the scope so much that we miss connections. > Systemd timers doesn't even sound like a replacement for cron but > think of it as cron on steroids. It is also a replacement for at, not just cron. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser signature.asc Description: PGP signature
Re: Cron Jobs and Time Zones Has Anything Changed?
Andrei POPESCU writes: > On Jo, 03 dec 20, 07:39:14, Martin McCormick wrote: > > > > So, I need to read more general information about the > > differences between systemd and what we've been using up to > > recently. > > The Wikipedia page and/or https://systemd.io might be a good place to > start. > > Kind regards, > Andrei I've had a chance to investigate this more and the first thing I did was to go to wikipedia which told me about systemd, the on-going argument about it VS older ways to build unix-like systems and a time line when systemd began to take hold which was around 2015 when I retired from work so it kind of sneaked up on me and I didn't realize that I've been using it for 5 years, well, at least I didn't think much about systemd having different resources. I've used udev rules in making sound cards come up in the right order and that's totally a systemd thing. While searching for ways to use cron with different time zones, I found out about something called systemd timers just mentioned in this thread and it appears they definitely will do the job but one must magically have made the connection between this concept and the concept that cron, the usual go to resource for making lighting come on at a certain time, purging stale files or backing up the system now has a new kid on the block called systemd timers. One can even list all the active systemd timers https://www.maketecheasier.com/use-systemd-timers-as-cron-replacement/ $ systemctl list-timers And, sure enough, I had a number of them ticking away. An on-going problem about self-education is that it's easy to limit the scope so much that we miss connections. Systemd timers doesn't even sound like a replacement for cron but think of it as cron on steroids. One of the things in the wikipedia article about systemd was a complaint by someone that it's just too complicated. All I can say is that maybe or not that is true but that's just life. Start simple. Make more and more complexity as problems with simple show up. One day, try to make things simple again. Lot's of luck with that. I'm not so sure that being blind makes nearly as much difference these days as it once did, but making connections that relate one knowledge base to another in a meaningful way will always be a problem for us. Martin
Re: Cron Jobs and Time Zones Has Anything Changed?
On Jo, 03 dec 20, 07:39:14, Martin McCormick wrote: > > So, I need to read more general information about the > differences between systemd and what we've been using up to > recently. The Wikipedia page and/or https://systemd.io might be a good place to start. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser signature.asc Description: PGP signature
Re: Cron Jobs and Time Zones Has Anything Changed?
Hi David, On Fri, Dec 04, 2020 at 01:32:35PM +1100, David wrote: > On Fri, 4 Dec 2020 at 13:10, Andy Smith wrote: > > So much text written without clear statement of problem! > > I understand why you wrote that, but you might be unaware that > Martin has previously mentioned on this list that he is blind. Does that stop him writing exactly what he wants to achieve, what he's tried and where that failed? He can clearly write a lot, just not the things that move the situation forward, it seems. Let's get a problem, and help Martin fix it - what this list is for. Otherwise, personal blogs are a thing. Cheers, Andy
Re: Cron Jobs and Time Zones Has Anything Changed?
On Fri, 4 Dec 2020 at 13:10, Andy Smith wrote: [...] > I am surprised that just looking up documentation > on systemd timers doesn't answer that question for you. [...] > So much text written without clear statement of problem! I understand why you wrote that, but you might be unaware that Martin has previously mentioned on this list that he is blind. So if he doesn't find it as easy as I do to discover information, or if he feels like writing a long message, then I'm cool with that, because I'm in awe of what he can do.
Re: Cron Jobs and Time Zones Has Anything Changed?
Hello, On Thu, Dec 03, 2020 at 07:39:14AM -0600, Martin McCormick wrote: > I am guilty as charged but haven't yet found the relevant information > as to how systemd helps solve this issue. You can put a time zone in a systemd timer. I can't see how it can be stated any simpler than that. If you want to ask the question, "How do I make a systemd timer that runs a command at a given time in a given time zone?" just ask that question! Though I am surprised that just looking up documentation on systemd timers doesn't answer that question for you. If that is not your question, well, what is your question? So much text written without clear statement of problem! Sort of ironic that this started with asking why there are 3.5MiB of files in /usr/share/zoneinfo/ - has more than 3.5N of data been created yet between these couple of threads? Cheers, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting
Re: Cron Jobs and Time Zones Has Anything Changed?
Martin McCormick writes: > I record a news broadcast from one of the BBC services > every week day at 17:45 British time. When Europe and North > America stop or start shifting daylight in Autumn or Spring, > there's a really good chance of missing some of the broadcasts if > one doesn't think about it since these shifts don't all happen on > the same time. Maybe you could create ~/.config/cron/bcast.vixie: 45 17 * * mon-fri echo hello or whatever command you want And install mcron, then run: TZ=Europe/London mcron --daemon -- Fabrice BAUZAC-STEHLY PGP 015AE9B25DCB0511D200A75DE5674DEA514C891D
Re: Cron Jobs and Time Zones Has Anything Changed?
> On Wed, Dec 02, 2020 at 01:58:45PM +, James B wrote: > > This might be wrong, but as far as I understand doesn't systemd > > now have the ability to manage cron jobs (as well as mount points, > > home folders and other things)?. Is there anything in this newer > > functionality that might make such a thing (re the request at the > > beginning of this thread) possible? > > Yes, I pointed this out to OP last time OP asked this exact question just a few days ago, so I don't know why they are asking again. I am guilty as charged but haven't yet found the relevant information as to how systemd helps solve this issue. Systemd is praised to the rooftops by some and cursed just as vehemently by others and it is what we are now using but it feels mostly like unix has always felt. I am obviously suffering from the worst sort of ignorance syndrome which can really bite in that sometimes, we have an idea what we don't know and other times, we don't even know that we don't know and that's really frightening. So, I need to read more general information about the differences between systemd and what we've been using up to recently. Martin McCormick
Re: Cron Jobs and Time Zones Has Anything Changed?
On Wed, Dec 02, 2020 at 01:17:02PM -0500, Dan Ritter wrote:
> As a name for the utility, I suggest "do-if-time-in" and require
> three parameters:
>
> do-if-time-in timezone time "command"
>
> As an interim fix, though: (and I know Greg's going to fix this)
>
> ---
> #!/bin/bash
> TZ=$1
> NOW=$(date +%H%M)
> echo $NOW
> if [ "$2" = "$NOW" ] ;
> then echo $("$3")
> fi
> ---
There are two natural designs for a utility like this. The first would
take three inputs (time zone, start time, end time), and return an exit
status that says whether the current time is within the interval.
The second design would take those same inputs, plus a command to execute
if and only if the current time is within the interval. For that design,
you'd use chain-loading (exec).
In either case, you don't need to pass the time zone as a parameter. You
can just use the TZ environment variable.
The real problem is how you specify the start and end times. In your
sample code, the result of the date command is HHMM format, so your
parameters would have to be given that way as well. HHMM may not be
the more useful format, especially since it doesn't give you a way to
specify a date.
For the purposes of this email, as an exercise, let's say we decide
to specify the start and end times in HH:MM format, and skip the whole
notion of specifying a date. That makes it reasonably easy to
implement.
---
#!/bin/bash
usage() {
echo "usage: $0 starttime endtime command [args]"
echo "starttime and endtime must be in HH:MM format"
}
if (($# < 3)); then
usage >&2
exit 1
fi
start=$1 end=$2
shift 2
if [[ $start != [0-9][0-9]:[0-9][0-9] || $end != [0-9][0-9]:[0-9][0-9] ]]; then
usage >&2
exit 1
fi
printf -v now '%(%H:%M)T' -1
if [[ $now >= $start && $now <= $end ]]; then
exec "$@"
fi
---
I didn't do anything with TZ because it's not *necessary*. If it's
given as an environment variable, it'll take hold automatically. If
it's not given, then the system's default time zone will be used.
Re: Cron Jobs and Time Zones Has Anything Changed?
Martin McCormick wrote:
> Greg Wooledge writes:
> > I was vaguely thinking of a similar approach. Set up a job that runs
> > every hour, or across a set of hours that will cover all the possible
> > cases that you care about, in your crontab. Within the job itself,
> > set a TZ variable and determine the time in that time zone by whatever
> > means necessary, and then either abort or continue based on that time.
This approach:
- does not replace crond, and so does not screw up upgrades to
the next version of Debian
- is a small, useful utility which could be adopted rapidly and
later packaged for Debian
- can be ignored by people who don't need it.
> Crontab would have a new field at the beginning of each
> line which could normally be left at "default" which would be the
> normal behavior that we are used to.
This approach requires one of:
- convince the upstream maintainer of cron to adopt it
- convince the Debian maintainer of cron to adopt it as a patch
that gets applied and potentially broken/fixed on each release
- creates a new cron package in competition with the existing
one
- creates a local cron package that has to be maintained along
with upstream changes
The third approach would be to build cronie for Debian, which is
probably do-able but is nevertheless a competitor for cron and
faces similar issues.
> I haven't looked at the C code for cron, but I have
> written a few perl scripts that do things with time and dates and
> the current epoch-based number of seconds since utc Midnight January
> 1, 1970 is based on the C modules such that one's current
> wall-clock time is time(localtime). Just a thought
Perl is definitely an appropriate language for a utility
like this.
libdatetime-timezone-perl
libtime-parsedate-perl
libdatetimex-easy-perl
are all extremely common installs.
As a name for the utility, I suggest "do-if-time-in" and require
three parameters:
do-if-time-in timezone time "command"
As an interim fix, though: (and I know Greg's going to fix this)
---
#!/bin/bash
TZ=$1
NOW=$(date +%H%M)
echo $NOW
if [ "$2" = "$NOW" ] ;
then echo $("$3")
fi
---
-dsr-
Re: Cron Jobs and Time Zones Has Anything Changed?
Greg Wooledge writes: > I was vaguely thinking of a similar approach. Set up a job that runs > every hour, or across a set of hours that will cover all the possible > cases that you care about, in your crontab. Within the job itself, > set a TZ variable and determine the time in that time zone by whatever > means necessary, and then either abort or continue based on that time. > > This is also similar to how one approaches a complex date-based task > such as "run on the second-to-last day of each month". For that one, > you can set up the job to run on the 27th through the 30th every > month. Then within the job itself, determine whether it's the > correct day, and abort if it's not. What I was thinking of is a modification to cron which should integrate nicely with what cron already does. Crontab would have a new field at the beginning of each line which could normally be left at "default" which would be the normal behavior that we are used to. If someone wanted to run a job at 15:00 each day in let's say Japanese time, the first field of the line would read Asia/Tokyo instead of default. The line might look like Asia/Tokyo 28 15 * * 1-5 sh -c ". $HOME/.master.env;beep -f700 -l500" Since all unix-like systems start out with UTC and use those /usr/share/zoneinfo data base files to calculate what local time is, that information is handy in the time() function. localtime(time) gets you the adjusted number of seconds for your locale arranged in a structure containing fields for the current year, day of month, day of the week plus the hours, minutes and seconds with the adjustment for Summer or Winter for that zone. The sample line above would cause cron to grab the current epoch in seconds (UTC), feed that to localtimebased on rules for /usr/share/zoneinfo/Asia/Tokyo and then all those values to match the fields on the rest of the line. The time of 15:28 or 3:28 PM in Tokyo occurs around 01:28 in the Central US time zone and that's when your computer would have beeped. This would happen Monday through Friday Japanese time which still would be Monday through Friday in the US but early in the morning. If the time referenced in Tokyo had been 7:00 in the morning , it would happen the previous evening in the US. As long as one designated the time zone correctly and doesn't forget that 07:00 on Monday morning in Japan equals 5 or 6 o/clock on the evening of the previous day, it should just work. I haven't looked at the C code for cron, but I have written a few perl scripts that do things with time and dates and the current epoch-based number of seconds since utc Midnight January 1, 1970 is based on the C modules such that one's current wall-clock time is time(localtime). Just a thought Martin
Re: Cron Jobs and Time Zones Has Anything Changed?
Apols..I hadn't read the original post, just saw this one from today! -- James B portoteache...@fastmail.com Em Qua, 2 Dez ʼ20, às 16:26, Andy Smith escreveu: > Hello, > > On Wed, Dec 02, 2020 at 01:58:45PM +, James B wrote: > > This might be wrong, but as far as I understand doesn't systemd > > now have the ability to manage cron jobs (as well as mount points, > > home folders and other things)?. Is there anything in this newer > > functionality that might make such a thing (re the request at the > > beginning of this thread) possible? > > Yes, I pointed this out to OP last time OP asked this exact question > just a few days ago, so I don't know why they are asking again. > Nothing has changed in the last couple of days to give crond TZ > support! > > Cheers, > Andy > > -- > https://bitfolk.com/ -- No-nonsense VPS hosting > >
Re: Cron Jobs and Time Zones Has Anything Changed?
Hello, On Wed, Dec 02, 2020 at 01:58:45PM +, James B wrote: > This might be wrong, but as far as I understand doesn't systemd > now have the ability to manage cron jobs (as well as mount points, > home folders and other things)?. Is there anything in this newer > functionality that might make such a thing (re the request at the > beginning of this thread) possible? Yes, I pointed this out to OP last time OP asked this exact question just a few days ago, so I don't know why they are asking again. Nothing has changed in the last couple of days to give crond TZ support! Cheers, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting
Re: Cron Jobs and Time Zones Has Anything Changed?
On Wed, Dec 02, 2020 at 08:53:28AM -0500, Dan Ritter wrote: > It would not be ridiculous to run a wrapper program out of, e.g. > cron.hourly, which used an explicitly set TZ as a cue to run > another job. I was vaguely thinking of a similar approach. Set up a job that runs every hour, or across a set of hours that will cover all the possible cases that you care about, in your crontab. Within the job itself, set a TZ variable and determine the time in that time zone by whatever means necessary, and then either abort or continue based on that time. This is also similar to how one approaches a complex date-based task such as "run on the second-to-last day of each month". For that one, you can set up the job to run on the 27th through the 30th every month. Then within the job itself, determine whether it's the correct day, and abort if it's not.
Re: Cron Jobs and Time Zones Has Anything Changed?
On 02/12/2020 10:30, Martin McCormick wrote: > In a recent discussion, someone indicated that there might be a > way to set individual parts such as accounts on a unix system so > that cron could use another time zone if needed to kickoff jobs > on that system based on the time in another country. > > As far as I understand cron, one can set the system's > time zone to only one value which is usually one's local clock > time and that works very well since system logs and cron jobs all > agree with what is appropriate for one's location. > > I record a news broadcast from one of the BBC services > every week day at 17:45 British time. When Europe and North > America stop or start shifting daylight in Autumn or Spring, > there's a really good chance of missing some of the broadcasts if > one doesn't think about it since these shifts don't all happen on > the same time. > > One can certainly get the time anywhere as recently > discussed by setting the TZ environment variable but, if you tell > cron to trigger a job at 17:45, it only knows when that is based > on the entire system's local time. > > Has anything changed recently to make this logic > obsolete? > > In my case, I just have an old Linux box for which I set > it's system time zone to Europe/London and call it good but this > could get out of hand if one had more than 2 or 3 such schedules. > > One could also setup VM's if you have the memory to spare > but this adds a lot of resource usage and complexity to the job > at hand so my question is basically, has anything fundamentally > changed in the way cron is used? > > This is not a complaint at all. I was first introduced to > unix-like systems in 1989 and immediately knew that this was the > sort of OS I wanted to stick with in amateur radio and technical > tinkering in general. > > Martin McCormick WB5AGZ > systemd timers seem to allow specification of activation time including a time zone. However, I'm not sure if DST changes are considered - it might just convert the specified time to the local time zone when the timer definition is read so that you can specify '17:45 GMT' and it runs at, say, your 10:45, but it won't automatically pick up that 17:45 GMT is not 11:45 local. I might be wrong, though. -- To do nothing is to be nothing. Eduardo M KALINOWSKI edua...@kalinowski.com.br
Re: Cron Jobs and Time Zones Has Anything Changed?
This might be wrong, but as far as I understand doesn't systemd now have the ability to manage cron jobs (as well as mount points, home folders and other things)?. Is there anything in this newer functionality that might make such a thing (re the request at the beginning of this thread) possible? I'm currently learning how to manage these things with systemd rather than crontab and mount but still not quite up to speed with it, so may be overestimating the possiblities available. -- James B portoteache...@fastmail.com Em Qua, 2 Dez ʼ20, às 13:53, Dan Ritter escreveu: > Greg Wooledge wrote: > > On Wed, Dec 02, 2020 at 07:30:22AM -0600, Martin McCormick wrote: > > > In a recent discussion, someone indicated that there might be a > > > way to set individual parts such as accounts on a unix system so > > > that cron could use another time zone if needed to kickoff jobs > > > on that system based on the time in another country. > > > > It would not be ridiculous to run a wrapper program out of, e.g. > cron.hourly, which used an explicitly set TZ as a cue to run > another job. > > Interestingly, Red Hat and Ubuntu use cronie instead of Vixie's > cron, and cronie supports a per-crontab CRON_TZ variable. cronie > is not in Debian, but it could very likely be packaged easily. > > -dsr- > >
Re: Cron Jobs and Time Zones Has Anything Changed?
Greg Wooledge wrote: > On Wed, Dec 02, 2020 at 07:30:22AM -0600, Martin McCormick wrote: > > In a recent discussion, someone indicated that there might be a > > way to set individual parts such as accounts on a unix system so > > that cron could use another time zone if needed to kickoff jobs > > on that system based on the time in another country. > It would not be ridiculous to run a wrapper program out of, e.g. cron.hourly, which used an explicitly set TZ as a cue to run another job. Interestingly, Red Hat and Ubuntu use cronie instead of Vixie's cron, and cronie supports a per-crontab CRON_TZ variable. cronie is not in Debian, but it could very likely be packaged easily. -dsr-
Re: Cron Jobs and Time Zones Has Anything Changed?
On Wed, Dec 02, 2020 at 07:30:22AM -0600, Martin McCormick wrote: > In a recent discussion, someone indicated that there might be a > way to set individual parts such as accounts on a unix system so > that cron could use another time zone if needed to kickoff jobs > on that system based on the time in another country. crontab(5) LIMITATIONS The cron daemon runs with a defined timezone. It currently does not support per-user timezones. All the tasks: system's and user's will be run based on the configured timezone. Even if a user specifies the TZ environment variable in his crontab this will affect only the commands executed in the crontab, not the execution of the crontab tasks them‐ selves.
Cron Jobs and Time Zones Has Anything Changed?
In a recent discussion, someone indicated that there might be a way to set individual parts such as accounts on a unix system so that cron could use another time zone if needed to kickoff jobs on that system based on the time in another country. As far as I understand cron, one can set the system's time zone to only one value which is usually one's local clock time and that works very well since system logs and cron jobs all agree with what is appropriate for one's location. I record a news broadcast from one of the BBC services every week day at 17:45 British time. When Europe and North America stop or start shifting daylight in Autumn or Spring, there's a really good chance of missing some of the broadcasts if one doesn't think about it since these shifts don't all happen on the same time. One can certainly get the time anywhere as recently discussed by setting the TZ environment variable but, if you tell cron to trigger a job at 17:45, it only knows when that is based on the entire system's local time. Has anything changed recently to make this logic obsolete? In my case, I just have an old Linux box for which I set it's system time zone to Europe/London and call it good but this could get out of hand if one had more than 2 or 3 such schedules. One could also setup VM's if you have the memory to spare but this adds a lot of resource usage and complexity to the job at hand so my question is basically, has anything fundamentally changed in the way cron is used? This is not a complaint at all. I was first introduced to unix-like systems in 1989 and immediately knew that this was the sort of OS I wanted to stick with in amateur radio and technical tinkering in general. Martin McCormick WB5AGZ
Re: systemd+anacron breaks cron jobs
On 12/5/18, Kamil Jońca wrote: > Cindy-Sue Causey writes: > >> On 12/5/18, Kamil Jońca wrote: >>> Michael Biebl writes: >>> My general remark that anacron is typically not needed anymore, still stands though (even if it doesn't apply for your specific use case). >>> >>> What is other tool to make USER automated, cyclic tasks? >> >> >> I learned of "apt-cache search" a LONG time ago. One of my Top 5 tools >> I use A LOT every week. What I did this time was first run "apt-cache >> show anacron" because that was in the subject line. That shared >> "command scheduler" as an early part of the description so I ran with >> that keyword phrase: >> >> +++ BEGIN OUTPUT +++ >> >> $ apt-cache search command scheduler >> anacron - cron-like program that doesn't go by time >> kalarm - alarm message, command and email scheduler >> libnet-openssh-parallel-perl - run SSH jobs in parallel >> python-axiom - Python object database >> task-spooler - personal job scheduler >> >> +++ END OUTPUT +++ >> >> Not much but does serve as an example. Kalarm... I think I tried that > > Ekhem. kalarm is kde dependent. Whole discussion is about tool which do > not depend on user login ... > The rest of result is not worth comenting on ... Sorry about that. I didn't catch that part (I skipped 17 emails and only read the last one, oops!), but I do fully understand. I just tried a Kalarm install. It wants to bring about 35MB of other things in along with. I don't remember non-cron alarm-clock-applet being that hefty, but it's possible that it would be for someone else depending on what's already installed on their own setup. > Yes, I did not search extensively. When (ana)cron exist and they fill my > needs, why should I waste my time? > Recently systemd aggressively try to take more and more jobs, but it is > not quite ready for one-to-one replacement of those[1]. > > KJ > > > [1] I am quite happy using systemd as init replacement, but why these folks > want to put there timer, dhcp-client and so on? You never know. As things progress, maybe your chatter will inspire someone who's looking for a nice tech class project or something. I see requests for ideas like that on regular occasion across various lists. PS Now that I say that, I see tech posts all the time that are consistently too timely to the topics brought up here. It's good stuff. *waving at those folks > I SEE YOU PEEKING!* :D Cindy :) -- Cindy-Sue Causey Talking Rock, Pickens County, Georgia, USA * runs with birdseed *
Re: systemd+anacron breaks cron jobs
Cindy-Sue Causey writes: > On 12/5/18, Kamil Jońca wrote: >> Michael Biebl writes: >> >>> >>> My general remark that anacron is typically not needed anymore, still >>> stands though (even if it doesn't apply for your specific use case). >> >> What is other tool to make USER automated, cyclic tasks? > > > I learned of "apt-cache search" a LONG time ago. One of my Top 5 tools > I use A LOT every week. What I did this time was first run "apt-cache > show anacron" because that was in the subject line. That shared > "command scheduler" as an early part of the description so I ran with > that keyword phrase: > > +++ BEGIN OUTPUT +++ > > $ apt-cache search command scheduler > anacron - cron-like program that doesn't go by time > kalarm - alarm message, command and email scheduler > libnet-openssh-parallel-perl - run SSH jobs in parallel > python-axiom - Python object database > task-spooler - personal job scheduler > > +++ END OUTPUT +++ > > Not much but does serve as an example. Kalarm... I think I tried that Ekhem. kalarm is kde dependent. Whole discussion is about tool which do not depend on user login ... The rest of result is not worth comenting on ... Yes, I did not search extensively. When (ana)cron exist and they fill my needs, why should I waste my time? Recently systemd aggressively try to take more and more jobs, but it is not quite ready for one-to-one replacement of those[1]. KJ [1] I am quite happy using systemd as init replacement, but why these folks want to put there timer, dhcp-client and so on? -- http://wolnelektury.pl/wesprzyj/teraz/ Normal times may possibly be over forever.
Re: systemd+anacron breaks cron jobs
On 12/5/18, Kamil Jońca wrote: > Michael Biebl writes: > >> >> My general remark that anacron is typically not needed anymore, still >> stands though (even if it doesn't apply for your specific use case). > > What is other tool to make USER automated, cyclic tasks? I learned of "apt-cache search" a LONG time ago. One of my Top 5 tools I use A LOT every week. What I did this time was first run "apt-cache show anacron" because that was in the subject line. That shared "command scheduler" as an early part of the description so I ran with that keyword phrase: +++ BEGIN OUTPUT +++ $ apt-cache search command scheduler anacron - cron-like program that doesn't go by time kalarm - alarm message, command and email scheduler libnet-openssh-parallel-perl - run SSH jobs in parallel python-axiom - Python object database task-spooler - personal job scheduler +++ END OUTPUT +++ Not much but does serve as an example. Kalarm... I think I tried that as an alarm (then went with alarm-clock-apple instead = LOVE!). I'm going to go back and look at Kalarm with this thread in mind. I've seen "cron job" tossed all around but never had enough brain cells functioning at the same time to actually pursue finding an excuse to test drive the concept. True story is that cron jobs always sounded almost too... "daunting". Kalarm pulling up in this mix, including via its "apt-cache show" description, just helped throw that #fakeNews impression out the window. #ThankYou! Maybe you could try a different, creative combination of other keywords' "apt-cache search" that you know should work with respect to anacron. That might lead to more possibilities than what pulled up above. Cindy :) -- Cindy-Sue Causey Talking Rock, Pickens County, Georgia, USA * runs with birdseed *
Re: systemd+anacron breaks cron jobs
Michael Biebl writes: > > My general remark that anacron is typically not needed anymore, still > stands though (even if it doesn't apply for your specific use case). What is other tool to make USER automated, cyclic tasks? KJ -- http://stopstopnop.pl/stop_stopnop.pl_o_nas.html We totally deny the allegations, and we're trying to identify the allegators.
Re: systemd+anacron breaks cron jobs
Am 05.12.18 um 11:35 schrieb Kamil Jońca: > So I cannot drop (ana)cron :) EOT With your specific set of requirements, you are most likely best served by cron (and anacron if your system is not continuously running). I still don't understand why you need to start your backup task as user service and during boot instead of just making it a system service, but that's ok. It's ultimately your decision. My general remark that anacron is typically not needed anymore, still stands though (even if it doesn't apply for your specific use case). Regards, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: systemd+anacron breaks cron jobs
Michael Biebl writes: > Am 05.12.18 um 11:04 schrieb Kamil Jońca: > >> But 'enable-linger' starts my ALL services, which is not what I want. >> I want to start only timers. > > Since you can only have one systemd --user instance, this is not possible. > You can't have a systemd --user instance which is started during boot > with only timers.target and a second systemd --user instance which is > started on first login with default.target. So I cannot drop (ana)cron :) EOT KJ -- http://stopstopnop.pl/stop_stopnop.pl_o_nas.html According to the obituary notices, a mean and unimportant person never dies.
Re: systemd+anacron breaks cron jobs
Am 05.12.18 um 11:04 schrieb Kamil Jońca: > But 'enable-linger' starts my ALL services, which is not what I want. > I want to start only timers. Since you can only have one systemd --user instance, this is not possible. You can't have a systemd --user instance which is started during boot with only timers.target and a second systemd --user instance which is started on first login with default.target. Regards, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: systemd+anacron breaks cron jobs
Michael Biebl writes: [...] > >> 2. start timers irrespective of graphical login. > > If you want them to be started during boot, use enable-linger But 'enable-linger' starts my ALL services, which is not what I want. I want to start only timers. KJ -- http://wolnelektury.pl/wesprzyj/teraz/ And the silence came surging softly backwards When the plunging hooves were gone... -- Walter de La Mare, "The Listeners"
Re: systemd+anacron breaks cron jobs
Am 05.12.18 um 10:49 schrieb Michael Biebl: > Am 05.12.18 um 10:47 schrieb Kamil Jońca: >> How can I: >> 1. start services only with graphical login and > > You can't. At least not yet. Use ~/.config/autostart Some work has already been done to support graphical-session.target https://www.freedesktop.org/software/systemd/man/systemd.special.html#graphical-session.target We are not there yet, though. A bit more dated is this video from systemd.conf https://www.youtube.com/watch?v=hq18daxTkLA Regards, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: systemd+anacron breaks cron jobs
Am 05.12.18 um 10:47 schrieb Kamil Jońca: > Michael Biebl writes: > >> Am 05.12.18 um 10:04 schrieb Kamil Jońca: >>> Michael Biebl writes: >> > which in turn, can break ALL your "user" units) I'd be interested to know, what exactly you have in mind here. I'm not aware of such a breakage. >>> >>> For example: I have (--user) >>> kj-keepassx.service - my own service with keepasx >>> xscreensaver-monitor.service - my own service which to monitor screensaver >>> >>> These services should NOT be run withoud graphical login. >> >> If those services are tied to a X login session, they should not be >> started via systemd --user (at least, not yet) >> >> Let me go into a bit more detail. >> >> >> There is only ever *one* systemd --user instance per user. It is >> typically started, the first time you log in and stopped, once there is >> no more active login session for a particular user. >> > [...snip...] > I knew all you wrote. > So I my question still is: > > How can I: > 1. start services only with graphical login and You can't. At least not yet. Use ~/.config/autostart This is what I trying to explain. > 2. start timers irrespective of graphical login. If you want them to be started during boot, use enable-linger -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: systemd+anacron breaks cron jobs
Michael Biebl writes: > Am 05.12.18 um 10:04 schrieb Kamil Jońca: >> Michael Biebl writes: > which in turn, can break ALL your "user" units) >>> >>> I'd be interested to know, what exactly you have in mind here. I'm not >>> aware of such a breakage. >> >> For example: I have (--user) >> kj-keepassx.service - my own service with keepasx >> xscreensaver-monitor.service - my own service which to monitor screensaver >> >> These services should NOT be run withoud graphical login. > > If those services are tied to a X login session, they should not be > started via systemd --user (at least, not yet) > > Let me go into a bit more detail. > > > There is only ever *one* systemd --user instance per user. It is > typically started, the first time you log in and stopped, once there is > no more active login session for a particular user. > [...snip...] I knew all you wrote. So I my question still is: How can I: 1. start services only with graphical login and 2. start timers irrespective of graphical login. KJ -- http://stopstopnop.pl/stop_stopnop.pl_o_nas.html It's a .88 magnum -- it goes through schools. -- Danny Vermin
Re: systemd+anacron breaks cron jobs
Am 05.12.18 um 10:04 schrieb Kamil Jońca: > Michael Biebl writes: >>> which in turn, can break ALL your "user" units) >> >> I'd be interested to know, what exactly you have in mind here. I'm not >> aware of such a breakage. > > For example: I have (--user) > kj-keepassx.service - my own service with keepasx > xscreensaver-monitor.service - my own service which to monitor screensaver > > These services should NOT be run withoud graphical login. If those services are tied to a X login session, they should not be started via systemd --user (at least, not yet) Let me go into a bit more detail. There is only ever *one* systemd --user instance per user. It is typically started, the first time you log in and stopped, once there is no more active login session for a particular user. If you have multiple active login sessions (say X, and one console login on tty2), you still have only one systemd --user instance. If you now logout from X, the systemd --user instance is not stopped, only if you also logout from tty2. I hope, you can now see that your kj-keepassx.service is not going to work. What you really want, is to start that service as part of a X login session. Those are traditionally handled via /etc/xdg/autostart and ~/.config/autostart There are attempts to provide such a XDG autostart equivalent facility in systemd, by providing a target, which becomes active once a X session starts and becomes inactive, once the X session ends. User units which are supposed to be tied to X sessions can then bind to that target. See https://blogs.gnome.org/laney/2018/06/26/starting-sessions-with-systemd/ if you want to read a bit more about it. For the time being, starting a service via a systemd user service which is bound to the life-time of an X session, is not really supported and I would recommend you use ~/.config/autostart for it instead. Regards, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: systemd+anacron breaks cron jobs
Michael Biebl writes: > Am 05.12.18 um 08:54 schrieb Kamil Jońca: >> "User" task aren't started until user logs in. (You should play with >> enable-linger, > > I haven't read the full discussion, so I missed the part that you are > apparently using a user crontab. To clarify things: 1. In original post I described system task which CAN (and sooner or later will) be migrated to systemd timers. But then You said that: 2. anacron can be dropped - which in general is not true, because systemd cannot provided proper functionality for user units. > It's correct, that "systemd --user" is started if you log in, or if you > explicitly enable linger for this user (then it is started during boot). > > >> which in turn, can break ALL your "user" units) > > I'd be interested to know, what exactly you have in mind here. I'm not > aware of such a breakage. For example: I have (--user) kj-keepassx.service - my own service with keepasx xscreensaver-monitor.service - my own service which to monitor screensaver These services should NOT be run withoud graphical login. But I would run my user timers. How to achieve this? with cron/anacron I simply put line in my (ana)crontab. KJ -- http://wolnelektury.pl/wesprzyj/teraz/ Classical music is the kind we keep thinking will turn into a tune. -- Kin Hubbard, "Abe Martin's Sayings"
Re: systemd+anacron breaks cron jobs
Am 05.12.18 um 08:54 schrieb Kamil Jońca: > "User" task aren't started until user logs in. (You should play with > enable-linger, I haven't read the full discussion, so I missed the part that you are apparently using a user crontab. Just curious: Why are you starting the backup task via a user crontab and not as a system cron job? Are you only saving the users /home/ directory? It's correct, that "systemd --user" is started if you log in, or if you explicitly enable linger for this user (then it is started during boot). > which in turn, can break ALL your "user" units) I'd be interested to know, what exactly you have in mind here. I'm not aware of such a breakage. Regards, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: systemd+anacron breaks cron jobs
Michael Biebl writes: > Am 05.12.18 um 07:41 schrieb Michael Biebl: >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=864213#25 >> If you drop /lib/udev/rules.d/60-anacron.rules my bet is that the >> problem is gone. > > Btw, I'd go as far and say that you can safely drop anacron these days. This is only true for "system" tasks. "User" task aren't started until user logs in. (You should play with enable-linger, which in turn, can break ALL your "user" units) This thing stop me from migrating. KJ -- http://stopstopnop.pl/stop_stopnop.pl_o_nas.html Uwolnić słonia !!!
Re: systemd+anacron breaks cron jobs
Am 05.12.18 um 07:41 schrieb Michael Biebl: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=864213#25 > If you drop /lib/udev/rules.d/60-anacron.rules my bet is that the > problem is gone. Btw, I'd go as far and say that you can safely drop anacron these days. A lot of Debian packages which ship a cron job also ship a native systemd .timer. Such persistent timers handle systems which don't run 24/7 in a much better way. In your case, I would recommend to use a .timer to start your backup task. The arch wiki [2] is a good start, or simply take a look at existing timers on your system: systemctl cat logrotate.service logrotate.timer Regards, Michael [1] https://www.freedesktop.org/software/systemd/man/systemd.timer.html#Persistent= [2] https://wiki.archlinux.org/index.php/Systemd/Timers -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: systemd+anacron breaks cron jobs
Michael Biebl writes: [...] > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=864213#25 > If you drop /lib/udev/rules.d/60-anacron.rules my bet is that the > problem is gone. kjonca@alfa:~%ls /lib/udev/rules.d/60-anacron.rules ls: cannot access '/lib/udev/rules.d/60-anacron.rules': No such file or directory So what? KJ -- http://stopstopnop.pl/stop_stopnop.pl_o_nas.html You can't hug a child with nuclear arms.
Re: systemd+anacron breaks cron jobs
> On Mon, 03 Dec 2018, Kamil Jońca wrote: >> >> Dec 03 00:23:54 alfa systemd[1]: anacron.service: State 'stop-sigterm' >> >> timed out. Killing. >> > See, someone or some script told systemd to stop anacron (or maybe to >> > stop-and-start/restart it). THIS is causing the undesired behavior. >> >> Dec 03 00:22:24 alfa systemd[1]: Stopping Run anacron jobs... >> Dec 03 00:22:24 alfa anacron[8919]: Received SIGUSR1 >> Dec 03 00:23:54 alfa systemd[1]: anacron.service: State 'stop-sigterm' timed >> out. Killing. > > Looks like something asked systemd to send sigusr1 to anacron, which is > "clean exit" for anacron. Since the anacron package told systemd to use > "killmode mixed", it waits for a while, then proceeds to SIGKILL > everything in the group because they took too long to die. > > It is a bug, but on anacron, not systemd. systemd is doing exactly what > it was (mis)configured to do by the anacron package. > > And something *is* asking anacron to restart or to stop. Look at your > log rotation scripts (and also anacron's). https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=864213#25 If you drop /lib/udev/rules.d/60-anacron.rules my bet is that the problem is gone. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: systemd+anacron breaks cron jobs?
On Tuesday, December 4, 2018 at 1:40:03 PM UTC+5:30, Kamil Jońca wrote: > Rusi Mody writes: > > Best bet is switch to using systemd timers > > Second question: Why systemd kills my jobs? (Yes I know what parameters > are responsible for this, but why they are configured that way?) I am no expert of systemd. Heck Im not even a noob! Just saying that timers seems to be the systemd way in place of cron/anacron https://unix.stackexchange.com/questions/278564/cron-vs-systemd-timers > > Ekhem. My personal cron entries are called regardles I am logged in or > not. How can I achieve this with systemd "user" timers? The specific answer is (I guess!) to look at persistent/ linger etc options The wider answer maybe: Do you really need to use user units? Especially when you explicitly want their usage dissociated from user sessions?
Re: systemd+anacron breaks cron jobs?
On Mon, 03 Dec 2018, Kamil Jońca wrote: > >> Dec 03 00:23:54 alfa systemd[1]: anacron.service: State 'stop-sigterm' > >> timed out. Killing. > > See, someone or some script told systemd to stop anacron (or maybe to > > stop-and-start/restart it). THIS is causing the undesired behavior. > > Dec 03 00:22:24 alfa systemd[1]: Stopping Run anacron jobs... > Dec 03 00:22:24 alfa anacron[8919]: Received SIGUSR1 > Dec 03 00:23:54 alfa systemd[1]: anacron.service: State 'stop-sigterm' timed > out. Killing. Looks like something asked systemd to send sigusr1 to anacron, which is "clean exit" for anacron. Since the anacron package told systemd to use "killmode mixed", it waits for a while, then proceeds to SIGKILL everything in the group because they took too long to die. It is a bug, but on anacron, not systemd. systemd is doing exactly what it was (mis)configured to do by the anacron package. And something *is* asking anacron to restart or to stop. Look at your log rotation scripts (and also anacron's). > I have NO scripts which kill anacron. IMO it is systemd thing. What happens when the anacron service is stopped/restarted under systemd is different from non-systemd anacron, but that's because the anacron package misconfigured systemd, so it would be a "systemd thing as (mis)configured by the package". But something is triggering that service stop/restart/force-reload (can't tell which from the logs), and it is not systemd. systemd is obeying orders from some other system component. -- Henrique Holschuh
Re: systemd+anacron breaks cron jobs?
Rusi Mody writes: > On Monday, December 3, 2018 at 1:30:07 PM UTC+5:30, Kamil Jońca wrote: >> I have in my /etc/cron.daily some local scripts. >> Some of them can be occassionally time-consuming. >> Recently I found that some of them did not end. >> And what I found: >> 1. as "everybody" knows, in case of anacron presence, system cron jobs >> are delegated to anacron. >> 2. recently in Debian we have anacron.timer which also runs "cron.daily" >>entry. >> 3. there is a timeout in systemd services which cause to kill my jobs :( >> >> So my question is: is it safe to remove/disable anacron timer? > > Best bet is switch to using systemd timers Ekhem. My personal cron entries are called regardles I am logged in or not. How can I achieve this with systemd "user" timers? Second question: Why systemd kills my jobs? (Yes I know what parameters are responsible for this, but why they are configured that way?) KJ -- http://stopstopnop.pl/stop_stopnop.pl_o_nas.html The Ancient Doctrine of Mind Over Matter: I don't mind... and you don't matter. -- As revealed to reporter G. Rivera by Swami Havabanana
Re: systemd+anacron breaks cron jobs?
On Monday, December 3, 2018 at 1:30:07 PM UTC+5:30, Kamil Jońca wrote: > I have in my /etc/cron.daily some local scripts. > Some of them can be occassionally time-consuming. > Recently I found that some of them did not end. > And what I found: > 1. as "everybody" knows, in case of anacron presence, system cron jobs > are delegated to anacron. > 2. recently in Debian we have anacron.timer which also runs "cron.daily" >entry. > 3. there is a timeout in systemd services which cause to kill my jobs :( > > So my question is: is it safe to remove/disable anacron timer? Best bet is switch to using systemd timers https://medium.com/horrible-hacks/using-systemd-as-a-better-cron-a4023eea996d https://unix.stackexchange.com/questions/84858/systemd-timer-units-that-mimic-anacron-behaviour
Re: systemd+anacron breaks cron jobs?
Henrique de Moraes Holschuh writes: > On Mon, 03 Dec 2018, Kamil Jońca wrote: >> 1. as "everybody" knows, in case of anacron presence, system cron jobs >> are delegated to anacron. >> 2. recently in Debian we have anacron.timer which also runs "cron.daily" >>entry. >> 3. there is a timeout in systemd services which cause to kill my jobs :( > > Eh, that will only happen if you try to stop the anacron service, > otherwise the timeout would apply to anacron _itself_ failing to start, > not to any of its jobs... > >> Dec 03 00:23:54 alfa systemd[1]: anacron.service: State 'stop-sigterm' timed >> out. Killing. > > See, someone or some script told systemd to stop anacron (or maybe to > stop-and-start/restart it). THIS is causing the undesired behavior. Could you, please, interpret these logs (excerpt from "journalctl -u anacron.service" result) Dec 03 00:03:45 alfa systemd[1]: Started Run anacron jobs. Dec 03 00:03:45 alfa anacron[8919]: Anacron 2.3 started on 2018-12-03 Dec 03 00:03:45 alfa anacron[8919]: Will run job `cron.daily' in 5 min. Dec 03 00:03:45 alfa anacron[8919]: Will run job `cron.weekly' in 10 min. Dec 03 00:03:45 alfa anacron[8919]: Jobs will be executed sequentially Dec 03 00:08:45 alfa anacron[8919]: Job `cron.daily' started Dec 03 00:08:45 alfa anacron[9253]: Updated timestamp for job `cron.daily' to 2018-12-03 Dec 03 00:17:55 alfa sudo[14045]: root : TTY=unknown ; PWD=/ ; USER=f4y ; COMMAND=/bin/bash -c /home/kjonca/archive.sh Dec 03 00:17:55 alfa sudo[14045]: pam_unix(sudo:session): session opened for user kjonca by (uid=0) Dec 03 00:17:56 alfa sudo[14045]: pam_unix(sudo:session): session closed for user kjonca Dec 03 00:17:56 alfa sudo[14049]: root : TTY=unknown ; PWD=/ ; USER=news ; COMMAND=/usr/local/lib/news/dumpnews Dec 03 00:17:56 alfa sudo[14049]: pam_unix(sudo:session): session opened for user news by (uid=0) Dec 03 00:22:24 alfa systemd[1]: Stopping Run anacron jobs... Dec 03 00:22:24 alfa anacron[8919]: Received SIGUSR1 Dec 03 00:23:54 alfa systemd[1]: anacron.service: State 'stop-sigterm' timed out. Killing. Dec 03 00:23:54 alfa systemd[1]: anacron.service: Killing process 8919 (anacron) with signal SIGKILL. Dec 03 00:23:54 alfa systemd[1]: anacron.service: Killing process 9249 (sh) with signal SIGKILL. Dec 03 00:23:54 alfa systemd[1]: anacron.service: Killing process 9250 (run-parts) with signal SIGKILL. Dec 03 00:23:54 alfa systemd[1]: anacron.service: Killing process 9409 (local) with signal SIGKILL. Dec 03 00:23:54 alfa systemd[1]: anacron.service: Killing process 14049 (sudo) with signal SIGKILL. Dec 03 00:23:54 alfa systemd[1]: anacron.service: Killing process 14050 (dumpnews) with signal SIGKILL. Dec 03 00:23:54 alfa systemd[1]: anacron.service: Killing process 14067 (sort) with signal SIGKILL. Dec 03 00:23:54 alfa systemd[1]: anacron.service: Killing process 14068 (tar) with signal SIGKILL. Dec 03 00:23:54 alfa systemd[1]: anacron.service: Killing process 14069 (xz) with signal SIGKILL. Dec 03 00:23:54 alfa systemd[1]: anacron.service: Main process exited, code=killed, status=9/KILL Dec 03 00:23:54 alfa systemd[1]: anacron.service: Killing process 9249 (sh) with signal SIGKILL. Dec 03 00:23:54 alfa systemd[1]: anacron.service: Killing process 9250 (run-parts) with signal SIGKILL. Dec 03 00:23:54 alfa systemd[1]: anacron.service: Killing process 14049 (sudo) with signal SIGKILL. Dec 03 00:23:54 alfa systemd[1]: anacron.service: Killing process 14050 (dumpnews) with signal SIGKILL. Dec 03 00:23:54 alfa systemd[1]: anacron.service: Killing process 14067 (sort) with signal SIGKILL. Dec 03 00:23:54 alfa systemd[1]: anacron.service: Killing process 14068 (tar) with signal SIGKILL. Dec 03 00:23:54 alfa systemd[1]: anacron.service: Killing process 14069 (xz) with signal SIGKILL. Dec 03 00:23:54 alfa systemd[1]: anacron.service: Failed with result 'timeout'. Dec 03 00:23:54 alfa systemd[1]: Stopped Run anacron jobs. Dec 03 01:00:02 alfa systemd[1]: Started Run anacron jobs. > > I am not sure what the proper fix would be in this case, depends on what > caused the attempt to stop (or maybe restart) the service. I have NO scripts which kill anacron. IMO it is systemd thing. KJ -- http://wolnelektury.pl/wesprzyj/teraz/ The aim of a joke is not to degrade the human being but to remind him that he is already degraded. -- George Orwell
Re: systemd+anacron breaks cron jobs?
Kamil Jońca wrote: > Here is some journal excerpt: > Dec 03 00:23:54 alfa systemd[1]: anacron.service: State 'stop-sigterm' > timed out. Killing. Dec 03 00:23:54 alfa systemd[1]: anacron.service: > Killing process 8919 (anacron) with signal SIGKILL. Dec 03 00:23:54 alfa > systemd[1]: anacron.service: Killing process 9249 (sh) with signal > SIGKILL. Dec 03 00:23:54 alfa systemd[1]: anacron.service: Killing process > 9250 (run-parts) with signal SIGKILL. Dec 03 00:23:54 alfa systemd[1]: > anacron.service: Killing process 9409 (local) with signal SIGKILL. Dec 03 > 00:23:54 alfa systemd[1]: anacron.service: Killing process 14049 (sudo) > with signal SIGKILL. Dec 03 00:23:54 alfa systemd[1]: anacron.service: > Killing process 14050 (dumpnews) with signal SIGKILL. Dec 03 00:23:54 alfa > systemd[1]: anacron.service: Killing process 14067 (sort) with signal > SIGKILL. Dec 03 00:23:54 alfa systemd[1]: anacron.service: Killing process > 14068 (tar) with signal SIGKILL. Dec 03 00:23:54 alfa systemd[1]: > anacron.service: Killing process 14069 (xz) with signal SIGKILL. Dec 03 > 00:23:54 alfa systemd[1]: anacron.service: Main process exited, > code=killed, status=9/KILL Dec 03 00:23:54 alfa systemd[1]: > anacron.service: Killing process 9249 (sh) with signal SIGKILL. Dec 03 > 00:23:54 alfa systemd[1]: anacron.service: Killing process 9250 > (run-parts) with signal SIGKILL. Dec 03 00:23:54 alfa systemd[1]: > anacron.service: Killing process 14049 (sudo) with signal SIGKILL. Dec 03 > 00:23:54 alfa systemd[1]: anacron.service: Killing process 14050 > (dumpnews) with signal SIGKILL. Dec 03 00:23:54 alfa systemd[1]: > anacron.service: Killing process 14067 (sort) with signal SIGKILL. Dec 03 > 00:23:54 alfa systemd[1]: anacron.service: Killing process 14068 (tar) > with signal SIGKILL. Dec 03 00:23:54 alfa systemd[1]: anacron.service: > Killing process 14069 (xz) with signal SIGKILL. Dec 03 00:23:54 alfa > systemd[1]: anacron.service: Failed with result 'timeout'. Looks like systemd is trying to interpret the command from the cronjob and it does not manage to handle it. I do not use systemd, but I read that you need to update scripts to match the systemd logic, so it might be you should rewrite this or other wise tell systemd to ignore it. regards
Re: systemd+anacron breaks cron jobs?
On Mon, 03 Dec 2018, Kamil Jońca wrote: > 1. as "everybody" knows, in case of anacron presence, system cron jobs > are delegated to anacron. > 2. recently in Debian we have anacron.timer which also runs "cron.daily" >entry. > 3. there is a timeout in systemd services which cause to kill my jobs :( Eh, that will only happen if you try to stop the anacron service, otherwise the timeout would apply to anacron _itself_ failing to start, not to any of its jobs... > Dec 03 00:23:54 alfa systemd[1]: anacron.service: State 'stop-sigterm' timed > out. Killing. See, someone or some script told systemd to stop anacron (or maybe to stop-and-start/restart it). THIS is causing the undesired behavior. I am not sure what the proper fix would be in this case, depends on what caused the attempt to stop (or maybe restart) the service. -- Henrique Holschuh
systemd+anacron breaks cron jobs?
I have in my /etc/cron.daily some local scripts. Some of them can be occassionally time-consuming. Recently I found that some of them did not end. And what I found: 1. as "everybody" knows, in case of anacron presence, system cron jobs are delegated to anacron. 2. recently in Debian we have anacron.timer which also runs "cron.daily" entry. 3. there is a timeout in systemd services which cause to kill my jobs :( So my question is: is it safe to remove/disable anacron timer? Here is some journal excerpt: Dec 03 00:23:54 alfa systemd[1]: anacron.service: State 'stop-sigterm' timed out. Killing. Dec 03 00:23:54 alfa systemd[1]: anacron.service: Killing process 8919 (anacron) with signal SIGKILL. Dec 03 00:23:54 alfa systemd[1]: anacron.service: Killing process 9249 (sh) with signal SIGKILL. Dec 03 00:23:54 alfa systemd[1]: anacron.service: Killing process 9250 (run-parts) with signal SIGKILL. Dec 03 00:23:54 alfa systemd[1]: anacron.service: Killing process 9409 (local) with signal SIGKILL. Dec 03 00:23:54 alfa systemd[1]: anacron.service: Killing process 14049 (sudo) with signal SIGKILL. Dec 03 00:23:54 alfa systemd[1]: anacron.service: Killing process 14050 (dumpnews) with signal SIGKILL. Dec 03 00:23:54 alfa systemd[1]: anacron.service: Killing process 14067 (sort) with signal SIGKILL. Dec 03 00:23:54 alfa systemd[1]: anacron.service: Killing process 14068 (tar) with signal SIGKILL. Dec 03 00:23:54 alfa systemd[1]: anacron.service: Killing process 14069 (xz) with signal SIGKILL. Dec 03 00:23:54 alfa systemd[1]: anacron.service: Main process exited, code=killed, status=9/KILL Dec 03 00:23:54 alfa systemd[1]: anacron.service: Killing process 9249 (sh) with signal SIGKILL. Dec 03 00:23:54 alfa systemd[1]: anacron.service: Killing process 9250 (run-parts) with signal SIGKILL. Dec 03 00:23:54 alfa systemd[1]: anacron.service: Killing process 14049 (sudo) with signal SIGKILL. Dec 03 00:23:54 alfa systemd[1]: anacron.service: Killing process 14050 (dumpnews) with signal SIGKILL. Dec 03 00:23:54 alfa systemd[1]: anacron.service: Killing process 14067 (sort) with signal SIGKILL. Dec 03 00:23:54 alfa systemd[1]: anacron.service: Killing process 14068 (tar) with signal SIGKILL. Dec 03 00:23:54 alfa systemd[1]: anacron.service: Killing process 14069 (xz) with signal SIGKILL. Dec 03 00:23:54 alfa systemd[1]: anacron.service: Failed with result 'timeout'. KJ -- http://stopstopnop.pl/stop_stopnop.pl_o_nas.html A rolling disk gathers no MOS.
Errors with Amavis cron jobs
Hi all!
Recently, when checking the "amavis" email account of my mail server,
I found several emails from the following cron jobs:
-
# cat /etc/cron.d/amavisd-new
#
# SpamAssassin maintenance for amavisd-new
#
# m h dom mon dow user command
18 */3 * * * amavis test -e /usr/sbin/amavisd-new-cronjob &&
/usr/sbin/amavisd-new-cronjob sa-sync
24 1 * * * amavis test -e /usr/sbin/amavisd-new-cronjob &&
/usr/sbin/amavisd-new-cronjob sa-clean
-
Both jobs seems to fail. What catches my attention is that emails
with errors always occur at the same times. For the first job,
at 15.18 GMT-3; and for the second job, at 01.24 GMT-3. Well, the
second job is always running at the same time, although the first
job is executed at regular intervals of three hours and the error
always occurs at the same time (15.18 GMT-3).
Emails from both jobs seems to suggest the same kind of error:
-
bayes: unknown packing format for bayes db, please re-learn: 86 at
/usr/share/perl5/Mail/SpamAssassin/BayesStore/DBM.pm line 1926.
bayes: unknown packing format for bayes db, please re-learn: 86 at
/usr/share/perl5/Mail/SpamAssassin/BayesStore/DBM.pm line 1926.
bayes: unknown packing format for bayes db, please re-learn: 86 at
/usr/share/perl5/Mail/SpamAssassin/BayesStore/DBM.pm line 1926.
bayes: unknown packing format for bayes db, please re-learn: 86 at
/usr/share/perl5/Mail/SpamAssassin/BayesStore/DBM.pm line 1926.
-
I took a look on the lines mentioned, although I am not very
clear what may be the cause of this error:
-
1909 if (($packed & FORMAT_FLAG) == ONE_BYTE_FORMAT) {
1910 return (($packed & ONE_BYTE_SSS_BITS) >> 3,
1911 $packed & ONE_BYTE_HHH_BITS,
1912 $atime || 0);
1913 }
1914 elsif (($packed & FORMAT_FLAG) == TWO_LONGS_FORMAT) {
1915 my ($packed, $ts, $th, $atime);
1916 if ($self->{db_version} >= 1) {
1917 ($packed, $ts, $th, $atime) = unpack("CVVV", $value);
1918 }
1919 elsif ($self->{db_version} == 0) {
1920 ($packed, $ts, $th, $atime) = unpack("CLLS", $value);
1921 }
1922 return ($ts || 0, $th || 0, $atime || 0);
1923 }
1924 # other formats would go here...
1925 else {
1926 warn "bayes: unknown packing format for bayes db, please re-learn:
$packed";
1927 return (0, 0, 0);
1928 }
1929 }
-
Has anyone experienced something like this?
Thanks in advance.
Kinds regards,
Daniel
cron jobs to restart a shell process ...
~ Sometimes I need to start a long running process which for various reasons may be stopped (server drops connection, OS kills it, ...) and I would like to have a somewhat automatic mechanism to check if it was stopped and, in that case, restart it (of course, with a new process id) ~ This is what I have in mind: ~ 1) run an initial script to set up the context of the long running process, which, of course, will be specific, but the communication between 1) and 2) is just trough a regular protocolled file (I try to make my code as compatible as possible and pipes and other forms of interprocess comm tend to be very OS specific). ~ 2) a second general script which based on 1) and the id of the running process just checks if process is running and restarts it in the case it isn't, based on: ~ 2.1) a lock file named after some identifying metadata regarding 1), and ~ 2.2) containing the current/last process id. ~ 3) insert a line in your crontab file, to run 2) ~ You can check if a process is running by pars-, greping ps aux's output and simply go monkey to finish some working script, but I am sure those needs aren't just mine and there should be either a flag for cron jobs, a utility, or some best practices out there I don't know of. In fact, do you know of best practices for max data processing (I am talking here about jobs that may take days) ~ Is there such a thing? ~ Any suggestions? ~ thank you, lbrtchx -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cafakbwjxidvyrcgk3xaznlabjd0pnjcd1fycpaigve76p0s...@mail.gmail.com
Re: cron jobs to restart a shell process ...
~ of course, as part of this algorithm there should be a way of determining if the job finished gracefully and there should be a way of recontextualizing each restart ... ~ lbrtchx -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAFakBwh5myvjOj-w85rq7J-djdHPGiJjEvzniSBhDpSzeCy2=w...@mail.gmail.com
Re: cron jobs to restart a shell process ...
On Mon, Feb 04, 2013 at 01:07:55PM +, Albretch Mueller wrote:
~
Sometimes I need to start a long running process which for various reasons
may
be stopped (server drops connection, OS kills it, ...) and I would like to
have
a somewhat automatic mechanism to check if it was stopped and, in that case,
restart it (of course, with a new process id)
~
This is what I have in mind:
~
1) run an initial script to set up the context of the long running process,
which, of course, will be specific, but the communication between 1) and 2) is
just trough a regular protocolled file (I try to make my code as compatible as
possible and pipes and other forms of interprocess comm tend to be very OS
specific).
~
2) a second general script which based on 1) and the id of the running
process
just checks if process is running and restarts it in the case it
isn't, based on:
~
2.1) a lock file named after some identifying metadata regarding 1), and
~
2.2) containing the current/last process id.
~
3) insert a line in your crontab file, to run 2)
~
You can check if a process is running by pars-, greping ps aux's output and
simply go monkey to finish some working script, but I am sure those needs
aren't
just mine and there should be either a flag for cron jobs, a utility, or some
best practices out there I don't know of. In fact, do you know of best
practices
for max data processing (I am talking here about jobs that may take days)
A 'crontab' example, controlling the online time of my modem
(my providers switch cheap and very expansive fees at certain hours)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
SHELL=/bin/bash
PATH=/usr/lsh:/usr/lbin:/usr/bin:/bin:/sbin
# m h dom mon dow command
# -
# IF online through script 'ip-Tele2', then shutdown modem every 2 hours
# (at minute 57, run script 'ring-bell'; at minute 59, run 'poff') (weekdays)
57 0-22/2* * 1-5 pidof pppd ps -o command -C ip-Tele2 ring-bell 3
59 0-22/2* * 1-5 pidof pppd ps -o command -C ip-Tele2 poff
/dev/null
# IF stub file: 'ip-stop' exists, then shutdown modem ('poff') (daily, every
hour)
# (at minute 57, run script 'ring-bell'; at minute 59, run 'poff') (7 days)
57 0-23 * * 0-6 [ -f /tmpp/stub/crontab/ip-stop ] pidof pppd
ring-bell 3
59 0-23 * * 0-6 [ -f /tmpp/stub/crontab/ip-stop ] pidof pppd poff
rm /tmpp/stub/crontab/ip-stop
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Hope this gives some helpful clue.
Moin W.F.
--
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130204191906.ga4...@fok01.laje.edewe.de
Re: Cron jobs
Resolvi o problema em definitivo, vou compartilhar aqui para que fique
de referência futura.
Como dito, os scripts acionados pelo cron que façam uso do servidor X
precisam informar explicitamente as variáveis de ambiente DISPLAY e
XAUTHORITY.
No caso do DISPLAY, isto é trivial, basta escolher e informar. Normalmente:
export DISPLAY=:0
Se o display desejado for o do primeiro usuário conectado fisicamente à máquina.
Agora no caso do XAUTHORITY, o arquivo que garante o acesso pode
variar de acordo com o ambiente gráfico utilizado. Normalmente será o
~/.Xauthority, de modo que basta um:
export XAUTHORITY=/home/$USER/.Xauthority
Mas no caso específico do gdm3, cada nova sessão cria um arquivo
randômico em /var/run/gdm3/auth-for-$USER-$HASH/database, o que nos
obriga a procurar pelo arquivo correto para a sessão específica.
No meu caso, eu resolvi o problema usando:
XAUTHFOLDER=`ls /var/run/gdm3/ | grep Debian`
export XAUTHORITY=/var/run/gdm3/${XAUTHFOLDER}/database
Aproveitando que no Debian sempre haverá um arquivo do sistema,
independente de qual será o usuário conectado. Essa solução, contudo,
não serviria para qualquer distro.
Outras soluções que encontrei foram:
http://unix.stackexchange.com/questions/10121/open-a-window-on-a-remote-x-display-why-cannot-open-display
http://stackoverflow.com/questions/11015029/cron-job-how-to-run-a-script-that-requires-to-open-display
Abraços,
André Nunes Batista
Blog: http://tagesuhu.wordpress.com/
PGP Public Key: 0x7b0590cb6722cf80
2012/8/7 André Nunes andrenbati...@gmail.com:
Consegui descobrir qual era o problema falando com o Javier
Fernandez-Sanguino, mantenedor do pacote cron do debian.
O script precisa acessar o servidor X e, para tanto, precisa do
XAUTHORITY correto. Quando executado da linha de comando, o XAUTHORITY
já está dado como variável do ambiente, mas quando é invocado pelo
cron, o mesmo não acontece.
Assim, para solucionar o problema é preciso atribuir explicitamente a
variável XAUTHORITY no script. O grande problema agora é que o GMD3
não usa o ~/.Xauthority, mas um arquivo aleatório dentro do
/var/run/gdm3/*/database que é criado para cada nova sessão.
Vou tentar criar um script que descubra o path correto para o
xauthority da sessão, se alguém tiver experiência com bash scripting e
quiser dar uma mão, serei extremamente grato. De qualquer forma, o
problema com o cron já está resolvido e o script funcionando.
Abraços,
André Nunes Batista
Blog: http://tagesuhu.wordpress.com/
PGP Public Key: 0x7b0590cb6722cf80
2012/8/1 André Nunes andrenbati...@gmail.com:
Olá,
Estou tentando, sem sucesso, agendar alguns scripts usando o cron e
gostaria de saber se alguém consegue me dar uma luz aqui.
Um dos scripts é:
#!/bin/bash
DATE=`date '+%Y%m%d_%H_%M'`
export DISPLAY=:0
/usr/bin/import -window root -resize 800 /var/log/logkeys/ss/${DATE}.jpg
O path para o script é: /usr/local/bin/screen.sh
Permissões, usuário e grupo: -rwxr-xr-x 1 root staff
O cron job é:
--
# Agendamento de printscreen a cada dois minutos.
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
*/2 * * * * root /usr/local/bin/screen.sh
--
O path é: /etc/cron.d/screen
As permissões, usuário e grupo são: -rw-r--r-- 1 root root
O /var/log/syslog informa que o agendamento deu certo e o script está
sendo executado:
Aug 1 15:08:53 tagesuhu-pc dbus[1639]: [system] Successfully
activated service 'org.debian.apt'
Aug 1 15:08:54 tagesuhu-pc wpa_supplicant[1700]: wlan0: WPA: Group
rekeying completed with X [GTK=CCMP]
Aug 1 15:09:25 tagesuhu-pc wpa_supplicant[1700]: wlan0: WPA: Group
rekeying completed with X [GTK=CCMP]
Aug 1 15:09:56 tagesuhu-pc wpa_supplicant[1700]: wlan0: WPA: Group
rekeying completed with [GTK=CCMP]
Aug 1 15:10:01 tagesuhu-pc /USR/SBIN/CRON[22434]: (root) CMD
(/usr/local/bin/screen.sh)
Aug 1 15:10:27 tagesuhu-pc wpa_supplicant[1700]: wlan0: WPA: Group
rekeying completed with [GTK=CCMP]
Aug 1 15:10:58 tagesuhu-pc wpa_supplicant[1700]: wlan0: WPA: Group
rekeying completed with XXX [GTK=CCMP]
Aug 1 15:11:29 tagesuhu-pc wpa_supplicant[1700]: wlan0: WPA: Group
rekeying completed with [GTK=CCMP]
Aug 1 15:12:00 tagesuhu-pc wpa_supplicant[1700]: wlan0: WPA: Group
rekeying completed with [GTK=CCMP]
Aug 1 15:12:01 tagesuhu-pc /USR/SBIN/CRON[22449]: (root) CMD
(/usr/local/bin/screen.sh)
Aug 1 15:12:31 tagesuhu-pc wpa_supplicant[1700]: wlan0: WPA: Group
rekeying completed with X [GTK=CCMP]
Aug 1 15:13:02 tagesuhu-pc wpa_supplicant[1700]: wlan0: WPA: Group
rekeying completed with XXX [GTK=CCMP]
Aug 1 15:13:33 tagesuhu-pc wpa_supplicant[1700]: wlan0: WPA: Group
rekeying completed with XX [GTK=CCMP]
Aug 1 15:13:53 tagesuhu-pc AptDaemon: INFO: Quitting due to
Re: Cron jobs
Consegui descobrir qual era o problema falando com o Javier
Fernandez-Sanguino, mantenedor do pacote cron do debian.
O script precisa acessar o servidor X e, para tanto, precisa do
XAUTHORITY correto. Quando executado da linha de comando, o XAUTHORITY
já está dado como variável do ambiente, mas quando é invocado pelo
cron, o mesmo não acontece.
Assim, para solucionar o problema é preciso atribuir explicitamente a
variável XAUTHORITY no script. O grande problema agora é que o GMD3
não usa o ~/.Xauthority, mas um arquivo aleatório dentro do
/var/run/gdm3/*/database que é criado para cada nova sessão.
Vou tentar criar um script que descubra o path correto para o
xauthority da sessão, se alguém tiver experiência com bash scripting e
quiser dar uma mão, serei extremamente grato. De qualquer forma, o
problema com o cron já está resolvido e o script funcionando.
Abraços,
André Nunes Batista
Blog: http://tagesuhu.wordpress.com/
PGP Public Key: 0x7b0590cb6722cf80
2012/8/1 André Nunes andrenbati...@gmail.com:
Olá,
Estou tentando, sem sucesso, agendar alguns scripts usando o cron e
gostaria de saber se alguém consegue me dar uma luz aqui.
Um dos scripts é:
#!/bin/bash
DATE=`date '+%Y%m%d_%H_%M'`
export DISPLAY=:0
/usr/bin/import -window root -resize 800 /var/log/logkeys/ss/${DATE}.jpg
O path para o script é: /usr/local/bin/screen.sh
Permissões, usuário e grupo: -rwxr-xr-x 1 root staff
O cron job é:
--
# Agendamento de printscreen a cada dois minutos.
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
*/2 * * * * root /usr/local/bin/screen.sh
--
O path é: /etc/cron.d/screen
As permissões, usuário e grupo são: -rw-r--r-- 1 root root
O /var/log/syslog informa que o agendamento deu certo e o script está
sendo executado:
Aug 1 15:08:53 tagesuhu-pc dbus[1639]: [system] Successfully
activated service 'org.debian.apt'
Aug 1 15:08:54 tagesuhu-pc wpa_supplicant[1700]: wlan0: WPA: Group
rekeying completed with X [GTK=CCMP]
Aug 1 15:09:25 tagesuhu-pc wpa_supplicant[1700]: wlan0: WPA: Group
rekeying completed with X [GTK=CCMP]
Aug 1 15:09:56 tagesuhu-pc wpa_supplicant[1700]: wlan0: WPA: Group
rekeying completed with [GTK=CCMP]
Aug 1 15:10:01 tagesuhu-pc /USR/SBIN/CRON[22434]: (root) CMD
(/usr/local/bin/screen.sh)
Aug 1 15:10:27 tagesuhu-pc wpa_supplicant[1700]: wlan0: WPA: Group
rekeying completed with [GTK=CCMP]
Aug 1 15:10:58 tagesuhu-pc wpa_supplicant[1700]: wlan0: WPA: Group
rekeying completed with XXX [GTK=CCMP]
Aug 1 15:11:29 tagesuhu-pc wpa_supplicant[1700]: wlan0: WPA: Group
rekeying completed with [GTK=CCMP]
Aug 1 15:12:00 tagesuhu-pc wpa_supplicant[1700]: wlan0: WPA: Group
rekeying completed with [GTK=CCMP]
Aug 1 15:12:01 tagesuhu-pc /USR/SBIN/CRON[22449]: (root) CMD
(/usr/local/bin/screen.sh)
Aug 1 15:12:31 tagesuhu-pc wpa_supplicant[1700]: wlan0: WPA: Group
rekeying completed with X [GTK=CCMP]
Aug 1 15:13:02 tagesuhu-pc wpa_supplicant[1700]: wlan0: WPA: Group
rekeying completed with XXX [GTK=CCMP]
Aug 1 15:13:33 tagesuhu-pc wpa_supplicant[1700]: wlan0: WPA: Group
rekeying completed with XX [GTK=CCMP]
Aug 1 15:13:53 tagesuhu-pc AptDaemon: INFO: Quitting due to inactivity
Aug 1 15:13:53 tagesuhu-pc AptDaemon: INFO: Quitting was requested
Aug 1 15:14:01 tagesuhu-pc /USR/SBIN/CRON[22464]: (root) CMD
(/usr/local/bin/screen.sh)
No entanto, ao verificar o diretório /var/log/logkeys/ss/, nenhum
arquivo está sendo gravado.
Testei o script diretamente do shell e ele funcionou normalmente. Além
disso, os outros dois scripts também não estão sendo executados pelo
cron, de modo que eu acredito que há algum problema na forma como eu
agendei a sua execução, só não consigo entender qual é o problema.
Obs: Não possuo nem o arquivo cron.allow nem o arquivo cron.deny.
André Nunes Batista
Blog: http://tagesuhu.wordpress.com/
PGP Public Key: 0x7b0590cb6722cf80
--
To UNSUBSCRIBE, email to debian-user-portuguese-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/caakmmzghfxrazcccfyux0fyjp+4em0yybodruf22u4ra1um...@mail.gmail.com
Cron jobs
Olá,
Estou tentando, sem sucesso, agendar alguns scripts usando o cron e
gostaria de saber se alguém consegue me dar uma luz aqui.
Um dos scripts é:
#!/bin/bash
DATE=`date '+%Y%m%d_%H_%M'`
export DISPLAY=:0
/usr/bin/import -window root -resize 800 /var/log/logkeys/ss/${DATE}.jpg
O path para o script é: /usr/local/bin/screen.sh
Permissões, usuário e grupo: -rwxr-xr-x 1 root staff
O cron job é:
--
# Agendamento de printscreen a cada dois minutos.
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
*/2 * * * * root /usr/local/bin/screen.sh
--
O path é: /etc/cron.d/screen
As permissões, usuário e grupo são: -rw-r--r-- 1 root root
O /var/log/syslog informa que o agendamento deu certo e o script está
sendo executado:
Aug 1 15:08:53 tagesuhu-pc dbus[1639]: [system] Successfully
activated service 'org.debian.apt'
Aug 1 15:08:54 tagesuhu-pc wpa_supplicant[1700]: wlan0: WPA: Group
rekeying completed with X [GTK=CCMP]
Aug 1 15:09:25 tagesuhu-pc wpa_supplicant[1700]: wlan0: WPA: Group
rekeying completed with X [GTK=CCMP]
Aug 1 15:09:56 tagesuhu-pc wpa_supplicant[1700]: wlan0: WPA: Group
rekeying completed with [GTK=CCMP]
Aug 1 15:10:01 tagesuhu-pc /USR/SBIN/CRON[22434]: (root) CMD
(/usr/local/bin/screen.sh)
Aug 1 15:10:27 tagesuhu-pc wpa_supplicant[1700]: wlan0: WPA: Group
rekeying completed with [GTK=CCMP]
Aug 1 15:10:58 tagesuhu-pc wpa_supplicant[1700]: wlan0: WPA: Group
rekeying completed with XXX [GTK=CCMP]
Aug 1 15:11:29 tagesuhu-pc wpa_supplicant[1700]: wlan0: WPA: Group
rekeying completed with [GTK=CCMP]
Aug 1 15:12:00 tagesuhu-pc wpa_supplicant[1700]: wlan0: WPA: Group
rekeying completed with [GTK=CCMP]
Aug 1 15:12:01 tagesuhu-pc /USR/SBIN/CRON[22449]: (root) CMD
(/usr/local/bin/screen.sh)
Aug 1 15:12:31 tagesuhu-pc wpa_supplicant[1700]: wlan0: WPA: Group
rekeying completed with X [GTK=CCMP]
Aug 1 15:13:02 tagesuhu-pc wpa_supplicant[1700]: wlan0: WPA: Group
rekeying completed with XXX [GTK=CCMP]
Aug 1 15:13:33 tagesuhu-pc wpa_supplicant[1700]: wlan0: WPA: Group
rekeying completed with XX [GTK=CCMP]
Aug 1 15:13:53 tagesuhu-pc AptDaemon: INFO: Quitting due to inactivity
Aug 1 15:13:53 tagesuhu-pc AptDaemon: INFO: Quitting was requested
Aug 1 15:14:01 tagesuhu-pc /USR/SBIN/CRON[22464]: (root) CMD
(/usr/local/bin/screen.sh)
No entanto, ao verificar o diretório /var/log/logkeys/ss/, nenhum
arquivo está sendo gravado.
Testei o script diretamente do shell e ele funcionou normalmente. Além
disso, os outros dois scripts também não estão sendo executados pelo
cron, de modo que eu acredito que há algum problema na forma como eu
agendei a sua execução, só não consigo entender qual é o problema.
Obs: Não possuo nem o arquivo cron.allow nem o arquivo cron.deny.
André Nunes Batista
Blog: http://tagesuhu.wordpress.com/
PGP Public Key: 0x7b0590cb6722cf80
--
To UNSUBSCRIBE, email to debian-user-portuguese-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/CAAKmMzGcN68re5wSvyqFg=gwo-D85GbDKQk0WVkL8r-zJdRD=w...@mail.gmail.com
Re: Authentication issues trying to log onto a box as a standard user, and cron jobs...
On Mon, Apr 9, 2012 at 15:20, Bob Proulx b...@proulx.com wrote: Good. Can you log in as the non-root user? No, all users on this box are from NIS. Yes. Stop all other lines of debugging and focus on this issue. Why is there an error there? Can you log in as that user? laltest@lal-squeeze:~$ su -l laltest No, as this account is a special account without a password. We can only log into this account using a shared ssh key. If not then why not? Start debugging there. Also I have a cron job scheduled, via crontab, to run at 21:01 everyday. It fails to run and the only reference to this I can find in the logs is the following: Apr 8 21:01:01 lal-squeeze CRON[14107]: Authentication failure So I imagine that this is a different manifestation of the same problem. Everything points to the same problem. Debug it first. Any recommendations on how to debug this issue? Look in /var/log/syslog for messages. Look in /var/log/auth.log for messages. I can't see anything in the logs around the time that I try and connect to the box. Cheers Adam -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CA+mfgz0xE-0D13gGa-Ff3mafmHJb_=rd6csbod3ohofuobz...@mail.gmail.com
Re: Authentication issues trying to log onto a box as a standard user, and cron jobs...
Adam Mercer wrote: Bob Proulx wrote: Good. Can you log in as the non-root user? No, all users on this box are from NIS. How does having a user in NIS prevent you from logging in as that user? Presumably the purpose of NIS is to enable the user to log into the account. So I don't understand this comment. Yes. Stop all other lines of debugging and focus on this issue. Why is there an error there? Can you log in as that user? laltest@lal-squeeze:~$ su -l laltest No, as this account is a special account without a password. We can only log into this account using a shared ssh key. And at the moment you can't log in at all. Right? Did this work previously? If so then you might try investigating what changed between then and now. Or is this something that hasn't ever worked and you are trying to set it up for the first time? If not then why not? Start debugging there. I still think that is the right direction to push. Since the account is in NIS but isn't enabled personally I would create a temporary local account for testing. Don't forget to clean it up afterward. I would guess that there is some local configuration issue that is preventing the account from being authorized. Need to isolate the problems into as simple of a case as possible and divide and conquer to a solution. Bob signature.asc Description: Digital signature
Re: Authentication issues trying to log onto a box as a standard user, and cron jobs...
On Wed, Apr 11, 2012 at 16:13, Bob Proulx b...@proulx.com wrote: No, all users on this box are from NIS. How does having a user in NIS prevent you from logging in as that user? Presumably the purpose of NIS is to enable the user to log into the account. So I don't understand this comment. It doesn't that was just extra information. And at the moment you can't log in at all. Right? As the individual user yes. We can log in as root. Did this work previously? If so then you might try investigating what changed between then and now. Or is this something that hasn't ever worked and you are trying to set it up for the first time? This is a fresh VM. I still think that is the right direction to push. Since the account is in NIS but isn't enabled personally I would create a temporary local account for testing. Don't forget to clean it up afterward. I would guess that there is some local configuration issue that is preventing the account from being authorized. Need to isolate the problems into as simple of a case as possible and divide and conquer to a solution. Sounds like a sane approach, I'll do that tomorrow. Cheers Adam -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/ca+mfgz2e0m1xfw-3frek8tkpkama0f8aiyvsvcvwjsthh+r...@mail.gmail.com
Authentication issues trying to log onto a box as a standard user, and cron jobs...
Hi I am trying to connect to a squeeze VM as a standard user using ssh keys, whenever I try to ssh into the box the connection is closed by the VM: ram@g5:~$ ssh -v lal-squeeze OpenSSH_5.5p1 Debian-6+squeeze1, OpenSSL 0.9.8o 01 Jun 2010 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug1: Connecting to lal-squeeze [192.168.100.11] port 22. debug1: Connection established. debug1: identity file /home/ram/.ssh/id_rsa type 1 debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048 debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048 debug1: identity file /home/ram/.ssh/id_rsa-cert type -1 debug1: identity file /home/ram/.ssh/id_dsa type -1 debug1: identity file /home/ram/.ssh/id_dsa-cert type -1 debug1: Remote protocol version 2.0, remote software version OpenSSH_5.5p1 Debian-6+squeeze1 debug1: match: OpenSSH_5.5p1 Debian-6+squeeze1 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_5.5p1 Debian-6+squeeze1 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server-client aes128-ctr hmac-md5 none debug1: kex: client-server aes128-ctr hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(102410248192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug1: Host 'lal-squeeze' is known and matches the RSA host key. debug1: Found key in /home/ram/.ssh/known_hosts:1 debug1: ssh_rsa_verify: signature correct debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: Roaming not allowed by server debug1: SSH2_MSG_SERVICE_REQUEST sent debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey,password debug1: Next authentication method: publickey debug1: Offering public key: /home/ram/.ssh/id_rsa debug1: Server accepts key: pkalg ssh-rsa blen 277 debug1: PEM_read_PrivateKey failed debug1: read PEM private key done: type unknown Enter passphrase for key '/home/ram/.ssh/id_rsa': debug1: read PEM private key done: type RSA Connection closed by 192.168.100.11 ram@g5:~$ I can't find anything in the logs regarding this connect. I can log onto the box as root. Next when I su to a user account I receive the following: root@lal-squeeze:~# su -l laltest su: Authentication failure (Ignored) laltest@lal-squeeze:~$ so something is clearly wrong and I imagine this authentication issue may be related to the inability to log on as a user. Also I have a cron job scheduled, via crontab, to run at 21:01 everyday. It fails to run and the only reference to this I can find in the logs is the following: Apr 8 21:01:01 lal-squeeze CRON[14107]: Authentication failure So I imagine that this is a different manifestation of the same problem. Any recommendations on how to debug this issue? Cheers Adam -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/ca+mfgz2mx5yghgtparncp2tkgfk3-ffns2-ap7oo9g2jt8m...@mail.gmail.com
Re: Authentication issues trying to log onto a box as a standard user, and cron jobs...
Adam Mercer wrote: I am trying to connect to a squeeze VM as a standard user using ssh keys, whenever I try to ssh into the box the connection is closed by the VM: ram@g5:~$ ssh -v lal-squeeze Unfortunately this information is rarely useful. It is the *server* side of the messages that are interesting not the client side. I can log onto the box as root. Good. Can you log in as the non-root user? Next when I su to a user account I receive the following: root@lal-squeeze:~# su -l laltest su: Authentication failure (Ignored) laltest@lal-squeeze:~$ so something is clearly wrong and I imagine this authentication issue may be related to the inability to log on as a user. Yes. Stop all other lines of debugging and focus on this issue. Why is there an error there? Can you log in as that user? laltest@lal-squeeze:~$ su -l laltest If not then why not? Start debugging there. Also I have a cron job scheduled, via crontab, to run at 21:01 everyday. It fails to run and the only reference to this I can find in the logs is the following: Apr 8 21:01:01 lal-squeeze CRON[14107]: Authentication failure So I imagine that this is a different manifestation of the same problem. Everything points to the same problem. Debug it first. Any recommendations on how to debug this issue? Look in /var/log/syslog for messages. Look in /var/log/auth.log for messages. This reads almost like a permission problem. One of the programs that should be suid-root has had the suid-bit removed or something. I am not saying that it is. The error messages in the logs should help. If you can remember what has happened to the VM between when it was working and now that it isn't may also be a good clue. Bob signature.asc Description: Digital signature
Re: Cron jobs and root account locked on Lenny
Alexander Fortin wrote the following on 24.07.2008 23:09 /snip debug hi want to comment on the bugreport be my guest: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=492307 -- bye Thilo key: 0x4A411E09 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Cron jobs and root account locked on Lenny
On Jul 23, 6:50 pm, Andrei Popescu [EMAIL PROTECTED] wrote: I partially agree with the useless of the feauture, but Debian installer is asking if you want to allow root login or not, so I'm Only in expert mode ;) Uhm... well I always find difficult to define what a (Debian) expert need to know to be called so... Anyway, can you manually partition disks with raid and lvm stuff when you are not in expert mode? 'Cause actually it's the only expert thing I need to do at install time :D I'm not an expert, but a quick read through passwd(1) says account expiry should be set to '1', while your 'passwd -S' shows '-1', just like a normal account. How about trying to lock it again? Lock-unlock doesn't work On Jul 23, 8:10 pm, Sven Joachim [EMAIL PROTECTED] wrote: A comment in that bug suggests using usermod --lock root to lock the root account, that does seem to work. Yep, using usermod instead of passwd seems to work fine! So, to report a bug or not to? Which mailing list? Alex -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Cron jobs and root account locked on Lenny
Alexander Fortin wrote the following on 24.07.2008 10:03 /snip Yep, using usermod instead of passwd seems to work fine! So, to report a bug or not to? Which mailing list? http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=389183 Alex HTH -- bye Thilo key: 0x4A411E09 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Cron jobs and root account locked on Lenny
On Thu,24.Jul.08, 11:06:47, Thilo Six wrote: Alexander Fortin wrote the following on 24.07.2008 10:03 /snip Yep, using usermod instead of passwd seems to work fine! So, to report a bug or not to? Which mailing list? http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=389183 Interesting, the manpage passwd(1) says that 'passwd -l' should also set account expiry to 1, but it doesn't. Either passwd or the manpage is wrong, so I think this should be reported against the package passwd. Regards, Andrei -- If you can't explain it simply, you don't understand it well enough. (Albert Einstein) signature.asc Description: Digital signature
Re: Cron jobs and root account locked on Lenny
Hi, Andrei Popescu [EMAIL PROTECTED] writes: Interesting, the manpage passwd(1) says that 'passwd -l' should also set account expiry to 1, but it doesn't. Either passwd or the manpage is wrong, so I think this should be reported against the package passwd. It sets a value to 1 in my /etc/shadow when I last used it. I assume that would be the expiry field? I've got passwd 1:4.1.1-2 installed (from testing). Regards, Ansgar -- PGP: 1024D/595FAD19 739E 2D09 0969 BEA9 9797 B055 DDB0 2FF7 595F AD19 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Cron jobs and root account locked on Lenny
Andrei Popescu wrote the following on 24.07.2008 18:28 /snip --- man 1 passwd - -l, --lock Lock the named account. This option disables an account by changing the password to a value which matches no possible encrypted value, and by setting the account expiry field to 1. - Interesting, the manpage passwd(1) says that 'passwd -l' should also set account expiry to 1, but it doesn't. Either passwd or the manpage is wrong, so I think this should be reported against the package passwd. Regards, Andrei well here it does. Tested with both Debian lenny and Ubuntu hardy. Which version do you use? If you have a locked account without that expiry and use either of the above just 'lock' that account again and then take a look at /etc/shadow. -- bye Thilo key: 0x4A411E09 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Cron jobs and root account locked on Lenny
On Thu,24.Jul.08, 18:47:20, Thilo Six wrote: well here it does. Tested with both Debian lenny and Ubuntu hardy. Which version do you use? I'm not the OP. Regards, Andrei -- If you can't explain it simply, you don't understand it well enough. (Albert Einstein) signature.asc Description: Digital signature
Re: Cron jobs and root account locked on Lenny
Andrei Popescu wrote the following on 24.07.2008 22:04 well here it does. Tested with both Debian lenny and Ubuntu hardy. Which version do you use? I'm not the OP. Regards, Andrei I think that doesn't matter in this regard. You have said your passwd doesn't behave as mentioned in the manpage, which would be clearly a bug. I said i can reproduce exactly the behaviour mentioned in manpage and therefore seeking for an explanation of that divergence which resulted in the question which version you use. -- bye Thilo key: 0x4A411E09 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Cron jobs and root account locked on Lenny
On Thu,24.Jul.08, 22:35:01, Thilo Six wrote: Andrei Popescu wrote the following on 24.07.2008 22:04 well here it does. Tested with both Debian lenny and Ubuntu hardy. Which version do you use? I'm not the OP. Regards, Andrei I think that doesn't matter in this regard. You have said your passwd doesn't behave as mentioned in the manpage, which would be clearly a bug. I never said *my* passwd doesn't lock, but the OP confirmed that his doesn't but usermod does. I just tested and on my machine 'passwd -l' and 'usermod -L' have the same effect, at least in the /etc/shadow file. Regards, Andrei -- If you can't explain it simply, you don't understand it well enough. (Albert Einstein) signature.asc Description: Digital signature
Re: Cron jobs and root account locked on Lenny
On Jul 24, 6:50 pm, Thilo Six [EMAIL PROTECTED] wrote: well here it does. Tested with both Debian lenny and Ubuntu hardy. Which version do you use? If you have a locked account without that expiry and use either of the above just 'lock' that account again and then take a look at /etc/shadow. I'm on Lenny: klingon:/home/alieno# dpkg -l *passwd*|grep ^ii ii base-passwd 3.5.17 ii passwd 1:4.1.1-2 I previously fixed it using usermod -L as suggested by Sven Joachim, and it was working fine: [EMAIL PROTECTED]:~$ sudo su klingon:/home/alieno# passwd -S root root L 07/23/2008 0 9 7 -1 (no warnings and cronjobs ok) klingon:/home/alieno# passwd -l root Password changed. klingon:/home/alieno# passwd -S root root L 07/23/2008 0 9 7 -1 klingon:/home/alieno# head -1 /etc/shadow root:!$1$MwKDBs6O$H.ZfnYq7C.xzVUdHRmwL31:14084:0:9:7::1: So the passwd -S output is the same. But: klingon:/home/alieno# exit [EMAIL PROTECTED]:~$ sudo su Your account has expired; please contact your system administrator su: User account has expired (Ignored) klingon:/home/alieno# head -1 /etc/shadow root:!$1$MwKDBs6O$H.ZfnYq7C.xzVUdHRmwL31:14084:0:9:7::1: and from syslog: Jul 24 22:44:01 klingon CRON[4998]: User account has expired klingon:/home/alieno# passwd Enter new UNIX password: Retype new UNIX password: passwd: password updated successfully klingon:/home/alieno# passwd -S root root P 07/24/2008 0 9 7 -1 #klingon:/home/alieno# head -1 /etc/shadow root:$1$0pbophfn$B3EpqcFkcezuOYY1D6mNr/:14084:0:9:7::1: klingon:/home/alieno# exit [EMAIL PROTECTED]:~$ sudo su Your account has expired; please contact your system administrator su: User account has expired (Ignored) Locking back with usermod doesn't work anymore! klingon:/home/alieno# usermod -L root klingon:/home/alieno# head -1 /etc/shadow root:!$1$b/Xw.zn6$qMfTmi6zbxeM2nWIDqgMR.:14084:0:9:7::1: klingon:/home/alieno# passwd -S root root L 07/24/2008 0 9 7 -1 klingon:/home/alieno# exit [EMAIL PROTECTED]:~$ sudo su Your account has expired; please contact your system administrator su: User account has expired (Ignored) (and of course root cronjobs not working anymore) It works if i do klingon:/home/alieno# passwd -u root klingon:/home/alieno# passwd -S root P 07/24/2008 0 9 7 -1 klingon:/home/alieno# head -1 /etc/shadow root:$1$b/Xw.zn6$qMfTmi6zbxeM2nWIDqgMR.:14084:0:9:7::: klingon:/home/alieno# usermod -L root klingon:/home/alieno# passwd -S root L 07/24/2008 0 9 7 -1 klingon:/home/alieno# head -1 /etc/shadow root:!$1$b/Xw.zn6$qMfTmi6zbxeM2nWIDqgMR.:14084:0:9:7::: klingon:/home/alieno# exit [EMAIL PROTECTED]:~$ sudo su klingon:/home/alieno# and cronjobs are running ok -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Cron jobs and root account locked on Lenny
A few days ago (due to a broken harddisk) I've installed Lenny from scratch on my laptop. I've copied pretty much every configuration from the old installation (Etch) and everything seems good. Well, everything but a couple of things: first of all, at install time I chose no root login but only a user with sudo grants. So, the root account is locked: [EMAIL PROTECTED]:~$ sudo passwd -S root root L 07/21/2008 0 9 7 -1 Now, first difference I've noticed from the previous (Etch) install is: [EMAIL PROTECTED]:~$ sudo su - Your account has expired; please contact your system administrator su: User account has expired (Ignored) klingon:~# Ok, not so annoying, but I'm not sure it's the right message: shouldn't the account be locked and not expired? Anyway, this leads to the second, more important issue: crond is not running jobs owned by root. For example: syslog: Jul 22 20:17:01 klingon CRON[3060]: User account has expired auth.log: Jul 22 12:17:01 klingon CRON[3060]: pam_unix(cron:account): account root has expired (account expired) Of course, I could unlock root account, but I thought it was good practice to avoid root login from tty/ssh etc, and I'm pretty sure this configuration was working well under Etch. Could this be considered as a bug? Should I report it? Thanks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Cron jobs and root account locked on Lenny
On Wed,23.Jul.08, 00:11:35, Alexander Fortin wrote: [locked root account troubles] Of course, I could unlock root account, but I thought it was good practice to avoid root login from tty/ssh etc, and I'm pretty sure this configuration was working well under Etch. Could this be considered as a bug? Should I report it? I never understood what benefits this brings, the Ubuntu page explaining it didn't convince me. Also, as far as I understand (from the very same page) Ubuntu is patching some (many?) packages to make them work in this configuration. Of course, I may be completely wrong, in which case I'm sure somebody will contradict me with arguments and references :) Regards, Andrei -- If you can't explain it simply, you don't understand it well enough. (Albert Einstein) signature.asc Description: Digital signature
Re: Cron jobs and root account locked on Lenny
On Wed, 23 Jul 2008 13:10:26 +0300 Andrei Popescu [EMAIL PROTECTED] wrote: On Wed,23.Jul.08, 00:11:35, Alexander Fortin wrote: [locked root account troubles] Of course, I could unlock root account, but I thought it was good practice to avoid root login from tty/ssh etc, and I'm pretty sure this configuration was working well under Etch. Could this be considered as a bug? Should I report it? I never understood what benefits this brings, the Ubuntu page explaining it didn't convince me. I agree. I think it's really more annoying than anything. You can still use sudo if you want, but you also have the choice of using su (like, say, when sudo is fubared or you can't log in to your user account...). That said, I don't recommend allowing root login over ssh, but than can be disabled with sshd. -- Brian signature.asc Description: PGP signature
Re: Cron jobs and root account locked on Lenny
On Jul 23, 2:30 pm, Brian Marshall [EMAIL PROTECTED] wrote: That said, I don't recommend allowing root login over ssh, but than can be disabled with sshd. I partially agree with the useless of the feauture, but Debian installer is asking if you want to allow root login or not, so I'm pretty sure I'm not the only one on Lenny with locked root account and root cron jobs running, and I still think this could lead to confusion, especially if you were used to lock root accunt under Etch. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Cron jobs and root account locked on Lenny
On Wed,23.Jul.08, 09:00:22, Alexander Fortin wrote: On Jul 23, 2:30 pm, Brian Marshall [EMAIL PROTECTED] wrote: That said, I don't recommend allowing root login over ssh, but than can be disabled with sshd. I partially agree with the useless of the feauture, but Debian installer is asking if you want to allow root login or not, so I'm Only in expert mode ;) pretty sure I'm not the only one on Lenny with locked root account and root cron jobs running, and I still think this could lead to confusion, especially if you were used to lock root accunt under Etch. I'm not an expert, but a quick read through passwd(1) says account expiry should be set to '1', while your 'passwd -S' shows '-1', just like a normal account. How about trying to lock it again? Regards, Andrei -- If you can't explain it simply, you don't understand it well enough. (Albert Einstein) signature.asc Description: Digital signature
Re: Cron jobs and root account locked on Lenny
On 2008-07-23 18:46 +0200, Andrei Popescu wrote: I'm not an expert, but a quick read through passwd(1) says account expiry should be set to '1', while your 'passwd -S' shows '-1', just like a normal account. How about trying to lock it again? I tried that here, and it did not help. Probably a bug in passwd or pam. Didn't find anything in the BTS, but Ubuntu users see something similar: https://bugs.launchpad.net/ubuntu/+source/shadow/+bug/238755 A comment in that bug suggests using usermod --lock root to lock the root account, that does seem to work. Sven -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Silent Cron Jobs
On Wed, Mar 26, 2008 at 10:05:53AM -0400, Curt Howland wrote: Well, yes, it works, but I get mail sent to me by cron explaining that the job executed successfully. I'd prefer not to get the mail. I don't get mail for any of the other jobs in cron.daily, and I don't understand enough of bash scripting to see how mine is different from the others. One way to do it is to add ' /dev/null 21' to the crontab entry. Regards Johann -- Johann Spies Telefoon: 021-808 4036 Informasietegnologie, Universiteit van Stellenbosch Casting all your care upon him; for he careth for you. I Peter 5:7 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Silent Cron Jobs
Hi, I tried to whip up a small cron job, I put a short script in /etc/cron.daily thinking that this would work. Well, yes, it works, but I get mail sent to me by cron explaining that the job executed successfully. I'd prefer not to get the mail. I don't get mail for any of the other jobs in cron.daily, and I don't understand enough of bash scripting to see how mine is different from the others. If all else fails I could just add a line to /etc/crontab, but I think the Debian way is so very much better coordinated and elegant. just add this line at the beggining of your script : exec /dev/null this will discard any standard output and should be enough (you only get a mail when your program produces some output). You can also discard stderr by adding 21 at the end of this line, but this is not a good idea as you could miss some important error message. -- Cédric Lucantis
Re: Silent Cron Jobs
Hi, afaik cron (by default) mails all output from a script. If i create a cronjob I usually dump all stdout (just redirect it to /dev/null) But I want to be informed of any errors so I keep stderr. example: # this will get mailed echo My cool cron script # this will not mail stdout, but stderr (see below for an example) echo My cooler cron script /dev/null # this will send you a mail because there was output on stderr, if there was output on stdout it wouldn't mail /nonexistant/echo My failing cron script /dev/null Not this is untested and just a quick writeup but the general rule should apply hth martin On Wed, Mar 26, 2008 at 3:05 PM, Curt Howland [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi. I tried to whip up a small cron job, I put a short script in /etc/cron.daily thinking that this would work. Well, yes, it works, but I get mail sent to me by cron explaining that the job executed successfully. I'd prefer not to get the mail. I don't get mail for any of the other jobs in cron.daily, and I don't understand enough of bash scripting to see how mine is different from the others. If all else fails I could just add a line to /etc/crontab, but I think the Debian way is so very much better coordinated and elegant. Curt- - -- Treason! http://blog.mises.org/archives/007926.asp -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iQEVAwUBR+pYQi9Y35yItIgBAQJkcgf/c8y5Sbd4WkNChuA2muNkprTVFy6JkMIs 8gHQReKiEJH6R4QHVTWRtElqjWHDcry15lCV6h2AIN5w+FIPKmvFcViA3rGk5jK3 Jr/NzC3twwtRaxhvUKDNrfr0VHmAjHeVxBdBHt287zejzDc9TCECcPBderco82rO OwmDs7WuNzQrWZSz8VDGFhjxdJrdhUIVzgeSamD0xtt65gNvUj6GN2YxGeUODlTk V9XfO6vxsrK3chBrag7Cz4EA5pPsyK3QoMtr/NrCPSBPbE2dT38hZAtz3dIN4yq1 ve2fmP7HMF24TtKhTKxkmKN6Qm3uOT8B9qiZ7VPrJsvldcSJVAHuAA== =IgSr -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- http://tumblr.marcher.name https://twitter.com/MartinMarcher http://www.xing.com/profile/Martin_Marcher http://www.linkedin.com/in/martinmarcher You are not free to read this message, by doing so, you have violated my licence and are required to urinate publicly. Thank you. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Silent Cron Jobs
On Wed, Mar 26, 2008 at 10:05 AM, Curt Howland [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi. I tried to whip up a small cron job, I put a short script in /etc/cron.daily thinking that this would work. Well, yes, it works, but I get mail sent to me by cron explaining that the job executed successfully. I'd prefer not to get the mail. I don't get mail for any of the other jobs in cron.daily, and I don't understand enough of bash scripting to see how mine is different from the others. From the cron manpage: When executing commands, any output is mailed to the owner of the crontab (or to the user named in the MAILTO environment variable in the crontab, if such exists). So, either suppress output with something like 'cmd /dev/null 21' or put 'MAILTO=' in the script. I think :) Patrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Fwd: Silent Cron Jobs
-- Forwarded message -- From: Strong Cypher [EMAIL PROTECTED] Date: Thu, 27 Mar 2008 09:13:54 +0100 Subject: Re: Silent Cron Jobs To: Curt Howland [EMAIL PROTECTED] your script need to drop any think from output to be able to drop mail sending you have to redirect any command line to a file or null node like this cmd /dev/null On 3/26/08, Curt Howland [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi. I tried to whip up a small cron job, I put a short script in /etc/cron.daily thinking that this would work. Well, yes, it works, but I get mail sent to me by cron explaining that the job executed successfully. I'd prefer not to get the mail. I don't get mail for any of the other jobs in cron.daily, and I don't understand enough of bash scripting to see how mine is different from the others. If all else fails I could just add a line to /etc/crontab, but I think the Debian way is so very much better coordinated and elegant. Curt- - -- Treason! http://blog.mises.org/archives/007926.asp -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iQEVAwUBR+pYQi9Y35yItIgBAQJkcgf/c8y5Sbd4WkNChuA2muNkprTVFy6JkMIs 8gHQReKiEJH6R4QHVTWRtElqjWHDcry15lCV6h2AIN5w+FIPKmvFcViA3rGk5jK3 Jr/NzC3twwtRaxhvUKDNrfr0VHmAjHeVxBdBHt287zejzDc9TCECcPBderco82rO OwmDs7WuNzQrWZSz8VDGFhjxdJrdhUIVzgeSamD0xtt65gNvUj6GN2YxGeUODlTk V9XfO6vxsrK3chBrag7Cz4EA5pPsyK3QoMtr/NrCPSBPbE2dT38hZAtz3dIN4yq1 ve2fmP7HMF24TtKhTKxkmKN6Qm3uOT8B9qiZ7VPrJsvldcSJVAHuAA== =IgSr -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Silent Cron Jobs
On Wed, 26 Mar 2008 20:40:12 +0100, Curt Howland wrote: I tried to whip up a small cron job, I put a short script in /etc/cron.daily thinking that this would work. Well, yes, it works, but I get mail sent to me by cron explaining that the job executed successfully. http://www.linuxhelp.net/guides/cron/ -- Stephen Patterson :: [EMAIL PROTECTED] :: http://patter.mine.nu/ GPG: B416F0DE :: Jabber: [EMAIL PROTECTED] Don't be silly, Minnie. Who'd be walking round these cliffs with a gas oven? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Silent Cron Jobs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Curt Howland wrote: | Hi. | | I tried to whip up a small cron job, I put a short script | in /etc/cron.daily thinking that this would work. | | Well, yes, it works, but I get mail sent to me by cron explaining that | the job executed successfully. | | I'd prefer not to get the mail. I don't get mail for any of the other | jobs in cron.daily, and I don't understand enough of bash scripting | to see how mine is different from the others. | | If all else fails I could just add a line to /etc/crontab, but I think | the Debian way is so very much better coordinated and elegant. | | Curt- | I send the output of such cron jobs to /dev/null. that is ~ /dev/null 21 - -- -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH6tcsu4tRirKTPYwRAuOGAJ9g3Xc6fZWKzZy4o+pifO4KzilX0ACeMdE1 6UygOGX97U2j1twC9t2fkMk= =Tn4i -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Silent Cron Jobs
On 3/26/08, Curt Howland [EMAIL PROTECTED] wrote: I tried to whip up a small cron job, I put a short script in /etc/cron.daily thinking that this would work. Well, yes, it works, but I get mail sent to me by cron explaining that the job executed successfully. That's odd, usually cron only sends mail if the job failed or there was output. Is there output? Even if it's a single space or a blank line? I'd prefer not to get the mail. I don't get mail for any of the other jobs in cron.daily, and I don't understand enough of bash scripting to see how mine is different from the others. You can always dump the output to /dev/null. In case you don't know: | command_here /dev/null 21 This has the disadvantage that legitimate messages may be discarded. Your call. Tom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Silent Cron Jobs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thursday 27 March 2008, Patter [EMAIL PROTECTED] was heard to say: http://www.linuxhelp.net/guides/cron/ Thanks for all the help, everyone. Indeed, for this, redirecting stderr is just fine too, so cmd /dev/null 21 is exactly what I need. Much obliged, Curt- - -- Treason! http://blog.mises.org/archives/007926.asp -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iQEVAwUBR+usoy9Y35yItIgBAQKWpwf+NZeG7PkuSakWdl3sIiQvbkNZoX7NkS7L RUX6KBbrISyYx5DSM+nPlEWRH+oTMvg6HnO6fq1Afdm9yLQRgHbCj+ppufRpx2u6 z5YY3x4RVbVvKkhcfIQYABvBJtMm+xtXq5sjVlWmyFvpSLdbz0joGfm8NEFQujNW kRFkj0waf6webZet6aybJ73w1XI5pXHLhhwUjCtj19u1QiBvq0cDcPTudiOlQc+q Pgr7RayrCnr0G+3gyqvuqJVdwsxWithcHywUL4GX5lUKbO9ArG5D/lL8d1bKjyaF 74TYhrmQQYyRbq4XKy8Ah3ORWAB994y34onoDrHAf7Hsxbjym/rsuQ== =DEv1 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Silent Cron Jobs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi. I tried to whip up a small cron job, I put a short script in /etc/cron.daily thinking that this would work. Well, yes, it works, but I get mail sent to me by cron explaining that the job executed successfully. I'd prefer not to get the mail. I don't get mail for any of the other jobs in cron.daily, and I don't understand enough of bash scripting to see how mine is different from the others. If all else fails I could just add a line to /etc/crontab, but I think the Debian way is so very much better coordinated and elegant. Curt- - -- Treason! http://blog.mises.org/archives/007926.asp -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iQEVAwUBR+pYQi9Y35yItIgBAQJkcgf/c8y5Sbd4WkNChuA2muNkprTVFy6JkMIs 8gHQReKiEJH6R4QHVTWRtElqjWHDcry15lCV6h2AIN5w+FIPKmvFcViA3rGk5jK3 Jr/NzC3twwtRaxhvUKDNrfr0VHmAjHeVxBdBHt287zejzDc9TCECcPBderco82rO OwmDs7WuNzQrWZSz8VDGFhjxdJrdhUIVzgeSamD0xtt65gNvUj6GN2YxGeUODlTk V9XfO6vxsrK3chBrag7Cz4EA5pPsyK3QoMtr/NrCPSBPbE2dT38hZAtz3dIN4yq1 ve2fmP7HMF24TtKhTKxkmKN6Qm3uOT8B9qiZ7VPrJsvldcSJVAHuAA== =IgSr -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
continuation character in cron jobs
I'd like to use the continuation character \ in a cron job, but I get an error when I do. I use crontab -e to edit the crontab and have this sort of thing: 30 5 * * * script varable variable \ variable-text when I try to save, I get this: crontab: installing new crontab /tmp/crontab.kZ7WHF/crontab:122: bad minute errors in crontab file, can't install Does anyone know if there's a way to get cron to accept a continuation character? This is Debian Sid's (vixie) cron 3.0pl1-100. Cheers, David -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: continuation character in cron jobs
On Sun, Oct 21, 2007 at 12:03:30PM -0700, David Liontooth wrote: I'd like to use the continuation character \ in a cron job, but I get an error when I do. I use crontab -e to edit the crontab and have this sort of thing: 30 5 * * * script varable variable \ variable-text when I try to save, I get this: crontab: installing new crontab /tmp/crontab.kZ7WHF/crontab:122: bad minute errors in crontab file, can't install Does anyone know if there's a way to get cron to accept a continuation character? man (5) crontab The ``sixth'' field (the rest of the line) specifies the command to be run. The entire command portion of the line, up to a newline or % character, will be executed by /bin/sh or by the shell specified in the SHELL variable of the crontab file. Percent-signs (%) in the command, unless escaped with backslash (\), will be changed into newline characters, and all data after the first % will be sent to the command as standard input. There is no way to split a single command line onto multiple lines, like the shell's trailing \. -- Exhilaration is that feeling you get just after a great idea hits you, and just before you realize what's wrong with it. -- Anonymous Rick Pasotto[EMAIL PROTECTED]http://www.niof.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: continuation character in cron jobs
Rick Pasotto wrote: On Sun, Oct 21, 2007 at 12:03:30PM -0700, David Liontooth wrote: I'd like to use the continuation character \ in a cron job, but I get an error when I do. I use crontab -e to edit the crontab and have this sort of thing: 30 5 * * * script varable variable \ variable-text when I try to save, I get this: crontab: installing new crontab /tmp/crontab.kZ7WHF/crontab:122: bad minute errors in crontab file, can't install Does anyone know if there's a way to get cron to accept a continuation character? man (5) crontab The ``sixth'' field (the rest of the line) specifies the command to be run. The entire command portion of the line, up to a newline or % character, will be executed by /bin/sh or by the shell specified in the SHELL variable of the crontab file. Percent-signs (%) in the command, unless escaped with backslash (\), will be changed into newline characters, and all data after the first % will be sent to the command as standard input. There is no way to split a single command line onto multiple lines, like the shell's trailing \. Thanks! Really appreciate the info. I searched the man pages for 'continuation' but missed this. Too bad! Cheers, Dave -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Archiver Cron Jobs
On Tue, Feb 27, 2007 at 12:13:11AM -0500 or thereabouts, Michael Pobega wrote: I'm pretty new to cron jobs, and I've just started playing around with them pretty recently. Hi Michael: Cool. I'd like to be able to create a cron job that does a weekly archive of all of my folders in ~/mail. The way I have my mail set up is one folder per box, for example my folders are: ~/mail/inbox ~/mail/debian-user ~/mail/sent I'd like the Cron job to archive these on a weekly basis, but not exactly on a weekly basis. Instead of reinventing the wheel; Why not use something like archivemail? # aptitude show archivemail Package: archivemail State: installed Automatically installed: no Version: 0.7.0-1 Priority: optional Section: mail Maintainer: Joey Hess [EMAIL PROTECTED] Uncompressed Size: 139k Depends: python Description: archive and compress your old email Archivemail moves old mail out of a mailbox (in Maildir, MH, or mbox format, or via IMAP) and archives it in a compressed mbox-format mailbox file. It is well suited to be run from cron for automatic archiving of your old mail. It runs via cron as well, and the included readmes will help you set the syntax up for whatever time period floats yer boat. -- Regards Stephen A. Encrypted/Signed e-mail accepted (GPG or PGP) -- Key ID: 978BA045 + Having nothing, nothing can he lose. -- William Shakespeare, Henry VI + signature.asc Description: Digital signature
Re: Archiver Cron Jobs
On Tue, Feb 27, 2007 at 09:34:04AM -0500, Stephen wrote: On Tue, Feb 27, 2007 at 12:13:11AM -0500 or thereabouts, Michael Pobega wrote: I'd like to be able to create a cron job that does a weekly archive of all of my folders in ~/mail. The way I have my mail set up is one folder per box, for example my folders are: ~/mail/inbox ~/mail/debian-user ~/mail/sent I'd like the Cron job to archive these on a weekly basis, but not exactly on a weekly basis. Instead of reinventing the wheel; Why not use something like archivemail? # aptitude show archivemail Package: archivemail State: installed Automatically installed: no Version: 0.7.0-1 Priority: optional Section: mail Maintainer: Joey Hess [EMAIL PROTECTED] Uncompressed Size: 139k Depends: python Description: archive and compress your old email Archivemail moves old mail out of a mailbox (in Maildir, MH, or mbox format, or via IMAP) and archives it in a compressed mbox-format mailbox file. It is well suited to be run from cron for automatic archiving of your old mail. Wow, nice find! I'll definitely toy around with this sometime today. Oh, and it's in maildir format, since that's the only way I could get Mutt to do what I wanted (Mbox didn't seem to work right the way I was trying to set it up, although I don't mind using maildir instead of mbox). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Archiver Cron Jobs
I'm pretty new to cron jobs, and I've just started playing around with them pretty recently. I'd like to be able to create a cron job that does a weekly archive of all of my folders in ~/mail. The way I have my mail set up is one folder per box, for example my folders are: ~/mail/inbox ~/mail/debian-user ~/mail/sent I'd like the Cron job to archive these on a weekly basis, but not exactly on a weekly basis. The part that is tough for me to figure out is...I want the cron job to only archive when the file is a week old. So I'd need it to do a daily check of my folders and their contents (And the dates they were created), and if they're older than seven days old move them into ~/mail/archives/folder (Archive would be a mirror image of the directories in ~/mail). I imagine something like this can be done in bash or similar, but I have no experience doing bash. Thanks for your time, Michael Pobega -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Archiver Cron Jobs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/26/07 23:13, Michael Pobega wrote: I'm pretty new to cron jobs, and I've just started playing around with them pretty recently. I'd like to be able to create a cron job that does a weekly archive of all of my folders in ~/mail. The way I have my mail set up is one folder per box, for example my folders are: ~/mail/inbox ~/mail/debian-user ~/mail/sent These are mbox files? It would help see the complete directory structure. I'd like the Cron job to archive these on a weekly basis, but not exactly on a weekly basis. The part that is tough for me to figure out is...I want the cron job to only archive when the file is a week old. So I'd need it to do a daily check of my folders and their contents (And the dates they were created), and if they're older than seven days old move them into ~/mail/archives/folder (Archive would be a mirror image of the directories in ~/mail). If these are mbox files, there will be a problem if you try to Receive new emails (or compact folders or move mails from folder to folder, etc) while the job happens to be running. I imagine something like this can be done in bash or similar, but I have no experience doing bash. Yes, but... there's always a spanner in the gears. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFF48BpS9HxQb37XmcRAlDUAJ9SyoPnO1YWn6aZy83wZHxUdtHmqwCglhCa eVWvzt9EIToQmBD+kKwFSe8= =jz4t -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
