Discussion:
[unison-users] unison on mac fails with IMKClient Stall detected,
Roderick Usher my.work.email.lists@gmail.com [unison-users]
2017-07-04 15:52:03 UTC
Permalink
Hi, I’ve just mirrored the directory I want to sync from networked attached storage to a drive on a networked computer. The directory is synced with one on my laptop computer (a mac). In both cases I am using an ssh link into the same remote computer. The reason I am doing this is because unison is very slow on the network attached storage, I presume from network overhead, and ssh can sometimes time out before a sync is completed.

When I run unison between the directory on the networked attached storage and my laptop, it completes successfully.

However, when I change the root in my profile to run unison between the networked computer directory and the laptop, I get the error.

[pred] forcepartial 'web/web_button_research.gif' = false
[pred] preferpartial 'web/web_button_research.gif' = false
[pred] forcepartial 'web/web_button_research2.gif' = false
[pred] preferpartial 'web/web_button_research2.gif' = false
<>$Killed by signal 1.
Illegal instruction: 4
When the program dies, the apple error report comes up and it says (which might be relevant?)

Termination Signal: Illegal instruction: 4
Termination Reason: Namespace SIGNAL, Code 0x4
Terminating Process: Unison [10378]



No log is completed. But if I remove the file before the process is killed (web_button_research2.gif) the process still dies on the next file. What perplexes me the most is that unison runs fine on a duplicate set of files on the network attached storage. Below I’ve added the initial output from the command

unison -log -debug all Windows

2017-07-04 09:44:38.317 Unison[10477:617035] Roots are not set on the command line
2017-07-04 09:44:38.333 Unison[10477:617035] Connecting to Windows...
Preferences:
ui = graphic
host =
server = false
prefsdocs = false
doc =
version = false
silent = false
dumbtty = false
testserver = false
rest = Windows
showprev = false
selftest = false
confirmmerge = false
retry = 0
repeat =
contactquietly = false
key =
label =
expert = false
height = 15
auto = false
maxthreads = 0
maxsizethreshold = -1
prefer =
force =
sortnewfirst = false
sortbysize = false
keeptempfilesaftermerge = false
diff = diff -u CURRENT2 CURRENT1
copyonconflict = false
backupdir =
maxbackups = 2
backups = false
backupsuffix =
backupprefix = .bak.$VERSION.
backuploc = central
copymax = 1
copyquoterem = default
copythreshold = -1
copyprogrest = rsync --partial --append-verify --compress
copyprog = rsync --partial --inplace --compress
rsync = true
fastcheck = default
ignorelocks = false
dumparchives = false
showarchive = false
rootsName =
ignorearchives = false
fastercheckUNSAFE = false
fat = false
allHostsAreRunningWindows = false
someHostIsRunningWindows = false
ignore = Name {.DS_Store}
ignore = Name {Thumbs.db}
confirmbigdel = true
batch = false
root = ssh://***@workcomputer.work.colostate.edu//scratch/myfirstname/Windows
root = /Users/myfirstname/Windows
killserver = false
halfduplex = false
stream = true
addversionno = false
servercmd = /usr/local/bin/unison-2.48.3
sshargs =
rshargs =
rshcmd = rsh
sshcmd = ssh
xferbycopying = true
sshversion =
clientHostName = Myfirstnames-MacBook-Pro.local
ignoreinodenumbers = false
links-aux = true
links = default
times = true
group = false
owner = false
numericids = false
dontchmod = false
perms = 1023
watch = true
rsrc-aux = false
rsrc = default
maxerrors = 1
unicodeCS = false
unicodeEnc = false
unicode = default
someHostIsInsensitive = false
ignorecase = default
timers = false
terse = false
logfile = /Users/myfirstname/unison.log
log = true
debugtimes = false
debug = all
addprefsto =
[remote] Shell connection: ssh (ssh, -l, mylastname, workcomputer.work.colostate.edu, -e, none, /usr/local/bin/unison-2.48.3, -server)
2017-07-04 09:44:38.574 Unison[10477:617035] Got the prompt: '***@workcomputer.work.colostate.edu's password: '
2017-07-04 09:44:38.880 Unison[10477:617035] Connected.
[globals] Installing roots...[globals] Checking path '' for expansions
Roots:
/Users/myfirstname/Windows
ssh://***@workcomputer.work.colostate.edu//scratch/myfirstname/Windows
i.e.
/Users/myfirstname/Windows
ssh://***@workcomputer.work.colostate.edu//scratch/myfirstname/Windows
i.e. (in canonical order)
/Users/myfirstname/Windows
//workcomputer//scratch/myfirstname/Windows

