Re: Re: Socket files, artype=exustar, errctl=

[email protected] wrote:

> seems the problem is solved now by using option -dump.
> I nevertheless report what i experienced and why i think
> i failed to notice the importance of -dump.

By default, star is in normal "archiver" mode and this is different
from what people expect for backups.

> My failure to use -dump was in part due to psychology :
> dump/restore is traditionally an awful, hyper specific
> tool to serialize and deserialize filesystems. Far from
> what any reasonable backup should strive for.

If you do not use the dump/restore features of star, you do not
get all features of star.


> > > what file types other than PF_UNIX sockets are known
> > > to raise error condition SPECIALFILE with artype=exustar ?
> > >   star: '/dev/log' unsupported file type 'socket'. Not dumped.
> > 
> > Star with artype=exustar supports all possible filetypes that
> > are used on Solaris.
>
> Good to know.
> I nevertheless get those messages with
>    star -c artype=exustar -acl 

This is for maximum compatibility with other 'pax' implementations.


> > I thought you like to use star to make backups.
> > Why then do you use star in a mode that is intended for best
> > portability between different POSIX systems?
>
> Huh ?
> Up to now i thought star was _all_ about backups.

Star is mainly an archiver..... It includes however special
backup/restore features.


> ... RTFMing ...
>
> Do you mean with "make backups" that i should always
> use option -dump (or "level=0") ?

If you like a complete backup, is is the best to use level=0.
In this case, star forces you to backup the complete filesystem
and archives even more data about the FS.

> gnutar was only a remote idea (for maximum portablity).

GNUtar gives much less portability than people believe.
The GNUtar archive format is incompatible with the TAR standard
and thus confuses real tar implementations.


> I got led to artype=exustar by the man page when i
> tried to employ -acl. This option refused to work
> as
>    star -c -acl ...
> and the man page mentions "[Aa][Cc][Ll]" mainly together
> with options "artype=xustar" or "level=".
> The description of "diffopts=" says:
> "acl       Compare access control lists.  This  only
>            works if the archive is in exustar format
>            and has been  created  with  star's  -acl
>            option."

You cannot archive ACLs if you choose an archive format
that does not support ACLs.


> The incremental examples from the man-page did work
> without artype=exustar. I was a bit puzzled but
> thought that with exustar i would get the best effort
> out of star.

Star switches to the right format if you select backup mode.


> Checking the archive type a level=0 backup by 
> -print-artype did produce the answer "exustar archive".
>
>
> So a sentence about the benefits of -dump would have
> been helpful at the description of artype=exustar .

I added it now, but there are many other places in the 
man page that mention the relationship.


> I now understand exustar as a prerequisite for 
> premium exactness but not as being at the level where
> a user should tune exactness on the first hand.

I don't understand what you like to say here.


> > > I understand that powerful artype=exustar does not support
> > 
> > It does of course, but you don't want them unless you are doing
> > real and accurate backups.
>
> Ew. That's a cryptic statement together with my experiences.
> (I take it as a pointer towards option -dump)
>
> Yes. I don't want them. I also don't want the messages.
> But i want all other possibly more important messages
> of star.

Star does try to check as much as possible so it needs to
warn by default. Star is made in a way that there should be no
warning at all if you follow the examples in the sections
about incremental dumps.

In addition, star includes a powerful way of controlling the
error handling and star-1.5a66 did even enhance this a lot.



> > The old star format is from 1986 and tries to be a clean extension
> > on the historic tar archive format from 1978 while being
> > definitely pre POSIX.1-1988.
>
> A small paragraph (positioned quite early in star.1) about
> the appropriate choice of archive formats would be helpful. 
> Like
> - If you want maximum recording fidelity with file
>   attributes and properties, then use options ...
> - If you want compatibility with other tar-like programs,
>   then use options ...
> - If you want a full incremental backup of a single entire
>   filesystem see section "INCREMENTAL BACKUPS"

Isn't all this information in the artype= section?

> > Even ufsdump silently omits sockets from the backup....
> > Star _includes_ them if in backup mode.
>
> There is no term "backup mode" in the man page.
> (I take it for "-dump" now)

There is:

INCREMENTAL BACKUPS

BACKUP SCHEDULES

INCREMENTAL RESTORES

SYNCHRONIZING FILESYSTEMS



> There is a term "copy mode" but this does imply -dump .
> There is also "archive mode" mentioned with "copy mode".
> I find lots of other modes in the man page.

The general rule for all my programs is to make 
the command line as simple as possible.


