Ubuntu 12.10, Linux tweedle 3.5.0-23-generic #35-Ubuntu SMP Thu Jan 24 13:05:29 UTC 2013 i686 i686 i686 GNU/Linux
smbd --version Version 3.6.6
After reading down these posts, I think your real problem is with SMB. After a Ubuntu upgrade last spring I've had random, persistent and transient SMB errors that get logged but that do not seem to have any serious effect. NOTE that I haven't been paying a lot of attention to this because the SMB problem seems to immediately resolve itself (the SMB process re-spawns?) and life goes on.
This *may* be the most recent of those, can't recall the exact date and time:
[2013/02/16 16:07:51.038682, 0] lib/fault.c:47(fault_report)
===============================================================
[2013/02/16 16:07:51.051266, 0] lib/fault.c:48(fault_report)
INTERNAL ERROR: Signal 11 in pid 21916 (3.6.6)
Please read the Trouble-Shooting section of the Samba3-HOWTO
[2013/02/16 16:07:51.051391, 0] lib/fault.c:50(fault_report)
I too have suddenly begun seeing the Duplicity errors yesterday and today.
I too have a Duplicity archive file as a zero-length file on my backup device (Netgear NAS which works perfectly in all other regards).
I too cannot directly delete that zero-length file "Device or resource busy".
I too cannot *usually* unmount the Netgear NAS backup share in Nautilus -- but today I can, and when I do a 'ps ax grep 'dup'' I do NOT see the following Python script running now that the backup has failed:
Ubuntu 12.10, Linux tweedle 3.5.0-23-generic #35-Ubuntu SMP Thu Jan 24 13:05:29 UTC 2013 i686 i686 i686 GNU/Linux
smbd --version Version 3.6.6
After reading down these posts, I think your real problem is with SMB. After a Ubuntu upgrade last spring I've had random, persistent and transient SMB errors that get logged but that do not seem to have any serious effect. NOTE that I haven't been paying a lot of attention to this because the SMB problem seems to immediately resolve itself (the SMB process re-spawns?) and life goes on.
This *may* be the most recent of those, can't recall the exact date and time:
[2013/02/16 16:07:51.038682, 0] lib/fault. c:47(fault_ report) ======= ======= ======= ======= ======= ======= ======= ======= == c:48(fault_ report) c:50(fault_ report)
=====
[2013/02/16 16:07:51.051266, 0] lib/fault.
INTERNAL ERROR: Signal 11 in pid 21916 (3.6.6)
Please read the Trouble-Shooting section of the Samba3-HOWTO
[2013/02/16 16:07:51.051391, 0] lib/fault.
From: http:// www.samba. org/samba/ docs/Samba3- HOWTO.pdf c:51(fault_ report) ======= ======= ======= ======= ======= ======= ======= ======= == c:1117( smb_panic) c:1221( log_stack_ trace)
[2013/02/16 16:07:51.051494, 0] lib/fault.
=====
[2013/02/16 16:07:51.051569, 0] lib/util.
PANIC (pid 21916): internal error
[2013/02/16 16:07:51.220998, 0] lib/util.
BACKTRACE: 22 stack frames:
OK.
I too have suddenly begun seeing the Duplicity errors yesterday and today.
I too have a Duplicity archive file as a zero-length file on my backup device (Netgear NAS which works perfectly in all other regards).
I too cannot directly delete that zero-length file "Device or resource busy".
I too cannot *usually* unmount the Netgear NAS backup share in Nautilus -- but today I can, and when I do a 'ps ax grep 'dup'' I do NOT see the following Python script running now that the backup has failed:
32178 ? DNsl 7:43 /usr/bin/python /usr/bin/duplicity --include= /home/jsage/ .cache/ deja-dup/ metadata --include= /home/html/ www.finchhaven. com --exclude= /home/jsage/ Downloads --exclude= /home/jsage/ .local/ share/Trash --exclude= /home/jsage/ .xsession- errors --exclude= /home/jsage/ .thumbnails --exclude= /home/jsage/ .gvfs --exclude= /home/jsage/ .adobe/ Flash_Player/ AssetCache --exclude= /home/jsage/ .cache/ deja-dup --exclude= /home/jsage/ .cache --include= /home/jsage --exclude=/sys --exclude=/proc --exclude=/tmp --exclude=** --gio --volsize=25 / smb://finchnet- nas.local/ backup/ Tweedle --no-encryption --verbosity=9 --gpg-options= --no-use- agent --archive- dir=/home/ jsage/. cache/deja- dup --log-fd=19
In the past I have not been able to unmount the Netgear backup share because some (unknown at that time) Python script had it "busy".