Thanks!
Adrian Klaver adrian.klaver@aklaver.com [unison-users]
2017-07-04 19:52:34 UTC
Permalink
Post by Roderick Usher ***@gmail.com [unison-users]
Hi, I’ve just mirrored the directory I want to sync from networked
attached storage to a drive on a networked computer. The directory is
synced with one on my laptop computer (a mac). In both cases I am
using an ssh link into the same remote computer. The reason I am
doing this is because unison is very slow on the network attached
storage, I presume from network overhead, and ssh can sometimes time out
before a sync is completed.
From below you are syncing from OS X to Windows, correct?

Some questions:
1) Unison version(s) on both ends?

2) OS X version?

3) Windows versions?

4) Is the next file you mention below an image file also?
Post by Roderick Usher ***@gmail.com [unison-users]
When I run unison between the directory on the networked attached
storage and my laptop, it completes successfully.
However, when I change the root in my profile to run unison between the
networked computer directory and the laptop, I get the error.
[pred] forcepartial 'web/web_button_research.gif' = false
[pred] preferpartial 'web/web_button_research.gif' = false
[pred] forcepartial 'web/web_button_research2.gif' = false
[pred] preferpartial 'web/web_button_research2.gif' = false
<>$Killed by signal 1.
Illegal instruction: 4
When the program dies, the apple error report comes up and it says
(which might be relevant?)
Termination Signal: Illegal instruction: 4
Termination Reason: Namespace SIGNAL, Code 0x4
Terminating Process: Unison [10378]
No log is completed. But if I remove the file before the process is
killed (web_button_research2.gif) the process still dies on the next
file. What perplexes me the most is that unison runs fine on a
duplicate set of files on the network attached storage. Below I’ve
added the initial output from the command
unison -log -debug all Windows
2017-07-04 09:44:38.317 Unison[10477:617035] Roots are not set on the command line
2017-07-04 09:44:38.333 Unison[10477:617035] Connecting to Windows...
ui = graphic
host =
server = false
prefsdocs = false
doc =
version = false
silent = false
dumbtty = false
testserver = false
rest = Windows
showprev = false
selftest = false
confirmmerge = false
retry = 0
repeat =
contactquietly = false
key =
label =
expert = false
height = 15
auto = false
maxthreads = 0
maxsizethreshold = -1
prefer =
force =
sortnewfirst = false
sortbysize = false
keeptempfilesaftermerge = false
diff = diff -u CURRENT2 CURRENT1
copyonconflict = false
backupdir =
maxbackups = 2
backups = false
backupsuffix =
backupprefix = .bak.$VERSION.
backuploc = central
copymax = 1
copyquoterem = default
copythreshold = -1
copyprogrest = rsync --partial --append-verify --compress
copyprog = rsync --partial --inplace --compress
rsync = true
fastcheck = default
ignorelocks = false
dumparchives = false
showarchive = false
rootsName =
ignorearchives = false
fastercheckUNSAFE = false
fat = false
allHostsAreRunningWindows = false
someHostIsRunningWindows = false
ignore = Name {.DS_Store}
ignore = Name {Thumbs.db}
confirmbigdel = true
batch = false
root =
root = /Users/myfirstname/Windows
killserver = false
halfduplex = false
stream = true
addversionno = false
servercmd = /usr/local/bin/unison-2.48.3
sshargs =
rshargs =
rshcmd = rsh
sshcmd = ssh
xferbycopying = true
sshversion =
clientHostName = Myfirstnames-MacBook-Pro.local
ignoreinodenumbers = false
links-aux = true
links = default
times = true
group = false
owner = false
numericids = false
dontchmod = false
perms = 1023
watch = true
rsrc-aux = false
rsrc = default
maxerrors = 1
unicodeCS = false
unicodeEnc = false
unicode = default
someHostIsInsensitive = false
ignorecase = default
timers = false
terse = false
logfile = /Users/myfirstname/unison.log
log = true
debugtimes = false
debug = all
addprefsto =
[remote] Shell connection: ssh (ssh, -l, mylastname,
workcomputer.work.colostate.edu
<http://workcomputer.work.colostate.edu>, -e, none,
/usr/local/bin/unison-2.48.3, -server)
2017-07-04 09:44:38.880 Unison[10477:617035] Connected.
[globals] Installing roots...[globals] Checking path '' for expansions
/Users/myfirstname/Windows
i.e.
/Users/myfirstname/Windows
i.e. (in canonical order)
/Users/myfirstname/Windows
//workcomputer//scratch/myfirstname/Windows
Thanks!
--
Adrian Klaver
***@aklaver.com
Roderick Usher my.work.email.lists@gmail.com [unison-users]
2017-07-05 01:50:44 UTC
Permalink
Sorry, now that I look at it I see my email was sloppy. First off, the subject is incorrect—it’s from an earlier email that I started and never completed. Please ignore this. I’ve answered your questions below.
Post by Adrian Klaver ***@aklaver.com [unison-users]
Post by Roderick Usher ***@gmail.com [unison-users]
Hi, I’ve just mirrored the directory I want to sync from networked attached storage to a drive on a networked computer. The directory is synced with one on my laptop computer (a mac). In both cases I am using an ssh link into the same remote computer. The reason I am doing this is because unison is very slow on the network attached storage, I presume from network overhead, and ssh can sometimes time out before a sync is completed.
From below you are syncing from OS X to Windows, correct?
I am syncing between OSX and linux. The remote computer is running Fedora 24.
Post by Adrian Klaver ***@aklaver.com [unison-users]
1) Unison version(s) on both ends?
Unison version is 2.48.3 on the linux side, and 2.48.15 on the mac. This is a combination I finally got to work without the OCaml bigarray errors cropping up.
Post by Adrian Klaver ***@aklaver.com [unison-users]
2) OS X version?
10.12.5 (Sierra)
Post by Adrian Klaver ***@aklaver.com [unison-users]
3) Windows versions?
Fedora 24.
Post by Adrian Klaver ***@aklaver.com [unison-users]
4) Is the next file you mention below an image file also?
No, it also choked on a PDF file.
Post by Adrian Klaver ***@aklaver.com [unison-users]
Post by Roderick Usher ***@gmail.com [unison-users]
When I run unison between the directory on the networked attached storage and my laptop, it completes successfully.
However, when I change the root in my profile to run unison between the networked computer directory and the laptop, I get the error.
[pred] forcepartial 'web/web_button_research.gif' = false
[pred] preferpartial 'web/web_button_research.gif' = false
[pred] forcepartial 'web/web_button_research2.gif' = false
[pred] preferpartial 'web/web_button_research2.gif' = false
<>$Killed by signal 1.
Illegal instruction: 4
When the program dies, the apple error report comes up and it says (which might be relevant?)
Termination Signal: Illegal instruction: 4
Termination Reason: Namespace SIGNAL, Code 0x4
Terminating Process: Unison [10378]
No log is completed. But if I remove the file before the process is killed (web_button_research2.gif) the process still dies on the next file. What perplexes me the most is that unison runs fine on a duplicate set of files on the network attached storage. Below I’ve added the initial output from the command
unison -log -debug all Windows
2017-07-04 09:44:38.317 Unison[10477:617035] Roots are not set on the command line
2017-07-04 09:44:38.333 Unison[10477:617035] Connecting to Windows...
ui = graphic
host =
server = false
prefsdocs = false
doc =
version = false
silent = false
dumbtty = false
testserver = false
rest = Windows
showprev = false
selftest = false
confirmmerge = false
retry = 0
repeat =
contactquietly = false
key =
label =
expert = false
height = 15
auto = false
maxthreads = 0
maxsizethreshold = -1
prefer =
force =
sortnewfirst = false
sortbysize = false
keeptempfilesaftermerge = false
diff = diff -u CURRENT2 CURRENT1
copyonconflict = false
backupdir =
maxbackups = 2
backups = false
backupsuffix =
backupprefix = .bak.$VERSION.
backuploc = central
copymax = 1
copyquoterem = default
copythreshold = -1
copyprogrest = rsync --partial --append-verify --compress
copyprog = rsync --partial --inplace --compress
rsync = true
fastcheck = default
ignorelocks = false
dumparchives = false
showarchive = false
rootsName =
ignorearchives = false
fastercheckUNSAFE = false
fat = false
allHostsAreRunningWindows = false
someHostIsRunningWindows = false
ignore = Name {.DS_Store}
ignore = Name {Thumbs.db}
confirmbigdel = true
batch = false
root = /Users/myfirstname/Windows
killserver = false
halfduplex = false
stream = true
addversionno = false
servercmd = /usr/local/bin/unison-2.48.3
sshargs =
rshargs =
rshcmd = rsh
sshcmd = ssh
xferbycopying = true
sshversion =
clientHostName = Myfirstnames-MacBook-Pro.local
ignoreinodenumbers = false
links-aux = true
links = default
times = true
group = false
owner = false
numericids = false
dontchmod = false
perms = 1023
watch = true
rsrc-aux = false
rsrc = default
maxerrors = 1
unicodeCS = false
unicodeEnc = false
unicode = default
someHostIsInsensitive = false
ignorecase = default
timers = false
terse = false
logfile = /Users/myfirstname/unison.log
log = true
debugtimes = false
debug = all
addprefsto =
[remote] Shell connection: ssh (ssh, -l, mylastname, workcomputer.work.colostate.edu <http://workcomputer.work.colostate.edu/><http://workcomputer.work.colostate.edu <http://workcomputer.work.colostate.edu/>>, -e, none, /usr/local/bin/unison-2.48.3, -server)
2017-07-04 09:44:38.880 Unison[10477:617035] Connected.
[globals] Installing roots...[globals] Checking path '' for expansions
/Users/myfirstname/Windows
i.e.
/Users/myfirstname/Windows
i.e. (in canonical order)
/Users/myfirstname/Windows
//workcomputer//scratch/myfirstname/Windows
Thanks!
--
Adrian Klaver
Alan Schmitt alan.schmitt@polytechnique.org [unison-users]
2017-07-05 06:34:38 UTC
Permalink
Post by Roderick Usher ***@gmail.com [unison-users]
Post by Adrian Klaver ***@aklaver.com [unison-users]
2) OS X version?
10.12.5 (Sierra)
Is it a recent Mac? In particular, is it using a Skylake or Kabylake
processor with hyperthreading enabled?