> [start nostalgy]
> > On a vanilla SVr4, there are no socket in the filesystem.
> > Sockets reappeared around 1998 when SUSv2 did replace 
> > the t_* based networking interface by the old socked based
> > system requiring that dup(2) on a socket works.
> > As this is only possible if the socket implementation is in
> > the kernel, Solaris did put sockets back into the kernel and 
> > did re-introduce socket typed files again althouth even the
> > *BSD man pages from 1979 mentions socket files as being obsolete and
> > unwanted....
>
> I am maintaining a few programs which do IPC.
> I considered to employ PF_UNIX sockets for local
> communications but refrained because they are so
> poorly documented and seem not to have been a 
> stable standard in the past.
> (Named pipes aren't much better though.)

Sockets always have been stable on the OS that I was using.
Names pipes did appear much later (around 1988 which is
10 years after sockets came up).

On which OS did you have problems?

> Learned my IPC from SunOS (on a "SUN IPC" workstation)
> which brought very nice examples for IP based sockets.

Named pipes did appear with SunOS 4.0 AFAIK

> [end nostalgy]
> Now hugging my AMD 2600+ with its gig of RAM :))

I am still in hope to get a dual core opteron as a present from AMD ;-)



> The lower the skills of the backup operator the
> more harsh (but well balanced) should be the 
> reaction on unexpected problems.
> I've seen a person storing daily backups for years
> of which each single write run produced error
> messages and told that person (in english) that the
> backup was incomplete.
> Regrettably the person knew hardly any english and
> was only trained to watch for hard aborts.

If star is in backup mode, it will not write the tardumps= file
in case that the backup is incomplete.

With star-1.5a66 you may also tell star to immediately abort on
unexpected errors.


> There were tears flowing when the backups were
> finally needed.
>
> Your error handling concept allows a skilled
> admin to describe the known problems so that
> unskilled operators get a more clear feedback
> from the backup utility.
> I will try to make good use of it.

See the new -e option and the ABORT condition....


> I encountered some overly soft aborts resp. misleading
> error messages when using -fifo .
>
> From my report sketch (still under construction) :
>
> ------------------------------------------------------
> Suboptimal error message and sometimes abort too soft
> with  -fifo  :
> ------------------------------------------------------
>
> I aborted a star run (-fifo by default) by pressing CTRL+C
> and got this message :
>
>   star: 362598 blocks + 0 bytes (total of 3713003520 bytes = 3625980.00k).
>   star: Success. Sync pipe read error on pid 10836 flags 0x1.
>
> "Success" is a contradiction to the rest of the message.
> Whyever errno is 0, one should avoid to expose that pseudo
> error description text "Success" as standalone sentence.

The background process did die before the foreground process and caused
an EOF on the sync pipe. This is unusual and thus you see the message.


> Normally my script aborts on CTRL+C while star is running with -fifo.
> But i experienced twice an overly soft abort with star-1.5a64
> (while it piped into /dev/null) :

Do you use 'bash' to run the script?

Bash is unfortuneatly /bin/sh on Linux and it's jobcontrol is horrobly broken.

If you use something like star  | something in the script then you see most
likely the result of abash bug..... Bash is so broken, that I needed to add
special support in smake to prevent hitting ^C to only disconnect the foreground
from the terminal and let other processes run without getting a signal.

>   star: Missing links 0, Name too long 0, File too big 0, Not dumped 28.
>   star: Processed all possible files, despite earlier errors.
>
> my own shell code then reacted on the 254 exit
>   + ret=254
>
>   CAUTION: star had problems with some files. See messages above.
>
> but was not aware that the problem was fatal.

Then you run the script by a broken shell like bash :-(
I am sorry, but I cannot help if the bash maintainers do mnot listen to the
problems of their users. Bash incorrecly does jobcontrol for scripts althought
this is an absolute no-go. Try to use a shell that either correclty does not
do jobcontrol for scripts or that does not do jobcontrol at atll.


> The reading of files was not completed at that moment, i'm quite
> sure. The disk was visibly busy and the run would have ended
> with a count like
>   star: 481922 blocks + 0 bytes (total of 4934881280 bytes = 4819220.00k).
> if not interrupted.

If star _was_ interrupted (this happens if you use a non-broken shell),
star will die from ^C and you will see the correct exit indication.

Star most likely was not interrupted because you did use a broken shell.

Jörg

-- 
 EMail:[email protected] (home) Jörg Schilling D-13353 Berlin
       [email protected]		(uni)  
       [email protected]	(work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily