svn commands fail with SSL: bad packet length on Solaris
1
I have a host with Solaris installed:
# uname -a
SunOS <hostname> 5.10 Generic_147147-26 sun4u sparc SUNW,Sun-Fire-V250
When I'm trying to execute any svn command as non-root user to a remote repository I'm getting SSL error:
<username># svn log https://svn.example.com/repository/file
SSL negotiation failed: SSL error: bad packet length
But if I switch to a root user everything seems to work fine:
root# svn log https://svn.example.com/repository/file
Authentication realm: <https://svn.example.com:443>
Password for 'root':
I've tried to remove ssl.svn.server/<hash> file for remote host and this works for root account (I have to accept the certificate again) but I'm getting the same SSL error for non-root user.
Any ideas how to fix this?
ssl svn solaris
asked Nov 14 '18 at 10:02
GGorgeGGorge
82
add a comment |
1
I have a host with Solaris installed:
# uname -a
SunOS <hostname> 5.10 Generic_147147-26 sun4u sparc SUNW,Sun-Fire-V250
When I'm trying to execute any svn command as non-root user to a remote repository I'm getting SSL error:
<username># svn log https://svn.example.com/repository/file
SSL negotiation failed: SSL error: bad packet length
But if I switch to a root user everything seems to work fine:
root# svn log https://svn.example.com/repository/file
Authentication realm: <https://svn.example.com:443>
Password for 'root':
I've tried to remove ssl.svn.server/<hash> file for remote host and this works for root account (I have to accept the certificate again) but I'm getting the same SSL error for non-root user.
Any ideas how to fix this?
ssl svn solaris
asked Nov 14 '18 at 10:02
GGorgeGGorge
82
Post the output fromwhich svnand thenldd -s /path/to/svnfor bothrootand your normal user account. You might have differences in environment variables such asPATHandLD_LIBRARY_PATH.
– Andrew Henle
Nov 14 '18 at 10:36
The result ofusername# which svnis/opt/local/bin/svn. Subversion is not installed for root so I was using/opt/local/bin/svn log .... I've tried to do ldd for both users and gotldd: /opt/local/bin/svn: unsupported or unknown file type
– GGorge
Nov 14 '18 at 12:41
That probably means/opt/local/bin/svnis a script. Still, it's probably an environment difference. Do you have anyLD_LIBRARY_PATHenvironment variables set for eitherrootor your user account?env | grep LD_will show them. Don't just look forLD_LIBRARY_PATH.
– Andrew Henle
Nov 14 '18 at 13:25
Only user hasLD_LIBRARY_PATHin his environment. root does not have anything withLD_. Weird thing is that I have several almost identical Solaris hosts that share the same home directory and environment for each non-root user (automount, etc.) and svn works just fine on them.
– GGorge
Nov 15 '18 at 6:48
add a comment |
1
1
1
I have a host with Solaris installed:
# uname -a
SunOS <hostname> 5.10 Generic_147147-26 sun4u sparc SUNW,Sun-Fire-V250
When I'm trying to execute any svn command as non-root user to a remote repository I'm getting SSL error:
<username># svn log https://svn.example.com/repository/file
SSL negotiation failed: SSL error: bad packet length
But if I switch to a root user everything seems to work fine:
root# svn log https://svn.example.com/repository/file
Authentication realm: <https://svn.example.com:443>
Password for 'root':
I've tried to remove ssl.svn.server/<hash> file for remote host and this works for root account (I have to accept the certificate again) but I'm getting the same SSL error for non-root user.
Any ideas how to fix this?
ssl svn solaris
asked Nov 14 '18 at 10:02
GGorgeGGorge
82
I have a host with Solaris installed:
# uname -a
SunOS <hostname> 5.10 Generic_147147-26 sun4u sparc SUNW,Sun-Fire-V250
When I'm trying to execute any svn command as non-root user to a remote repository I'm getting SSL error:
<username># svn log https://svn.example.com/repository/file
SSL negotiation failed: SSL error: bad packet length
But if I switch to a root user everything seems to work fine:
root# svn log https://svn.example.com/repository/file
Authentication realm: <https://svn.example.com:443>
Password for 'root':
I've tried to remove ssl.svn.server/<hash> file for remote host and this works for root account (I have to accept the certificate again) but I'm getting the same SSL error for non-root user.
Any ideas how to fix this?
ssl svn solaris
ssl svn solaris
asked Nov 14 '18 at 10:02
GGorgeGGorge
82
asked Nov 14 '18 at 10:02
GGorgeGGorge
82
asked Nov 14 '18 at 10:02
GGorgeGGorge
82
asked Nov 14 '18 at 10:02
GGorgeGGorge
82
asked Nov 14 '18 at 10:02
GGorgeGGorge
82
82
Post the output fromwhich svnand thenldd -s /path/to/svnfor bothrootand your normal user account. You might have differences in environment variables such asPATHandLD_LIBRARY_PATH.
– Andrew Henle
Nov 14 '18 at 10:36
The result ofusername# which svnis/opt/local/bin/svn. Subversion is not installed for root so I was using/opt/local/bin/svn log .... I've tried to do ldd for both users and gotldd: /opt/local/bin/svn: unsupported or unknown file type
– GGorge
Nov 14 '18 at 12:41
That probably means/opt/local/bin/svnis a script. Still, it's probably an environment difference. Do you have anyLD_LIBRARY_PATHenvironment variables set for eitherrootor your user account?env | grep LD_will show them. Don't just look forLD_LIBRARY_PATH.
– Andrew Henle
Nov 14 '18 at 13:25
Only user hasLD_LIBRARY_PATHin his environment. root does not have anything withLD_. Weird thing is that I have several almost identical Solaris hosts that share the same home directory and environment for each non-root user (automount, etc.) and svn works just fine on them.
– GGorge
Nov 15 '18 at 6:48
add a comment |
Post the output fromwhich svnand thenldd -s /path/to/svnfor bothrootand your normal user account. You might have differences in environment variables such asPATHandLD_LIBRARY_PATH.
– Andrew Henle
Nov 14 '18 at 10:36
The result ofusername# which svnis/opt/local/bin/svn. Subversion is not installed for root so I was using/opt/local/bin/svn log .... I've tried to do ldd for both users and gotldd: /opt/local/bin/svn: unsupported or unknown file type
– GGorge
Nov 14 '18 at 12:41
That probably means/opt/local/bin/svnis a script. Still, it's probably an environment difference. Do you have anyLD_LIBRARY_PATHenvironment variables set for eitherrootor your user account?env | grep LD_will show them. Don't just look forLD_LIBRARY_PATH.
– Andrew Henle
Nov 14 '18 at 13:25
Only user hasLD_LIBRARY_PATHin his environment. root does not have anything withLD_. Weird thing is that I have several almost identical Solaris hosts that share the same home directory and environment for each non-root user (automount, etc.) and svn works just fine on them.
– GGorge
Nov 15 '18 at 6:48
Post the output from
which svn and then ldd -s /path/to/svn for both root and your normal user account. You might have differences in environment variables such as PATH and LD_LIBRARY_PATH.– Andrew Henle
Nov 14 '18 at 10:36
Post the output from
which svn and then ldd -s /path/to/svn for both root and your normal user account. You might have differences in environment variables such as PATH and LD_LIBRARY_PATH.– Andrew Henle
Nov 14 '18 at 10:36
The result of
username# which svn is /opt/local/bin/svn. Subversion is not installed for root so I was using /opt/local/bin/svn log .... I've tried to do ldd for both users and got ldd: /opt/local/bin/svn: unsupported or unknown file type– GGorge
Nov 14 '18 at 12:41
The result of
username# which svn is /opt/local/bin/svn. Subversion is not installed for root so I was using /opt/local/bin/svn log .... I've tried to do ldd for both users and got ldd: /opt/local/bin/svn: unsupported or unknown file type– GGorge
Nov 14 '18 at 12:41
That probably means
/opt/local/bin/svn is a script. Still, it's probably an environment difference. Do you have any LD_LIBRARY_PATH environment variables set for either root or your user account? env | grep LD_ will show them. Don't just look for LD_LIBRARY_PATH.– Andrew Henle
Nov 14 '18 at 13:25
That probably means
/opt/local/bin/svn is a script. Still, it's probably an environment difference. Do you have any LD_LIBRARY_PATH environment variables set for either root or your user account? env | grep LD_ will show them. Don't just look for LD_LIBRARY_PATH.– Andrew Henle
Nov 14 '18 at 13:25
Only user has
LD_LIBRARY_PATH in his environment. root does not have anything with LD_. Weird thing is that I have several almost identical Solaris hosts that share the same home directory and environment for each non-root user (automount, etc.) and svn works just fine on them.– GGorge
Nov 15 '18 at 6:48
Only user has
LD_LIBRARY_PATH in his environment. root does not have anything with LD_. Weird thing is that I have several almost identical Solaris hosts that share the same home directory and environment for each non-root user (automount, etc.) and svn works just fine on them.– GGorge
Nov 15 '18 at 6:48
add a comment |
1 Answer
1
active
oldest
votes
0
Is it possible that the regular user "username" had accepted a previous/different certificate from that host?
You may try to remove or rename the .svn directory into your "username" home and see if it solves the issue: if this is the case probably your "username" have stored some wrong setting in its .svn settings files.
Is it possible that root and "usarname" are using a different svn executable due to $PATH order? (You may check it using which svn command).
Hope it helps.
answered Nov 14 '18 at 10:30
ss900iess900ie
111
I've checked the certificates manually and they are exactly the same. I've even copied root certificate to username and still got bad packet lenght error.
– GGorge
Nov 14 '18 at 12:50
Which version of svn are your running on the client side and on the server side? Have you tried removing the .svn in the home of "username"? I feel like there might be an issue in the conf files.
– ss900ie
Nov 14 '18 at 13:36
Alternatively you may try with a different non-root user to understand if the issue it related to your "username" settings or it's due to machine settings. I'd use a fresh new user for this test.
– ss900ie
Nov 14 '18 at 13:50
svn is kinda outdated:svn, version 1.6.3 (r38063)Unfortunately I can't verify svn version on a server side. But root and non-root users both use the same binary/script to connect to a server so I'm guessing that this problem exists not because of version differencies. I've also tried to remove.subversionfrom non-root user home directory and it didn't help: svn command creates another one and still throws bad packet length error. The problem also persists for other non-root users (and I've got plenty of them on this host).
– GGorge
Nov 15 '18 at 7:01
@GGorge, wow this seems to be a very hard problem, are the regular users able to access ssl global configuration files in/etc/ssl,/opt/etc/ssland/etc/certs? Having some more time I'd try one (or both) of the following: * Compile and/or install a newer svn version on the users area (svn is not that difficult to compile on Solaris if you have the build tools) * Run regular users svn under truss to try understanding if the failure is related to some permission issue or library load issue I know these are time consuming but honestly I have no better ideas.
– ss900ie
Nov 15 '18 at 14:24
|
show 2 more comments
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
draft saved
draft discarded
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53297511%2fsvn-commands-fail-with-ssl-bad-packet-length-on-solaris%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
0
Is it possible that the regular user "username" had accepted a previous/different certificate from that host?
You may try to remove or rename the .svn directory into your "username" home and see if it solves the issue: if this is the case probably your "username" have stored some wrong setting in its .svn settings files.
Is it possible that root and "usarname" are using a different svn executable due to $PATH order? (You may check it using which svn command).
Hope it helps.
answered Nov 14 '18 at 10:30
ss900iess900ie
111
I've checked the certificates manually and they are exactly the same. I've even copied root certificate to username and still got bad packet lenght error.
– GGorge
Nov 14 '18 at 12:50
Which version of svn are your running on the client side and on the server side? Have you tried removing the .svn in the home of "username"? I feel like there might be an issue in the conf files.
– ss900ie
Nov 14 '18 at 13:36
Alternatively you may try with a different non-root user to understand if the issue it related to your "username" settings or it's due to machine settings. I'd use a fresh new user for this test.
– ss900ie
Nov 14 '18 at 13:50
svn is kinda outdated:svn, version 1.6.3 (r38063)Unfortunately I can't verify svn version on a server side. But root and non-root users both use the same binary/script to connect to a server so I'm guessing that this problem exists not because of version differencies. I've also tried to remove.subversionfrom non-root user home directory and it didn't help: svn command creates another one and still throws bad packet length error. The problem also persists for other non-root users (and I've got plenty of them on this host).
– GGorge
Nov 15 '18 at 7:01
@GGorge, wow this seems to be a very hard problem, are the regular users able to access ssl global configuration files in/etc/ssl,/opt/etc/ssland/etc/certs? Having some more time I'd try one (or both) of the following: * Compile and/or install a newer svn version on the users area (svn is not that difficult to compile on Solaris if you have the build tools) * Run regular users svn under truss to try understanding if the failure is related to some permission issue or library load issue I know these are time consuming but honestly I have no better ideas.
– ss900ie
Nov 15 '18 at 14:24
|
show 2 more comments
0
Is it possible that the regular user "username" had accepted a previous/different certificate from that host?
You may try to remove or rename the .svn directory into your "username" home and see if it solves the issue: if this is the case probably your "username" have stored some wrong setting in its .svn settings files.
Is it possible that root and "usarname" are using a different svn executable due to $PATH order? (You may check it using which svn command).
Hope it helps.
answered Nov 14 '18 at 10:30
ss900iess900ie
111
I've checked the certificates manually and they are exactly the same. I've even copied root certificate to username and still got bad packet lenght error.
– GGorge
Nov 14 '18 at 12:50
Which version of svn are your running on the client side and on the server side? Have you tried removing the .svn in the home of "username"? I feel like there might be an issue in the conf files.
– ss900ie
Nov 14 '18 at 13:36
Alternatively you may try with a different non-root user to understand if the issue it related to your "username" settings or it's due to machine settings. I'd use a fresh new user for this test.
– ss900ie
Nov 14 '18 at 13:50
svn is kinda outdated:svn, version 1.6.3 (r38063)Unfortunately I can't verify svn version on a server side. But root and non-root users both use the same binary/script to connect to a server so I'm guessing that this problem exists not because of version differencies. I've also tried to remove.subversionfrom non-root user home directory and it didn't help: svn command creates another one and still throws bad packet length error. The problem also persists for other non-root users (and I've got plenty of them on this host).
– GGorge
Nov 15 '18 at 7:01
@GGorge, wow this seems to be a very hard problem, are the regular users able to access ssl global configuration files in/etc/ssl,/opt/etc/ssland/etc/certs? Having some more time I'd try one (or both) of the following: * Compile and/or install a newer svn version on the users area (svn is not that difficult to compile on Solaris if you have the build tools) * Run regular users svn under truss to try understanding if the failure is related to some permission issue or library load issue I know these are time consuming but honestly I have no better ideas.
– ss900ie
Nov 15 '18 at 14:24
|
show 2 more comments
0
0
0
Is it possible that the regular user "username" had accepted a previous/different certificate from that host?
You may try to remove or rename the .svn directory into your "username" home and see if it solves the issue: if this is the case probably your "username" have stored some wrong setting in its .svn settings files.
Is it possible that root and "usarname" are using a different svn executable due to $PATH order? (You may check it using which svn command).
Hope it helps.
answered Nov 14 '18 at 10:30
ss900iess900ie
111
Is it possible that the regular user "username" had accepted a previous/different certificate from that host?
You may try to remove or rename the .svn directory into your "username" home and see if it solves the issue: if this is the case probably your "username" have stored some wrong setting in its .svn settings files.
Is it possible that root and "usarname" are using a different svn executable due to $PATH order? (You may check it using which svn command).
Hope it helps.
answered Nov 14 '18 at 10:30
ss900iess900ie
111
answered Nov 14 '18 at 10:30
ss900iess900ie
111
answered Nov 14 '18 at 10:30
ss900iess900ie
111
answered Nov 14 '18 at 10:30
ss900iess900ie
111
111
I've checked the certificates manually and they are exactly the same. I've even copied root certificate to username and still got bad packet lenght error.
– GGorge
Nov 14 '18 at 12:50
Which version of svn are your running on the client side and on the server side? Have you tried removing the .svn in the home of "username"? I feel like there might be an issue in the conf files.
– ss900ie
Nov 14 '18 at 13:36
Alternatively you may try with a different non-root user to understand if the issue it related to your "username" settings or it's due to machine settings. I'd use a fresh new user for this test.
– ss900ie
Nov 14 '18 at 13:50
svn is kinda outdated:svn, version 1.6.3 (r38063)Unfortunately I can't verify svn version on a server side. But root and non-root users both use the same binary/script to connect to a server so I'm guessing that this problem exists not because of version differencies. I've also tried to remove.subversionfrom non-root user home directory and it didn't help: svn command creates another one and still throws bad packet length error. The problem also persists for other non-root users (and I've got plenty of them on this host).
– GGorge
Nov 15 '18 at 7:01
@GGorge, wow this seems to be a very hard problem, are the regular users able to access ssl global configuration files in/etc/ssl,/opt/etc/ssland/etc/certs? Having some more time I'd try one (or both) of the following: * Compile and/or install a newer svn version on the users area (svn is not that difficult to compile on Solaris if you have the build tools) * Run regular users svn under truss to try understanding if the failure is related to some permission issue or library load issue I know these are time consuming but honestly I have no better ideas.
– ss900ie
Nov 15 '18 at 14:24
|
show 2 more comments
I've checked the certificates manually and they are exactly the same. I've even copied root certificate to username and still got bad packet lenght error.
– GGorge
Nov 14 '18 at 12:50
Which version of svn are your running on the client side and on the server side? Have you tried removing the .svn in the home of "username"? I feel like there might be an issue in the conf files.
– ss900ie
Nov 14 '18 at 13:36
Alternatively you may try with a different non-root user to understand if the issue it related to your "username" settings or it's due to machine settings. I'd use a fresh new user for this test.
– ss900ie
Nov 14 '18 at 13:50
svn is kinda outdated:svn, version 1.6.3 (r38063)Unfortunately I can't verify svn version on a server side. But root and non-root users both use the same binary/script to connect to a server so I'm guessing that this problem exists not because of version differencies. I've also tried to remove.subversionfrom non-root user home directory and it didn't help: svn command creates another one and still throws bad packet length error. The problem also persists for other non-root users (and I've got plenty of them on this host).
– GGorge
Nov 15 '18 at 7:01
@GGorge, wow this seems to be a very hard problem, are the regular users able to access ssl global configuration files in/etc/ssl,/opt/etc/ssland/etc/certs? Having some more time I'd try one (or both) of the following: * Compile and/or install a newer svn version on the users area (svn is not that difficult to compile on Solaris if you have the build tools) * Run regular users svn under truss to try understanding if the failure is related to some permission issue or library load issue I know these are time consuming but honestly I have no better ideas.
– ss900ie
Nov 15 '18 at 14:24
I've checked the certificates manually and they are exactly the same. I've even copied root certificate to username and still got bad packet lenght error.
– GGorge
Nov 14 '18 at 12:50
I've checked the certificates manually and they are exactly the same. I've even copied root certificate to username and still got bad packet lenght error.
– GGorge
Nov 14 '18 at 12:50
Which version of svn are your running on the client side and on the server side? Have you tried removing the .svn in the home of "username"? I feel like there might be an issue in the conf files.
– ss900ie
Nov 14 '18 at 13:36
Which version of svn are your running on the client side and on the server side? Have you tried removing the .svn in the home of "username"? I feel like there might be an issue in the conf files.
– ss900ie
Nov 14 '18 at 13:36
Alternatively you may try with a different non-root user to understand if the issue it related to your "username" settings or it's due to machine settings. I'd use a fresh new user for this test.
– ss900ie
Nov 14 '18 at 13:50
Alternatively you may try with a different non-root user to understand if the issue it related to your "username" settings or it's due to machine settings. I'd use a fresh new user for this test.
– ss900ie
Nov 14 '18 at 13:50
svn is kinda outdated:
svn, version 1.6.3 (r38063) Unfortunately I can't verify svn version on a server side. But root and non-root users both use the same binary/script to connect to a server so I'm guessing that this problem exists not because of version differencies. I've also tried to remove .subversion from non-root user home directory and it didn't help: svn command creates another one and still throws bad packet length error. The problem also persists for other non-root users (and I've got plenty of them on this host).– GGorge
Nov 15 '18 at 7:01
svn is kinda outdated:
svn, version 1.6.3 (r38063) Unfortunately I can't verify svn version on a server side. But root and non-root users both use the same binary/script to connect to a server so I'm guessing that this problem exists not because of version differencies. I've also tried to remove .subversion from non-root user home directory and it didn't help: svn command creates another one and still throws bad packet length error. The problem also persists for other non-root users (and I've got plenty of them on this host).– GGorge
Nov 15 '18 at 7:01
@GGorge, wow this seems to be a very hard problem, are the regular users able to access ssl global configuration files in
/etc/ssl, /opt/etc/ssl and /etc/certs? Having some more time I'd try one (or both) of the following: * Compile and/or install a newer svn version on the users area (svn is not that difficult to compile on Solaris if you have the build tools) * Run regular users svn under truss to try understanding if the failure is related to some permission issue or library load issue I know these are time consuming but honestly I have no better ideas.– ss900ie
Nov 15 '18 at 14:24
@GGorge, wow this seems to be a very hard problem, are the regular users able to access ssl global configuration files in
/etc/ssl, /opt/etc/ssl and /etc/certs? Having some more time I'd try one (or both) of the following: * Compile and/or install a newer svn version on the users area (svn is not that difficult to compile on Solaris if you have the build tools) * Run regular users svn under truss to try understanding if the failure is related to some permission issue or library load issue I know these are time consuming but honestly I have no better ideas.– ss900ie
Nov 15 '18 at 14:24
|
show 2 more comments
draft saved
draft discarded
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
draft saved
draft discarded
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53297511%2fsvn-commands-fail-with-ssl-bad-packet-length-on-solaris%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Post the output from
which svnand thenldd -s /path/to/svnfor bothrootand your normal user account. You might have differences in environment variables such asPATHandLD_LIBRARY_PATH.– Andrew Henle
Nov 14 '18 at 10:36
The result of
username# which svnis/opt/local/bin/svn. Subversion is not installed for root so I was using/opt/local/bin/svn log .... I've tried to do ldd for both users and gotldd: /opt/local/bin/svn: unsupported or unknown file type– GGorge
Nov 14 '18 at 12:41
That probably means
/opt/local/bin/svnis a script. Still, it's probably an environment difference. Do you have anyLD_LIBRARY_PATHenvironment variables set for eitherrootor your user account?env | grep LD_will show them. Don't just look forLD_LIBRARY_PATH.– Andrew Henle
Nov 14 '18 at 13:25
Only user has
LD_LIBRARY_PATHin his environment. root does not have anything withLD_. Weird thing is that I have several almost identical Solaris hosts that share the same home directory and environment for each non-root user (automount, etc.) and svn works just fine on them.– GGorge
Nov 15 '18 at 6:48