Best,

Alan
--
OpenPGP Key ID : 040D0A3B4ED2E5C7
Monthly Athmospheric CO₂, Mauna Loa Obs. 2017-05: 409.65, 2016-05: 407.70
Alan Schmitt alan.schmitt@polytechnique.org [unison-users]
2017-07-05 12:24:18 UTC
Permalink
"RU" == Roderick Usher <***@gmail.com> writes:

RU> Hi Alan,
Post by Alan Schmitt ***@polytechnique.org [unison-users]
Post by Roderick Usher ***@gmail.com [unison-users]
Post by Adrian Klaver ***@aklaver.com [unison-users]
2) OS X version?
10.12.5 (Sierra)
Is it a recent Mac? In particular, is it using a Skylake or Kabylake
processor with hyperthreading enabled?
RU> Here it is--
Post by Alan Schmitt ***@polytechnique.org [unison-users]
sysctl -n machdep.cpu.brand_string
RU> Intel(R) Core(TM) i7-6700HQ CPU @ 2.60GHz

RU> I believe it is a Skylake, and has hyperthreading.

I'm afraid you might be bitten by the hyperthreading bug.
http://gallium.inria.fr/blog/intel-skylake-bug/

If you have XCode, you can try launching Instruments, and disabling
hyperthreading in its preferences. Try to synchronize again, and we'll
know if this is that bug.

