Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update link in web interface does not work on OpenBSD. #1272

Closed
vext01 opened this issue Jan 19, 2015 · 22 comments
Closed

Update link in web interface does not work on OpenBSD. #1272

vext01 opened this issue Jan 19, 2015 · 22 comments
Assignees
Labels

Comments

@vext01
Copy link

@vext01 vext01 commented Jan 19, 2015

If you click the update link on the web interface on OpenBSD, you will get an error:

upgrading: readlink /proc/curproc/file: no such file or directory

OpenBSD (and probably some other UNIXs) does not have /proc.

Presumably you are trying to get the server's PID? It is typical to write a PID file into /var/run.

Thanks

@kozec
Copy link
Contributor

@kozec kozec commented Jan 19, 2015

/proc/curproc/file will return filename of current process, not PID. Shouldn't that be same thing as os.Args[0] ?

@AudriusButkevicius
Copy link
Member

@AudriusButkevicius AudriusButkevicius commented Jan 19, 2015

@AudriusButkevicius
Copy link
Member

@AudriusButkevicius AudriusButkevicius commented Jan 19, 2015

I agree though that os.Args[0] should be sufficient.
Though some programs do patch that up to show up under a different name in the process tree.

@kozec
Copy link
Contributor

@kozec kozec commented Jan 19, 2015

Targets OpenBSD specifically, so I am a bit puzzled why it's not there.

Unlike Linux, ObenBSD supports procfs only as optional feature and only on some architectures.

//edit: rephrased

@AudriusButkevicius
Copy link
Member

@AudriusButkevicius AudriusButkevicius commented Jan 19, 2015

I'll have to wait for @calmh to answer this.

@calmh
Copy link
Member

@calmh calmh commented Jan 22, 2015

Right. So this only works on the OpenBSDs that have a /proc. We need /proc to find the location of the binary so we can upgrade it. We should probably just do this check earlier and disable auto upgrades if we can't determine the binary location.

(os.Args[0] is what the user called the binary as, which may not contain the path)

@calmh calmh added the enhancement label Jan 22, 2015
@AudriusButkevicius
Copy link
Member

@AudriusButkevicius AudriusButkevicius commented Jan 22, 2015

Isn't filepath.Join(os.Getwd(), os.Args[0]) still the same thing?
I cannot see how you could invoke the binary differently.

@calmh
Copy link
Member

@calmh calmh commented Jan 22, 2015

If I just type syncthing in my home directory, os.Args[0] is syncthing, Getwd() is my home directory, the binary might be anywhere in my $PATH. There are other corner cases, but point is Args[0] isn't the truth.

@AudriusButkevicius
Copy link
Member

@AudriusButkevicius AudriusButkevicius commented Jan 22, 2015

Ah yes, I am just used to not having anything in my path.

@calmh
Copy link
Member

@calmh calmh commented Nov 22, 2015

Without /proc we can't determine our binary location and can't auto upgrade. Closing.

@calmh calmh closed this Nov 22, 2015
@mulander
Copy link

@mulander mulander commented Nov 22, 2015

Maybe adding an optional binary location config path would help solving the issue? People who prefer auto updates could set their location this way making it independent off /proc.

@calmh
Copy link
Member

@calmh calmh commented Nov 22, 2015

Maybe one of the three OpenBSD users feel strongly enough about this to propose a patch. :D

@canton7
Copy link
Member

@canton7 canton7 commented Nov 22, 2015

If you look at the github download stats, there are at least 160 of them...

@calmh
Copy link
Member

@calmh calmh commented Nov 22, 2015

No problem then.

@mulander
Copy link

@mulander mulander commented Nov 22, 2015

@calmh I'll provide a patch with the proposed config option solution. Stay tuned ;)

@calmh
Copy link
Member

@calmh calmh commented Nov 22, 2015

@mulander Maybe just fall back to argv[0] and if that's not an absolute path explain the problem to the user?

@mulander
Copy link

@mulander mulander commented Nov 22, 2015

@calmh sounds reasonable to me. I just finished work for today so will spent some time trying out options - will avoid adding new config for it and will report back with a patch or more info.

@AudriusButkevicius
Copy link
Member

@AudriusButkevicius AudriusButkevicius commented Nov 22, 2015

Or check $PATH/srgv[0]

@mulander
Copy link

@mulander mulander commented Nov 22, 2015

@calmh @AudriusButkevicius I was on my way to do a best effort implementation and finally found out how syncthing locates the current executable. It seems that you guys depend on a frozen version of kardianos/osext using Godeps.

Seems that this whole issue is already fixed upstream and all you need is to pull this commit provided by ajacoutot who is an OpenBSD developer.

@AudriusButkevicius
Copy link
Member

@AudriusButkevicius AudriusButkevicius commented Nov 22, 2015

Right, we only need to upgrade that then.

@plouj
Copy link
Contributor

@plouj plouj commented Dec 21, 2015

On a related note, could you also pull in the changes from kardianos/osext@431e263 ? I tried to do it myself, but I can't figure out godep :(

@calmh
Copy link
Member

@calmh calmh commented Dec 22, 2015

There you go. Shutting down this issue to avoid piling more things on it. ;)

@syncthing syncthing locked and limited conversation to collaborators Dec 22, 2015
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
7 participants
You can’t perform that action at this time.