deployer: When control path = 104 'the too long for Unix domain socket' is fired.

Q A
Issue Type Bug
Deployer Version 6.0.3
Local Machine OS MAC
Remote Machine OS ?

Description

If you’re reporting a bug, please include following information

Steps to reproduce

Content of deploy.php

When https://github.com/deployphp/deployer/blob/15274524b28c94e5967fa509a91680f599ddd23d/src/Ssh/Arguments.php#L128 equals to

Output log

With enabled option for verbose output -vvv.

  [Deployer\Exception\RuntimeException (-1)]
  The command "rm -f /srv/http/<username>/.dep/deploy.lock" failed.
  Exit Code: -1 (Unknown error)
  Host Name: acceptance
  ================
  unix_listener: "<path with 104 chars>" too long for Unix domain
   socket

About this issue

  • Original URL
  • State: closed
  • Created 7 years ago
  • Reactions: 5
  • Comments: 15 (12 by maintainers)

Commits related to this issue

Most upvoted comments

Hi 🙋‍♂️,

A quick fix for those who are stuck: you can disable ssh multiplexing by adding the snippet below into your deployer config:

set('ssh_multiplexing', false);

Also, since @giraz82 describes that this is about a socket. Would it be an option to place the socket file in another directory? /var/run would be preferred, but since we’ll run into permission problems I’d say that /tmp would also suffice.

Alright, it’s been a bit more then a week. 😬

I’ve just debugged the generateControlPath() a bit. I have a hostname that is 62 characters long, on port 22. Therefor $controlPath (which is checked on string length) becomes: deployer_[a-hostname-of-62-characters]:22, which results in a strlen of 74 which is easily within the 104 limit. Although, this does not take in account that this file will appended with a connection hash which, strangely isn’t actually appended to the file. Which might result in the following: deployer_[a-hostname-of-62-characters]:22.H0tQPCvXD48DN6lN, but again, even this should be within the 104 limit, so what’s up?

UNIX_PATH_MAX, that’s what’s up. After a bit of Googling this defines the max length for the domain sockets, it appears that this might be a bit different per OS. As far as I can tell, this is 104 for Mac OS and 108 for Linux. So, still, not less than what we’re checking on; 104. After some testing and manually creating control paths, I found out that this includes the entire, expanded, absolute path to the file.

So, I’ve been looking if it’s possible to evaluate OpenSSH tokens like %C without starting an actual connection, but I’ve been unable to find a solution for this. Therefor, I think it’d be best if we just keep calculating, but keep in mind that;

  1. The absolute path to the home dir needs to be included in the total length
  2. The prepended length (which seems to be 16) of the connection hash has to be included in the total length.

Also, I noticed that most of the case’s do not use the .ssh subfolder, which I guess is a mistake.

I’ve worked out above and will be submitting a pull request later.

Only thing I can think of is that the method could construct the paths itself? I do think the length check is valuable by itself, if it worked correctly. I might be able to create a patch later this week as a suggestion, not sure yet though.

@antonmedv how does generateControlPath() replace them with SSH before checking up on the length?

@nstapelbroek I’m not entirely sure what the security implications the /tmp folder brings. Though, there are some sources (only one I can find now is wikibooks.org) which imply that it would be a bad idea. Also, I’m not sure about showing files with the usernames / hostnames / ports in the /tmp folder. Though, might not be as bad as I initially thought?

Hi, yes it pissible to fix, kets use real path instead of ~