-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Unfortunately, exit 23 litterally just means something else went wrong
and might have scrolled off of the screen if you have rsync listing
files (--verbose or --itemize_changes). Essentially, it is anything
that doesn't have its own exit cod
27;t have its own exit code. I just ignore it. The most common
> reaosn is file vanished.
THX for sharing your experiences and knowledge :-)
I have just tried to "reverse engineer" the possible reasons from the source
code
and have found 21 reasons that I hope will never happen ;-)
I am trying to find a solution for the open source Linux software
"Back In Time" (https://github.com/bit-team/backintime)
where we evaluate the rsync exit code when taking a backup via rsync
and inform the user that an error has occured.
Questions:
1. Is there full list of possib
On 02/22/2018 12:09 PM, James Moe via rsync wrote:
> Code 35 is the highest code value I could find.
> How should code 5888 be interpreted?
>
As y'all have noted, 5888 / 256 = 23. That is rsync code for "could
not open all selected files for transfer." And, yes, that was the case.
Thank yo
Hi,
On Fri, 23 Feb 2018 04:09:07 +0900,
James Moe via rsync wrote:
> 2018-02-22T05:02:00-0700 sma-server3 python3[31371]: backintime
> (sma-user3x/3): WARNING: Command "rsync -rtDHh --links --no-p --no-g
> --no-o --info=progress2 --no-i-r --delete --delete-excluded -i
> --dry-run --out-format="B
should be attacking whatever is looping
the exit code or whatever isn't understanding looped exit codes.
However, a shell wrapper would probably handle the problem. Simply put,
running:
$SHELL -c 'exit 5888'
is considered to be a success in every $SHELL I have installed on my
It is an exit 0 (success) that is being multiplied by 23 for some reason
and whatever (shell?) is running rsync doesn't recognize that.
On 02/22/2018 02:09 PM, James Moe via rsync wrote:
> rsync v3.1.0
> linux v4.4.104-39-default x86_64
>
> Found in the system log:
>
> 2018-02-22T05:02:00-070
rsync v3.1.0
linux v4.4.104-39-default x86_64
Found in the system log:
2018-02-22T05:02:00-0700 sma-server3 python3[31371]: backintime
(sma-user3x/3): WARNING: Command "rsync -rtDHh --links --no-p --no-g
--no-o --info=progress2 --no-i-r --delete --delete-excluded -i
--dry-run --out-format="BA
On Thu, 11 Jul 2013 15:46:06 +, Andrew Gideon wrote:
> rsync: recv_generator: mkdir
>
> "/backup/host/vol/snapshot.2013.07.11.0.in_progress/live/lms/trylesson/toefl"
> failed: No space left on device (28)
> *** Skipping any contents from this failed directory ***
I'm still looking th
ns (to the result of previous backups)
* Changing the destination directory to an "in progress" name
It then runs the actual rsync in a child process. When the child
completes, if it exits with a zero exit code, the "in progress" name
is renamed to a permanent name by the wra
||FIXED
--- Comment #1 from Wayne Davison 2013-05-26 23:19:46 UTC ---
The exit code gets passed from the sender to the receiver, but the generator
doesn't get notified about it, so it exits with the wrong code. I have checked
in a fix for the issue into git. Thanks for the r
https://bugzilla.samba.org/show_bug.cgi?id=9882
Summary: Incorrect exit code when sender over SSH is killed
with SIGTERM
Product: rsync
Version: 3.1.0
Platform: All
OS/Version: Linux
Status: NEW
Severity
https://bugzilla.samba.org/show_bug.cgi?id=8967
Wayne Davison changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugzilla.samba.org/show_bug.cgi?id=8967
--- Comment #4 from Paul Slootman 2012-06-02 11:29:07 UTC ---
How difficult is it for systemd to extend its service file format to include a
line that defines valid exit statusses?
It's this attitude of systemd being perfect and everything else bei
https://bugzilla.samba.org/show_bug.cgi?id=8967
--- Comment #3 from Brian K. White 2012-06-01 19:14:21 UTC ---
(In reply to comment #2)
> that's not the point. This is something that must be fixed in rsync, not in
> systemd. systemd does the right thing: if the process exits with 0, everything
>
https://bugzilla.samba.org/show_bug.cgi?id=8967
--- Comment #2 from mus@gmail.com 2012-06-01 18:00:13 UTC ---
that's not the point. This is something that must be fixed in rsync, not in
systemd. systemd does the right thing: if the process exits with 0, everything
is ok, if not, something went
considered an error and therefore rsync should return
> with
> exit code 0. this also causes problems with systemd, see:
> https://bugzilla.samba.org/show_bug.cgi?id=8416#c3
So submit a bug to systemd to be more flexible.
--
bkw
--
Configure bugmail: https://bugzilla.samba.org/
https://bugzilla.samba.org/show_bug.cgi?id=8967
Summary: rsync returns with non-zero exit code when killed by
SIGTERM
Product: rsync
Version: 3.0.9
Platform: All
OS/Version: All
Status: NEW
Severity
henri wrote:
When launchd executed this command, it did not work. The system.log file reads
"Exited with exit code: 1".
Can you redirect the output to a file so it can tell you why it failed? e.g.
>file.out 2>&1
One common thing that prevents non-interactive sudo
> When launchd executed this command, it did not work. The system.log file
> reads "Exited with exit code: 1".
>
> Can you redirect the output to a file so it can tell you why it failed? e.g.
> >file.out 2>&1
>
> One common thing that prevents
Wayne Davison wrote:
On Sun, Dec 13, 2009 at 8:49 AM, Jonathan S. Abrams
mailto:hoci...@comcast.net>> wrote:
When launchd executed this command, it did not work. The
system.log file reads "Exited with exit code: 1".
Can you redirect the output to a file so it can
On Sun, Dec 13, 2009 at 8:49 AM, Jonathan S. Abrams wrote:
> When launchd executed this command, it did not work. The system.log file
> reads "Exited with exit code: 1".
>
Can you redirect the output to a file so it can tell you why it failed?
e.g. >file.out 2>
File_Storage_Mirror/docs
When launchd executed this command, it did not work. The system.log
file reads "Exited with exit code: 1". It called it at 12:01 AM,
but it did not execute properly.
When I VNC via SSH into the server, and execute that exact same
command at the
not work. The system.log
file reads "Exited with exit code: 1". It called it at 12:01 AM, but it
did not execute properly.
When I VNC via SSH into the server, and execute that exact same command
at the Terminal manually, it works as expected. If anyone can offer any
insight as
https://bugzilla.samba.org/show_bug.cgi?id=6965
Summary: truncated files and exit code 23
Product: rsync
Version: 3.0.4
Platform: x86
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P3
Component
https://bugzilla.samba.org/show_bug.cgi?id=6508
way...@samba.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugzilla.samba.org/show_bug.cgi?id=6508
Summary: Inconsistent exit code behavior between local, ssh
transport, and rsyncd transport
Product: rsync
Version: 3.0.4
Platform: All
OS/Version: All
Status: NEW
ot ideal.
so one way or the other, just stick to either one is fine. since the
exit code sometime is a personal taste...
>
> > all file sync/backup software for a live file system can have same
> > issue
> > here. which state to maintain. rsync can always do a stat on the
On Sun, 2007-12-23 at 15:55 -0500, Ming Zhang wrote:
> if sender read by path again and get ENOENT, then this ENOENT can tell
> rsync enough info. (though current rsync might say partial transfer
> though it is a vanished file... )
Treating the file as completely vanished on the basis of the ENOEN
On Thu, 2007-12-20 at 10:24 -0500, Matt McCutchen wrote:
> On Wed, 2007-12-19 at 22:25 -0500, Ming Zhang wrote:
> > so this file-list is the internal file list, not the --files-from
> > content.
>
> Yes, the correctness property is based on the internal file list.
>
> > rsync's goal is to keep sr
On Wed, 2007-12-19 at 22:25 -0500, Ming Zhang wrote:
> so this file-list is the internal file list, not the --files-from
> content.
Yes, the correctness property is based on the internal file list.
> rsync's goal is to keep src and dest in same state (same content, or the
> fact that none side ha
is
> whether to alert the user that s/he may have mistyped the --files-from
> entry. By default, rsync alerts the user with a code 23. In the case
> of inotify, an option would indicate that this alerting is not desired,
> and no exit code would be needed at all.
property. Then the only issue is
whether to alert the user that s/he may have mistyped the --files-from
entry. By default, rsync alerts the user with a code 23. In the case
of inotify, an option would indicate that this alerting is not desired,
and no exit code would be needed at all.
Matt
--
On Fri, 2007-12-14 at 23:27 -0500, Matt McCutchen wrote:
> On Fri, 2007-12-14 at 18:24 -0500, Ming Zhang wrote:
> > What should be the right exit code for vanished file in this scenario.
> >
> > (1) Use inotify or other mechanism to check changed files and then
>
On Fri, 2007-12-14 at 18:24 -0500, Ming Zhang wrote:
> What should be the right exit code for vanished file in this scenario.
>
> (1) Use inotify or other mechanism to check changed files and then
> generate a file list.
>
> (2) < file get deleted>
>
> (3) run rs
Hi
What should be the right exit code for vanished file in this scenario.
(1) Use inotify or other mechanism to check changed files and then
generate a file list.
(2) < file get deleted>
(3) run rsync with --files-from with the old list.
then send_file_list()->link_stat() will retur
Matt McCutchen wrote:
>
> If a file has vanished and there is also an error that affects the
> correctness of the transfer, the code 23 takes precedence over the code
> 24. Check rsync's output for any error messages. If there are none,
>
Indeed that is the case. I did not realize at first
On Fri, 2007-12-07 at 14:40 -0600, Marc DeTrano wrote:
> I am using rsync 2.6.9 (as currently packaged in Mandriva 2007.1)
>
> Ever since the latest update of the package I have been getting an exit
> code of 23 with the output "file has vanished: {filename}".
>
>
I am using rsync 2.6.9 (as currently packaged in Mandriva 2007.1)
Ever since the latest update of the package I have been getting an exit
code of 23 with the output "file has vanished: {filename}".
For partial transfers due to vanished files, I (and my script) would
expect exit code
te:
I'm wondering why rsync stop without any message regarding that it is
finished.
So I ran in verbose mode and I'm wondering if this:
_exit_cleanup(code=20, file=log.c, line=230): about to call exit(20)
_exit_cleanup(code=20, file=log.c, line=230): about to call exit(129)
Is the no
_exit_cleanup(code=20, file=log.c, line=230): about to call exit(129)
>
> Is the normal exit code, or if something went wrong?
Something definitely went wrong. Code 20 (RERR_SIGNAL) means rsync is
quitting because it received a signal: SIGINT, SIGTERM, or SIGHUP.
However, the file/lin
I'm wondering why rsync stop without any message regarding that it is
finished.
So I ran in verbose mode and I'm wondering if this:
_exit_cleanup(code=20, file=log.c, line=230): about to call exit(20)
_exit_cleanup(code=20, file=log.c, line=230): about to call exit(129)
Is the normal
https://bugzilla.samba.org/show_bug.cgi?id=3787
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugzilla.samba.org/show_bug.cgi?id=3787
Summary: Optional exit code indicating receiver was changed
Product: rsync
Version: 2.6.9
Platform: Other
OS/Version: All
Status: NEW
Severity: normal
Priority: P3
On Thu, 15 Jan 2004, Wayne Davison <[EMAIL PROTECTED]> wrote:
> On Tue, Jan 13, 2004 at 11:45:22PM -0600, John Van Essen wrote:
>> But as I mentioned, it also happens with a daemon
>
> Yeah, the daemon's exit code is not available to the client, so it is
> getting
On Tue, Jan 13, 2004 at 11:45:22PM -0600, John Van Essen wrote:
> But as I mentioned, it also happens with a daemon
Yeah, the daemon's exit code is not available to the client, so it is
getting lost. I've committed a patch that will cause a daemon sender to
go ahead and use F
On Tue, 13 Jan 2004 20:47:30 -0800, Wayne Davison <[EMAIL PROTECTED]> wrote:
> On Tue, Jan 13, 2004 at 10:38:23PM -0600, John Van Essen wrote:
>> Are you by any chance doing internal rsyncs?
>
> No. What remote shell are you using? If it doesn't propagate the exit
&
On Tue, Jan 13, 2004 at 10:38:23PM -0600, John Van Essen wrote:
> Are you by any chance doing internal rsyncs?
No. What remote shell are you using? If it doesn't propagate the exit
code from the sender (i.e. the process on the other side of the
connection), that may explain why the rec
ient (the io_error value is passed at the end of the file list,
>> not during or after the file transfer phase).
>
> Yes it is, it is passed as the exit code. In the tests I just ran, the
> new error message appears if both sides are 2.6.0:
>
> rsync warning: some files vanis
ter the file transfer phase).
Yes it is, it is passed as the exit code. In the tests I just ran, the
new error message appears if both sides are 2.6.0:
rsync warning: some files vanished before they could be transfered (code 24) at
main.c(1064)
and the new error code (24) is still returned
A new 2.6.0 feature is supposed to use a different exit code when the
only 'errors' were from files that disappeared between the building
of the file list and the actual transfer of files.
But if the client is local and the server is remote, IOERR_VANISHED
gets set on the remote serv
I didn't search the web for this - I just looked for
*.h files in the rsync source, and found error.h. I'm
guessing the contents of error.h is what you're after.
Check the rsync source out of CVS and view error.h.
HTH.
--
Hardy Merrill
Red Hat, Inc.
[EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
>
Hi !
I've spent countless hours search the internet to find a list of exit codes
for rsync. Can someone point me to a list of error codes and their
meanings?
this would be much appreciated !!
thanks !!
--
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before p
I am preparing for making 2.5.6pre1 today and decided to submit David
Staples patch with a little rework. Here's the version I submitted.
- Dave Dykstra
--- main.c~ Thu Aug 1 15:46:59 2002
+++ main.c Thu Jan 9 12:43:55 2003
@@ -26,6 +26,16 @@
extern struct stats stats;
extern int v
Greetings,
I'm getting a different exit code from rsh versus daemon when syncing
the same data. I've listed an example below. The exit code is 0 for the
client to daemon example, it does not reflect the Permission denied
errors. The second example is rsh and it returns exit code
> "k" == Kevin J Walters <[EMAIL PROTECTED]> writes:
k> I've just created a small directory as an example, it holds a file and
k> two symlinks that don't point to anything, and another symlink going
k> nowhere in a subdirectory.
k> rsync (2.5.5) is happy to copy these but produces an error.
On Mon, May 20, 2002 at 10:59:41AM -0400, Crisler, Jon wrote:
| Error 23 is an incomplete copy. As I understand it, there is an
| inconsistancy between the first check for differences, and the start of the
| copy process.
|
| I run into this all the time, but for my implemention it is a legiti
Title: RE: exit code 23 - inappropriate error for copying symlinks?
Error 23 is an incomplete copy. As I understand it, there is an inconsistancy between the first check for differences, and the start of the copy process.
I run into this all the time, but for my implemention it is a
Hi,
I've just created a small directory as an example, it holds a file and
two symlinks that don't point to anything, and another symlink going
nowhere in a subdirectory.
rsync (2.5.5) is happy to copy these but produces an error. I can't
see why it considers this an error? It's not even abort
59 matches
Mail list logo
