[expert] cron & smbtar

[Colin Jenkins]

Hi all ,
I have asked this question on the newbie list, but have had no luck so
far
The script below works ok from the command line but when I run it as a
cron job, it starts ok, but stops after backing up a few directories.
Any ideas what I'm doing wrong? is it a bug with cron?
btw, I'm using mdk9 and the files being backed up are on an nt server,
but have had the same problem backing up an xp box.
I had the same problem with drakebackup, tar and cp

#!/bin/sh
smbtar -s elendil -t /dev/st0 -x "stuff1" -v -i  -X System\ Volume\ Information
mt -f /dev/st0 offline  


-- 
regards,
 Colin

mailto:[EMAIL PROTECTED]

 
8:00pm up 8 days, 3:46, 2 users, load average: 0.00, 0.00, 0.00
No matter who you are, some scholar can show you the great idea you had was had by 
someone before you.
 ..registered linux user #223862 ..
   _ 




Want to buy your Pack or Services from MandrakeSoft? 
Go to http://www.mandrakestore.com

Re: [expert] cron & smbtar

[Jack Coates]

Argh, another broken reply-to... (yes, I know it's RFC-compliant to do
this... it's also RFC-compliant to have a non-contiguous IPv4 subnet
mask and you don't see people doing _that_ little bit of insanity do
you?)

On Thu, 2002-12-26 at 01:55, Colin Jenkins wrote:
> Hi all ,
> I have asked this question on the newbie list, but have had no luck so
> far
> The script below works ok from the command line but when I run it as a
> cron job, it starts ok, but stops after backing up a few directories.
> Any ideas what I'm doing wrong? is it a bug with cron?
> btw, I'm using mdk9 and the files being backed up are on an nt server,
> but have had the same problem backing up an xp box.
> I had the same problem with drakebackup, tar and cp
> 
> #!/bin/sh
> smbtar -s elendil -t /dev/st0 -x "stuff1" -v -i  -X System\ Volume\ Information
> mt -f /dev/st0 offline  
> 

usually this sort of error is due to differing environment or
permissions. If it's a user's crontab ($crontab -e) then you need to su
to that user and debug from there. If it's root's crontab (#vi
/etc/crontab) then make sure root can run it from command line.

Another possibility is that the network is fine when you're debugging,
but congested by other traffic when your cron job runs. Try doing
something less sensitive to network issues, like rsync'ing to a temp
directory a couple of times, then tar'ing that temp directory to the
tape.

> 
> -- 
> regards,
>  Colin
> 
> mailto:[EMAIL PROTECTED]
> 
>  
> 8:00pm up 8 days, 3:46, 2 users, load average: 0.00, 0.00, 0.00
> No matter who you are, some scholar can show you the great idea you had was had by 
>someone before you.
>  ..registered linux user #223862 ..
>_ 
> 
> 
> 
> 
> 

> Want to buy your Pack or Services from MandrakeSoft? 
> Go to http://www.mandrakestore.com
-- 
Jack Coates
Monkeynoodle: A Scientific Venture...



Want to buy your Pack or Services from MandrakeSoft? 
Go to http://www.mandrakestore.com

Re: [expert] cron & smbtar

[J. Grant]

is it really broken? The reply-to should not be changed/added by the
list.  It is the mdk config problem I believe.

JG

Jack Coates wrote:

Argh, another broken reply-to... (yes, I know it's RFC-compliant to do
this... it's also RFC-compliant to have a non-contiguous IPv4 subnet
mask and you don't see people doing _that_ little bit of insanity do
you?)

On Thu, 2002-12-26 at 01:55, Colin Jenkins wrote:


Hi all ,
I have asked this question on the newbie list, but have had no luck so
far
The script below works ok from the command line but when I run it as a
cron job, it starts ok, but stops after backing up a few directories.
Any ideas what I'm doing wrong? is it a bug with cron?
btw, I'm using mdk9 and the files being backed up are on an nt server,
but have had the same problem backing up an xp box.
I had the same problem with drakebackup, tar and cp

#!/bin/sh
smbtar -s elendil -t /dev/st0 -x "stuff1" -v -i  -X System\ Volume\ Information
mt -f /dev/st0 offline  



usually this sort of error is due to differing environment or
permissions. If it's a user's crontab ($crontab -e) then you need to su
to that user and debug from there. If it's root's crontab (#vi
/etc/crontab) then make sure root can run it from command line.

Another possibility is that the network is fine when you're debugging,
but congested by other traffic when your cron job runs. Try doing
something less sensitive to network issues, like rsync'ing to a temp
directory a couple of times, then tar'ing that temp directory to the
tape.



--
regards,
Colin

mailto:[EMAIL PROTECTED]

    
8:00pm up 8 days, 3:46, 2 users, load average: 0.00, 0.00, 0.00
No matter who you are, some scholar can show you the great idea you had was had by someone before you.
..registered linux user #223862 ..
  _ 








Want to buy your Pack or Services from MandrakeSoft? 
Go to http://www.mandrakestore.com




Want to buy your Pack or Services from MandrakeSoft? 
Go to http://www.mandrakestore.com




Want to buy your Pack or Services from MandrakeSoft? 
Go to http://www.mandrakestore.com

Re: [expert] cron & smbtar

[Jack Coates]

This is a religion issue, really. I usually try to avoid those and live
quietly with my choices, but this one bugs me because it causes either
needlessly duplicated mail or replies to questions to be
unpublished/unarchived.

The RFCs for mailing lists and many MUA authors/contributors feel that
mailing lists should not munge REPLY-TO because the end-user and MUA set
it and no other authority should be able to override that desire.

The administrators of and frequent contributors to mailing lists love
reply-to munging because it prevents needless duplication of mail and
helps to keep discussion threads in the mailing list, where they can be
archived and publicly posted.

On the one hand: pedantically correct behavior; on the other:
rule-bending for the sake of practical usage. The pedantics will rightly
point out that workarounds exist. In order to avoid seeing the needless
duplication of email, simply have every user of the mailing list set up
their own Unix mail server where they can install procmail and configure
it to find and delete duplicated email. In order to make sure that
everything is archived simply instruct all list users to always use
reply-all, at which point another set of people is going to get upset
because they're getting duplicate messages, at which point everyone else
flames them for not have their own Unix mail server and procmail setup
:-)

The best solution? Removing reply-to functionality from MUAs is tempting
but impractical; even though it is almost an anachronism in today's
world of ubiquitous email services, those who rely on it do rely on it.
Removing reply-to munging from MLM software would represent a pretty
ugly choice for the reasons above. (Hmm, in light of the ongoing
discussion of Mandrake's money problems, would they be happy about a
two-fold increase in the amount of email traffic? I know I wouldn't be.)
Changing the standard so that MLMs are allowed to munge reply-to but
MTAs are still prohibited? Sounds reasonable to me, and no one has yet
given me a valid reason not to (which doesn't mean that it doesn't
exist).

So in my opinion, it is not mdk's config which is broken, but rather the
standard which they are rightly not adhering to; just as, in my original
example, anyone who fully adheres to the IP RFC's subnet mask guidelines
needs to have their head examined.



Jack

On Thu, 2002-12-26 at 17:51, J. Grant wrote:
> is it really broken? The reply-to should not be changed/added by the
> list.  It is the mdk config problem I believe.
> 
> JG
> 
> Jack Coates wrote:
> > Argh, another broken reply-to... (yes, I know it's RFC-compliant to do
> > this... it's also RFC-compliant to have a non-contiguous IPv4 subnet
> > mask and you don't see people doing _that_ little bit of insanity do
> > you?)
> > 
> > On Thu, 2002-12-26 at 01:55, Colin Jenkins wrote:
> > 
> >>Hi all ,
> >>I have asked this question on the newbie list, but have had no luck so
> >>far
> >>The script below works ok from the command line but when I run it as a
> >>cron job, it starts ok, but stops after backing up a few directories.
> >>Any ideas what I'm doing wrong? is it a bug with cron?
> >>btw, I'm using mdk9 and the files being backed up are on an nt server,
> >>but have had the same problem backing up an xp box.
> >>I had the same problem with drakebackup, tar and cp
> >>
> >>#!/bin/sh
> >>smbtar -s elendil -t /dev/st0 -x "stuff1" -v -i  -X System\ Volume\ Information
> >>mt -f /dev/st0 offline  
> >>
> > 
> > 
> > usually this sort of error is due to differing environment or
> > permissions. If it's a user's crontab ($crontab -e) then you need to su
> > to that user and debug from there. If it's root's crontab (#vi
> > /etc/crontab) then make sure root can run it from command line.
> > 
> > Another possibility is that the network is fine when you're debugging,
> > but congested by other traffic when your cron job runs. Try doing
> > something less sensitive to network issues, like rsync'ing to a temp
> > directory a couple of times, then tar'ing that temp directory to the
> > tape.
> > 
> > 
> >>-- 
> >>regards,
> >> Colin
> >>
> >>mailto:[EMAIL PROTECTED]
> >>
> >> 
> >>8:00pm up 8 days, 3:46, 2 users, load average: 0.00, 0.00, 0.00
> >>No matter who you are, some scholar can show you the great idea you had was had by 
>someone before you.
> >> ..registered linux user #223862 ..
> >>   _ 
> >>
> >>
> >>
> >>
> >>
> > 
> > 
> >>Want to buy your Pack or Services from MandrakeSoft? 
> >>Go to http://www.mandrakestore.com
> >>
> >>
> >>
> >>
> >>Want to buy your Pack or Services from MandrakeSoft? 
> >>Go to http://www.mandrakestore.com
> 
> 
> 
> 
> 

> Want to buy your Pack or Services from MandrakeSoft? 
> Go to http://www.mandrakestore.com
-- 
Jack Coates
Monk

Re: [expert] cron & smbtar

[J. Grant]

Hello Jack,

Thank you for the infomative reply. Clearly you have considered this 
more than me, but surely this is what the special headers are for?

List-Post: 

It is the users client that is broken if it does not support list 
replies correctly in this case.

Because this reply-to is changed "reply all" does not work, and I have 
to manually add addresses.  I agree that maybe mdk is making the best of 
the current bad situation, but if mdk changed the list policy, this 
would mean all the email clients got fixed to follow those darn RFC's! 
Which is how it should be. We did not end up where we are here by 
changing standards.

Best regards

JG

Jack Coates wrote:

This is a religion issue, really. I usually try to avoid those and live
quietly with my choices, but this one bugs me because it causes either
needlessly duplicated mail or replies to questions to be
unpublished/unarchived.

The RFCs for mailing lists and many MUA authors/contributors feel that
mailing lists should not munge REPLY-TO because the end-user and MUA set
it and no other authority should be able to override that desire.

The administrators of and frequent contributors to mailing lists love
reply-to munging because it prevents needless duplication of mail and
helps to keep discussion threads in the mailing list, where they can be
archived and publicly posted.

On the one hand: pedantically correct behavior; on the other:
rule-bending for the sake of practical usage. The pedantics will rightly
point out that workarounds exist. In order to avoid seeing the needless
duplication of email, simply have every user of the mailing list set up
their own Unix mail server where they can install procmail and configure
it to find and delete duplicated email. In order to make sure that
everything is archived simply instruct all list users to always use
reply-all, at which point another set of people is going to get upset
because they're getting duplicate messages, at which point everyone else
flames them for not have their own Unix mail server and procmail setup
:-)