Unfortunately disabling hyperthreading does not stick when the mac
sleeps or reboots. For a permanent solution, I'm afraid one has to wait
for a firmware update from Apple.

Alan
--
OpenPGP Key ID : 040D0A3B4ED2E5C7
Monthly Athmospheric CO₂, Mauna Loa Obs. 2017-05: 409.65, 2016-05: 407.70
Adrian Klaver adrian.klaver@aklaver.com [unison-users]
2017-07-05 14:13:48 UTC
Permalink
Post by Roderick Usher ***@gmail.com [unison-users]
Sorry, now that I look at it I see my email was sloppy. First off, the
subject is incorrect—it’s from an earlier email that I started and never
completed. Please ignore this. I’ve answered your questions below.
Post by Adrian Klaver ***@aklaver.com [unison-users]
From below you are syncing from OS X to Windows, correct?
I am syncing between OSX and linux. The remote computer is running Fedora 24.
Well I botched that:)

At this point I would say let's see what implementing Alan's suggestion
does for you?
Post by Roderick Usher ***@gmail.com [unison-users]
Post by Adrian Klaver ***@aklaver.com [unison-users]
1) Unison version(s) on both ends?
Unison version is 2.48.3 on the linux side, and 2.48.15 on the mac.
This is a combination I finally got to work without the OCaml bigarray
errors cropping up.
Post by Adrian Klaver ***@aklaver.com [unison-users]
2) OS X version?
10.12.5 (Sierra)
Post by Adrian Klaver ***@aklaver.com [unison-users]
3) Windows versions?
Fedora 24.
Post by Adrian Klaver ***@aklaver.com [unison-users]
4) Is the next file you mention below an image file also?
No, it also choked on a PDF file.
--
Adrian Klaver
***@aklaver.com
Roderick Usher my.work.email.lists@gmail.com [unison-users]
2017-07-05 15:07:46 UTC
Permalink
Hi Alan and Adrian,

Thanks much for your help. I turned off hyperthreading and had the same
issue. I also changed another profile from syncing with the network
attached storage to the remote computer drive, and it also stopped.
However in this case no files were synced before I received a "killed by
signal 1" error.

So, it seems that when I change my work unison root from the network
attached storage to the local drive on my work computer, something goes
wrong. It seems to be independent of the actual files that are
transferred. Although I can readily ssh into the problematic drive on my
work computer, I am guessing that there is some sort of ssh issue that may
be related to my accessing the system through a VPN (using the Pulse Secure
app). On Friday, I'll bring my laptop into work and see if it works from
inside the work network.
Post by Adrian Klaver ***@aklaver.com [unison-users]
Post by Roderick Usher ***@gmail.com [unison-users]
Sorry, now that I look at it I see my email was sloppy. First off, the
subject is incorrect—it’s from an earlier email that I started and never
completed. Please ignore this. I’ve answered your questions below.
From below you are syncing from OS X to Windows, correct?
Post by Roderick Usher ***@gmail.com [unison-users]
I am syncing between OSX and linux. The remote computer is running Fedora 24.
Well I botched that:)
At this point I would say let's see what implementing Alan's suggestion
does for you?
Post by Roderick Usher ***@gmail.com [unison-users]
Post by Adrian Klaver ***@aklaver.com [unison-users]
1) Unison version(s) on both ends?
Unison version is 2.48.3 on the linux side, and 2.48.15 on the mac.
This is a combination I finally got to work without the OCaml bigarray
errors cropping up.
Post by Adrian Klaver ***@aklaver.com [unison-users]
2) OS X version?
10.12.5 (Sierra)
Post by Adrian Klaver ***@aklaver.com [unison-users]
3) Windows versions?
Fedora 24.
Post by Adrian Klaver ***@aklaver.com [unison-users]
4) Is the next file you mention below an image file also?
No, it also choked on a PDF file.
--
Adrian Klaver
Adrian Klaver adrian.klaver@aklaver.com [unison-users]
2017-07-05 16:45:45 UTC
Permalink
Post by Roderick Usher ***@gmail.com [unison-users]
Hi Alan and Adrian,
Thanks much for your help. I turned off hyperthreading and had the
same issue. I also changed another profile from syncing with the
network attached storage to the remote computer drive, and it also
stopped. However in this case no files were synced before I received a
"killed by signal 1" error.
So, it seems that when I change my work unison root from the network
attached storage to the local drive on my work computer, something goes
wrong. It seems to be independent of the actual files that are
transferred. Although I can readily ssh into the problematic drive on
my work computer, I am guessing that there is some sort of ssh issue
that may be related to my accessing the system through a VPN (using the
Pulse Secure app). On Friday, I'll bring my laptop into work and see
if it works from inside the work network.
Another possibility is that it is Unison cache problem. In the ~/.unison
directory there should be files starting with ar* and fp*. If you do
something like:

head -n 3 ar15d73504795578056710e428e7324019