The best solution? Removing reply-to functionality from MUAs is tempting
but impractical; even though it is almost an anachronism in today's
world of ubiquitous email services, those who rely on it do rely on it.
Removing reply-to munging from MLM software would represent a pretty
ugly choice for the reasons above. (Hmm, in light of the ongoing
discussion of Mandrake's money problems, would they be happy about a
two-fold increase in the amount of email traffic? I know I wouldn't be.)
Changing the standard so that MLMs are allowed to munge reply-to but
MTAs are still prohibited? Sounds reasonable to me, and no one has yet
given me a valid reason not to (which doesn't mean that it doesn't
exist).

So in my opinion, it is not mdk's config which is broken, but rather the
standard which they are rightly not adhering to; just as, in my original
example, anyone who fully adheres to the IP RFC's subnet mask guidelines
needs to have their head examined.



Jack

On Thu, 2002-12-26 at 17:51, J. Grant wrote:


is it really broken? The reply-to should not be changed/added by the
list.  It is the mdk config problem I believe.

JG

Jack Coates wrote:


Argh, another broken reply-to... (yes, I know it's RFC-compliant to do
this... it's also RFC-compliant to have a non-contiguous IPv4 subnet
mask and you don't see people doing _that_ little bit of insanity do
you?)

On Thu, 2002-12-26 at 01:55, Colin Jenkins wrote:



Hi all ,
I have asked this question on the newbie list, but have had no luck so
far
The script below works ok from the command line but when I run it as a
cron job, it starts ok, but stops after backing up a few directories.
Any ideas what I'm doing wrong? is it a bug with cron?
btw, I'm using mdk9 and the files being backed up are on an nt server,
but have had the same problem backing up an xp box.
I had the same problem with drakebackup, tar and cp

#!/bin/sh
smbtar -s elendil -t /dev/st0 -x "stuff1" -v -i  -X System\ Volume\ Information
mt -f /dev/st0 offline  



usually this sort of error is due to differing environment or
permissions. If it's a user's crontab ($crontab -e) then you need to su
to that user and debug from there. If it's root's crontab (#vi
/etc/crontab) then make sure root can run it from command line.

Another possibility is that the network is fine when you're debugging,
but congested by other traffic when your cron job runs. Try doing
something less sensitive to network issues, like rsync'ing to a temp
directory a couple of times, then tar'ing that temp directory to the
tape.




--
regards,
Colin

mailto:[EMAIL PROTECTED]

   
8:00pm up 8 days, 3:46, 2 users, load average: 0.00, 0.00, 0.00
No matter who you are, some scholar can show you the great idea you had was had by someone before you.
..registered linux user #223862 ..
 

Re: [expert] cron & smbtar

[Jack Coates]

On Fri, 2002-12-27 at 07:04, J. Grant wrote:
> Hello Jack,
> 
> Thank you for the infomative reply. Clearly you have considered this 
> more than me, but surely this is what the special headers are for?
> 
> List-Post: 

3.4. List-Post

The List-Post field describes the method for posting to the list. This
is typically the address of the list, but MAY be a moderator, or
potentially some other form of submission. For the special case of a
list that does not allow posting (e.g., an announcements list), the
List-Post field may contain the special value "NO".

   Examples:

 List-Post: 
 List-Post:  (Postings are Moderated)
 List-Post: 
 List-Post: NO (posting not allowed on this list)


I don't think that can be read as "MUAs should override Reply-To with
the List-Post value," which is probably why they don't.

> 
> It is the users client that is broken if it does not support list 
> replies correctly in this case.
> 
> Because this reply-to is changed "reply all" does not work, and I have 
> to manually add addresses.  I agree that maybe mdk is making the best of 
> the current bad situation, but if mdk changed the list policy, this 
> would mean all the email clients got fixed to follow those darn RFC's! 

I'd say everything's in compliance with 2369 there. To me the big
question is why to use Reply-To? I'm of the impression that it was
originally intended to support sending mail from account A when you want
to receive mail at account B. When account B is easily reached via
webmail, ssh, &c, and account A can easily be configured to forward its
mail to account B, I can't see why anyone would still want to do it this
way. But then, I don't see why people do a lot of things, so oh well.

> Which is how it should be. We did not end up where we are here by 
> changing standards.

Err... whither RFC 822? Oh yeah, obsoleted by 2822. Standards are only
standard because a majority of people agree to treat them as such, which
will only happen while the standard meets most of the needs of those
people. Needs change, the people with clout to make decisions change,
and standards therefore change to.

> 
> Best regards
> 
> JG
> 
> Jack Coates wrote:
> > 
> > This is a religion issue, really. I usually try to avoid those and live
> > quietly with my choices, but this one bugs me because it causes either
> > needlessly duplicated mail or replies to questions to be
> > unpublished/unarchived.
> > 
> > The RFCs for mailing lists and many MUA authors/contributors feel that
> > mailing lists should not munge REPLY-TO because the end-user and MUA set
> > it and no other authority should be able to override that desire.
> > 
> > The administrators of and frequent contributors to mailing lists love
> > reply-to munging because it prevents needless duplication of mail and
> > helps to keep discussion threads in the mailing list, where they can be
> > archived and publicly posted.
> > 
> > On the one hand: pedantically correct behavior; on the other:
> > rule-bending for the sake of practical usage. The pedantics will rightly
> > point out that workarounds exist. In order to avoid seeing the needless
> > duplication of email, simply have every user of the mailing list set up
> > their own Unix mail server where they can install procmail and configure
> > it to find and delete duplicated email. In order to make sure that
> > everything is archived simply instruct all list users to always use
> > reply-all, at which point another set of people is going to get upset
> > because they're getting duplicate messages, at which point everyone else
> > flames them for not have their own Unix mail server and procmail setup
> > :-)
> > 
> > The best solution? Removing reply-to functionality from MUAs is tempting
> > but impractical; even though it is almost an anachronism in today's
> > world of ubiquitous email services, those who rely on it do rely on it.
> > Removing reply-to munging from MLM software would represent a pretty
> > ugly choice for the reasons above. (Hmm, in light of the ongoing
> > discussion of Mandrake's money problems, would they be happy about a
> > two-fold increase in the amount of email traffic? I know I wouldn't be.)
> > Changing the standard so that MLMs are allowed to munge reply-to but
> > MTAs are still prohibited? Sounds reasonable to me, and no one has yet
> > given me a valid reason not to (which doesn't mean that it doesn't
> > exist).
> > 
> > So in my opinion, it is not mdk's config which is broken, but rather the
> > standard which they are rightly not adhering to; just as, in my original
> > example, anyone who fully adheres to the IP RFC's subnet mask guidelines
> > needs to have their head examined.
> > 
> > 
> > 
> > Jack
> > 
> > On Thu, 2002-12-26 at 17:51, J. Grant wrote:
> > 
> >>is it really broken? The reply-to should not be changed/added by the
> >>list

Re[2]: [expert] cron & smbtar

[Colin Jenkins]

Hello Jack,

Friday, December 27, 2002, 3:11:36 PM, you wrote:
of people is going to get upset

>> > 
>> > usually this sort of error is due to differing environment or
>> > permissions. If it's a user's crontab ($crontab -e) then you need to su
>> > to that user and debug from there. If it's root's crontab (#vi
>> > /etc/crontab) then make sure root can run it from command line.
>> > 
>> > Another possibility is that the network is fine when you're debugging,
>> > but congested by other traffic when your cron job runs. Try doing
>> > something less sensitive to network issues, like rsync'ing to a temp
>> > directory a couple of times, then tar'ing that temp directory to the
>> > tape.
>> >
>>
this is really starting to bug me,
I tried  the script below, runs from command line or clicking on icon,
but when run as cron job (as root) , it copies 2.9Mb and stops. there
are no errors in cron logs. AFIK it's not a network problem as no one else was
using it.
Unless I'm missing something obvious, it must be a bug with cron.
I have tried the same with 2 different networks, with the same
results. I'm using samba 2.2.6 on mdk9 with all the latest updates

#!/bin/sh
cp -rpuv /mnt/windows /mnt/hal

-- 
Best regards,
 Colinmailto:[EMAIL PROTECTED]
 
10:00pm up 9 days, 5:46, 2 users, load average: 0.01, 0.05, 0.04
I came to MIT to get an education for myself and a diploma for my mother.
 ..registered linux user #223862 ..
   _ 




Want to buy your Pack or Services from MandrakeSoft? 
Go to http://www.mandrakestore.com

Re: Re[2]: [expert] cron & smbtar

[Jack Coates]

On Fri, 2002-12-27 at 03:56, Colin Jenkins wrote:
> Hello Jack,
> 
> Friday, December 27, 2002, 3:11:36 PM, you wrote:
> of people is going to get upset
> 
> >> > 
> >> > usually this sort of error is due to differing environment or
> >> > permissions. If it's a user's crontab ($crontab -e) then you need to su
> >> > to that user and debug from there. If it's root's crontab (#vi
> >> > /etc/crontab) then make sure root can run it from command line.
> >> > 
> >> > Another possibility is that the network is fine when you're debugging,
> >> > but congested by other traffic when your cron job runs. Try doing
> >> > something less sensitive to network issues, like rsync'ing to a temp
> >> > directory a couple of times, then tar'ing that temp directory to the
> >> > tape.
> >> >
> >>
> this is really starting to bug me,
> I tried  the script below, runs from command line or clicking on icon,
> but when run as cron job (as root) , it copies 2.9Mb and stops. there
> are no errors in cron logs. AFIK it's not a network problem as no one else was
> using it.
> Unless I'm missing something obvious, it must be a bug with cron.

I have trouble imagining that, but samba not acting like I expected is a
daily occurrence :-)

> I have tried the same with 2 different networks, with the same
> results. I'm using samba 2.2.6 on mdk9 with all the latest updates
> 
> #!/bin/sh
> cp -rpuv /mnt/windows /mnt/hal

Anything in the logs? Griping from the NIC driver or filesystem or
shorewall? Permissions on NTFS should throw an error via smbmount, I
would think... it would certainly produce an error in the Windows
security log.

actually, humor me -- try removing the u flag from your copy statement
and see what that does.

-- 
Jack Coates
Monkeynoodle: A Scientific Venture...



Want to buy your Pack or Services from MandrakeSoft? 
Go to http://www.mandrakestore.com