you will see the roots the cache is for. The corresponding fp* will have
the same hash after the fp part. You can delete these files and retry
the sync. The downside is that for the first sync Unison will have to
rebuild everything, so if the profile covers a lot of files it may take
some time.
--
Adrian Klaver
***@aklaver.com
Adrian Klaver adrian.klaver@aklaver.com [unison-users]
2017-07-05 16:50:01 UTC
Permalink
Post by Roderick Usher ***@gmail.com [unison-users]
Hi Alan and Adrian,
Thanks much for your help. I turned off hyperthreading and had the
same issue. I also changed another profile from syncing with the
network attached storage to the remote computer drive, and it also
stopped. However in this case no files were synced before I received a
"killed by signal 1" error.
So, it seems that when I change my work unison root from the network
attached storage to the local drive on my work computer, something goes
wrong. It seems to be independent of the actual files that are
transferred. Although I can readily ssh into the problematic drive on
my work computer, I am guessing that there is some sort of ssh issue
that may be related to my accessing the system through a VPN (using the
Pulse Secure app). On Friday, I'll bring my laptop into work and see
if it works from inside the work network.
Another thought that you might try is to set up a new profile that was
never used against the network storage and see what happens.
--
Adrian Klaver
***@aklaver.com
Roderick Usher my.work.email.lists@gmail.com [unison-users]
2017-07-06 00:24:50 UTC
Permalink
Hi Adrian,

I tried removing the fp archives and also creating a new profile. In both cases, I get

2017-07-05 18:15:47.029 Unison[12509:979141] Warning Panel Returned 1
Killed by signal 1.
Illegal instruction: 4

Apple tells me this:
Termination Signal: Illegal instruction: 4
Termination Reason: Namespace SIGNAL, Code 0x4
Terminating Process: Unison [12475]

I am guessing the system is choking on something, but why it only happens on the remote computer directory is confusing to me.
Post by Roderick Usher ***@gmail.com [unison-users]
Hi Alan and Adrian,
Thanks much for your help. I turned off hyperthreading and had the same issue. I also changed another profile from syncing with the network attached storage to the remote computer drive, and it also stopped. However in this case no files were synced before I received a "killed by signal 1" error.
So, it seems that when I change my work unison root from the network attached storage to the local drive on my work computer, something goes wrong. It seems to be independent of the actual files that are transferred. Although I can readily ssh into the problematic drive on my work computer, I am guessing that there is some sort of ssh issue that may be related to my accessing the system through a VPN (using the Pulse Secure app). On Friday, I'll bring my laptop into work and see if it works from inside the work network.
Another thought that you might try is to set up a new profile that was never used against the network storage and see what happens.
--
Adrian Klaver
Adrian Klaver adrian.klaver@aklaver.com [unison-users]
2017-07-06 00:36:45 UTC
Permalink
Post by Roderick Usher ***@gmail.com [unison-users]
Hi Adrian,
I tried removing the fp archives and also creating a new profile. In both cases, I get
2017-07-05 18:15:47.029 Unison[12509:979141] Warning Panel Returned 1
Killed by signal 1.
Illegal instruction: 4
Termination Signal: Illegal instruction: 4
Termination Reason: Namespace SIGNAL, Code 0x4
Terminating Process: Unison [12475]
I am guessing the system is choking on something, but why it only
happens on the remote computer directory is confusing to me.
It's official, I'm stumped!
--
Adrian Klaver
***@aklaver.com


------------------------------------

------------------------------------


------------------------------------

Yahoo Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/unison-users/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/unison-users/join
(Yahoo! ID required)

<*> To change settings via email:
unison-users-***@yahoogroups.com
unison-users-***@yahoogroups.com

<*> To unsubscribe from this group, send an email to:
unison-users-***@yahoogroups.com

<*> Your use of Yahoo Groups is subject to:
https://info.yahoo.com/legal/us/yahoo/utos/terms/
Roderick Usher my.work.email.lists@gmail.com [unison-users]
2017-07-06 00:38:03 UTC
Permalink
Thanks for trying!
Post by Adrian Klaver ***@aklaver.com [unison-users]
Post by Roderick Usher ***@gmail.com [unison-users]
Hi Adrian,
I tried removing the fp archives and also creating a new profile. In both cases, I get
2017-07-05 18:15:47.029 Unison[12509:979141] Warning Panel Returned 1
Killed by signal 1.
Illegal instruction: 4
Termination Signal: Illegal instruction: 4
Termination Reason: Namespace SIGNAL, Code 0x4
Terminating Process: Unison [12475]
I am guessing the system is choking on something, but why it only happens on the remote computer directory is confusing to me.
It's official, I'm stumped!
--
Adrian Klaver
Alan Schmitt alan.schmitt@polytechnique.org [unison-users]
2017-07-06 06:51:35 UTC
Permalink
"RUmwelc[" == Roderick Usher my work email ***@gmail com [unison-users] <unison-users-***@yahoogroups.com> writes:

RUmwelc[> Thanks much for your help. I turned off hyperthreading and had the same
RUmwelc[> issue. I also changed another profile from syncing with the network
RUmwelc[> attached storage to the remote computer drive, and it also stopped.
RUmwelc[> However in this case no files were synced before I received a "killed by
RUmwelc[> signal 1" error.

What is the file system in the NAS? Because if Unison sees it as a local
storage, it may mis-identify it and try to do weird things.

Alan
--
OpenPGP Key ID : 040D0A3B4ED2E5C7
Monthly Athmospheric CO₂, Mauna Loa Obs. 2017-05: 409.65, 2016-05: 407.70
Roderick Usher my.work.email.lists@gmail.com [unison-users]
2017-07-06 13:45:39 UTC
Permalink
I don’t know, but it is the NAS that is working. It’s when I try to sync with the local drive on my work Fedora box things choke.

Yesterday I did a sync between an iMac and the local drive on my Fedora box, and that went fine. But when i try and do the same from my home macbook and the Fedora box I run into the problem.

So I am starting to favor that this is some weird ssh/vpn problem. I can rsync files over fine, so it isn’t an issue that is obvious to me.
Post by Alan Schmitt ***@polytechnique.org [unison-users]
RUmwelc[> Thanks much for your help. I turned off hyperthreading and had the same
RUmwelc[> issue. I also changed another profile from syncing with the network
RUmwelc[> attached storage to the remote computer drive, and it also stopped.
RUmwelc[> However in this case no files were synced before I received a "killed by
RUmwelc[> signal 1" error.
What is the file system in the NAS? Because if Unison sees it as a local
storage, it may mis-identify it and try to do weird things.
Alan
--
OpenPGP Key ID : 040D0A3B4ED2E5C7
Monthly Athmospheric CO₂, Mauna Loa Obs. 2017-05: 409.65, 2016-05: 407.70
Adrian Klaver adrian.klaver@aklaver.com [unison-users]
2017-07-06 14:23:06 UTC
Permalink
Post by Roderick Usher ***@gmail.com [unison-users]
I don’t know, but it is the NAS that is working. It’s when I try to sync with the local drive on my work Fedora box things choke.
Yesterday I did a sync between an iMac and the local drive on my Fedora box, and that went fine. But when i try and do the same from my home macbook and the Fedora box I run into the problem.
Are the OS X versions on the iMac and the Macbook the same?

How are you accessing the Fedora box from the iMac?
Post by Roderick Usher ***@gmail.com [unison-users]
So I am starting to favor that this is some weird ssh/vpn problem. I can rsync files over fine, so it isn’t an issue that is obvious to me.
Would it be possible to bring the Macbook to work and try syncing to the
Fedora box using just SSH?

Might help narrow the possibilities.
Post by Roderick Usher ***@gmail.com [unison-users]
Post by Alan Schmitt ***@polytechnique.org [unison-users]
RUmwelc[> Thanks much for your help. I turned off hyperthreading and had the same
RUmwelc[> issue. I also changed another profile from syncing with the network
RUmwelc[> attached storage to the remote computer drive, and it also stopped.
RUmwelc[> However in this case no files were synced before I received a "killed by
RUmwelc[> signal 1" error.
What is the file system in the NAS? Because if Unison sees it as a local
storage, it may mis-identify it and try to do weird things.
Alan
--
OpenPGP Key ID : 040D0A3B4ED2E5C7
Monthly Athmospheric CO₂, Mauna Loa Obs. 2017-05: 409.65, 2016-05: 407.70
--
Adrian Klaver
***@aklaver.com
Roderick Usher my.work.email.lists@gmail.com [unison-users]
2017-07-06 15:05:44 UTC
Permalink
Post by Adrian Klaver ***@aklaver.com [unison-users]
Post by Roderick Usher ***@gmail.com [unison-users]
I don’t know, but it is the NAS that is working. It’s when I try to sync with the local drive on my work Fedora box things choke.
Yesterday I did a sync between an iMac and the local drive on my Fedora box, and that went fine. But when i try and do the same from my home macbook and the Fedora box I run into the problem.
Are the OS X versions on the iMac and the Macbook the same?
Probably. Both are regularly updated as the latest version of OSX comes out. I’ll confirm tomorrow.
Post by Adrian Klaver ***@aklaver.com [unison-users]
How are you accessing the Fedora box from the iMac?
I connect with Pulse Secure, the officially supported VPN, and then ssh (via my unison profile).
Post by Adrian Klaver ***@aklaver.com [unison-users]
Post by Roderick Usher ***@gmail.com [unison-users]
So I am starting to favor that this is some weird ssh/vpn problem. I can rsync files over fine, so it isn’t an issue that is obvious to me.
Would it be possible to bring the Macbook to work and try syncing to the Fedora box using just SSH?
Yes, I will try that tomorrow. I’ll be away from the office today.
Post by Adrian Klaver ***@aklaver.com [unison-users]
Might help narrow the possibilities.
Thanks.
Post by Adrian Klaver ***@aklaver.com [unison-users]
Post by Roderick Usher ***@gmail.com [unison-users]
Post by Alan Schmitt ***@polytechnique.org [unison-users]
RUmwelc[> Thanks much for your help. I turned off hyperthreading and had the same
RUmwelc[> issue. I also changed another profile from syncing with the network
RUmwelc[> attached storage to the remote computer drive, and it also stopped.
RUmwelc[> However in this case no files were synced before I received a "killed by
RUmwelc[> signal 1" error.
What is the file system in the NAS? Because if Unison sees it as a local
storage, it may mis-identify it and try to do weird things.
Alan
--
OpenPGP Key ID : 040D0A3B4ED2E5C7
Monthly Athmospheric CO₂, Mauna Loa Obs. 2017-05: 409.65, 2016-05: 407.70
--
Adrian Klaver
Roderick Usher my.work.email.lists@gmail.com [unison-users]
2017-07-08 12:38:44 UTC
Permalink
Just a quick update—I brought my laptop into work and used the work network, but ran into the same problem. I need to leave for some travel, so I won’t be able to work on this problem for a while, but I wanted to thank everyone for your great ideas. I’ll post if I ever solve the issue.
Post by Roderick Usher ***@gmail.com [unison-users]
Post by Adrian Klaver ***@aklaver.com [unison-users]
Post by Roderick Usher ***@gmail.com [unison-users]
I don’t know, but it is the NAS that is working. It’s when I try to sync with the local drive on my work Fedora box things choke.
Yesterday I did a sync between an iMac and the local drive on my Fedora box, and that went fine. But when i try and do the same from my home macbook and the Fedora box I run into the problem.
Are the OS X versions on the iMac and the Macbook the same?
Probably. Both are regularly updated as the latest version of OSX comes out. I’ll confirm tomorrow.
Post by Adrian Klaver ***@aklaver.com [unison-users]
How are you accessing the Fedora box from the iMac?
I connect with Pulse Secure, the officially supported VPN, and then ssh (via my unison profile).
Post by Adrian Klaver ***@aklaver.com [unison-users]
Post by Roderick Usher ***@gmail.com [unison-users]
So I am starting to favor that this is some weird ssh/vpn problem. I can rsync files over fine, so it isn’t an issue that is obvious to me.
Would it be possible to bring the Macbook to work and try syncing to the Fedora box using just SSH?
Yes, I will try that tomorrow. I’ll be away from the office today.
Post by Adrian Klaver ***@aklaver.com [unison-users]
Might help narrow the possibilities.
Thanks.
Post by Adrian Klaver ***@aklaver.com [unison-users]
Post by Roderick Usher ***@gmail.com [unison-users]
Post by Alan Schmitt ***@polytechnique.org [unison-users]
RUmwelc[> Thanks much for your help. I turned off hyperthreading and had the same
RUmwelc[> issue. I also changed another profile from syncing with the network
RUmwelc[> attached storage to the remote computer drive, and it also stopped.
RUmwelc[> However in this case no files were synced before I received a "killed by
RUmwelc[> signal 1" error.
What is the file system in the NAS? Because if Unison sees it as a local
storage, it may mis-identify it and try to do weird things.
Alan
--
OpenPGP Key ID : 040D0A3B4ED2E5C7
Monthly Athmospheric CO₂, Mauna Loa Obs. 2017-05: 409.65, 2016-05: 407.70
--
Adrian Klaver
Loading...