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

VIV_PORT environment variable not set automatically #157

Closed
rhatos opened this issue Aug 5, 2024 · 22 comments
Closed

VIV_PORT environment variable not set automatically #157

rhatos opened this issue Aug 5, 2024 · 22 comments
Labels
type:bug Something isn't working

Comments

@rhatos
Copy link

rhatos commented Aug 5, 2024

Hi, great project!

I had some issues getting it working initially.

Running viv . in my terminal just resulted in it hanging indefinitely.

I tried out the development version and it worked immediately.

Maybe I'm not that experienced but the only way I got it to work without being in dev mode was to set the VIV_PORT environment variable manually in /etc/environment and relogging.

I installed it through the AUR and also ended up compiling it myself.

@rhatos rhatos added the type:bug Something isn't working label Aug 5, 2024
@jannis-baum
Copy link
Owner

jannis-baum commented Aug 5, 2024

Hello! Great to hear you like the project! Could you try reproducing the behavior of viv . just hanging indefinitely and then instead running vivify-server . and letting us know what the output is? Here we should see an error message.

@rhatos
Copy link
Author

rhatos commented Aug 5, 2024

Sure, I removed the environment variable and relogged, ran viv . and then ran vivify-server .

Below is the error.

node:internal/url:797
    this.#updateContext(bindingUrl.parse(input, base));
                                   ^

TypeError: Invalid URL
    at new URL (node:internal/url:797:36)
    at new ClientRequest (node:_http_client:135:30)
    at request (node:http:103:10)
    at get (node:http:114:15)
    at 1145 (build/bundle.js:2:1566497)
    at __webpack_require__ (build/bundle.js:2:3748442)
    at build/bundle.js:2:3749702
    at build/bundle.js:2:3749729
    at embedderRunCjs (node:internal/util/embedding:35:10) {
  code: 'ERR_INVALID_URL',
  input: 'http://localhost:undefined/health'
}

Node.js v20.15.1

@jannis-baum
Copy link
Owner

Nice, thanks for the help! I think I fixed it in #158. Since you have already figured out how to compile yourself, would you mind checking if it works on that branch?

@rhatos
Copy link
Author

rhatos commented Aug 5, 2024

No luck unfortunately - same error in vivify-server as before.

But just to double check that I did everything (never checked out an issue before).

I went gh pr checkout 158, removed the old binaries, ./configure <dir> and then make install.

Then ran the server and the normal binary. Which results in the error from earlier.

I did check to make sure the file you changed did change on my side too - which it did.

@jannis-baum
Copy link
Owner

Okay, what you describe sounds good, but just to make sure: When running viv --version you should get

vivify-server v0.3.0-4-g4b09a65

Then ensure you don't still have an instance of the old version of Vivify running, e.g. with

killall vivify-server

Then use viv to open something. Does it work like that?

@rhatos
Copy link
Author

rhatos commented Aug 5, 2024

It appears even calling viv --version is causing it to hang.

and killall vivify-server turned up with no processes running.

@sollymay
Copy link

sollymay commented Aug 5, 2024

I am getting an error when starting vivify-server as well, sorry I'm sending a picture instead of screenshot but work computer won't allow me to log into GitHub 😂.

image

Seems like something might be going on with port being undefined after latest update?

@jannis-baum
Copy link
Owner

Yes, the issue happens when there is no custom config. Could you check if #158 fixes this for you @sollymay?

@jannis-baum
Copy link
Owner

@rhatos could it be that you still have the AUR version installed somewhere and that it is in front of your own build on PATH? Could you try starting vivify-server with the full path that you configured before make install and/or deleting the AUR version? You could also try running which vivify-server to see which one is being started by default.

@sollymay
Copy link

sollymay commented Aug 5, 2024

Yes, the issue happens when there is no custom config. Could you check if #158 fixes this for you @sollymay?

I tried building and testing but seems when I try to run the built vivify-server I'm getting a kill from zsh.

I also tried just running vivify-server --version and same result

@tuurep
Copy link
Collaborator

tuurep commented Aug 5, 2024

I could reproduce viv hanging after deleting my config.json on current main, but #158 fixes it for me

@jannis-baum
Copy link
Owner

I could reproduce viv hanging after deleting my config.json on current main, but #158 fixes it for me

@tuurep Thanks! This is the same that I have as well.

I tried building and testing but seems when I try to run the built vivify-server I'm getting a kill from zsh.

@sollymay Interesting... So here you ran vivify-server at the absolute path you installed it to and then you get no output at all but just zsh telling you it was killed?

@sollymay
Copy link

sollymay commented Aug 5, 2024

@sollymay Interesting... So here you ran vivify-server at the absolute path you installed it to and then you get no output at all but just zsh telling you it was killed?

Yep, exactly. I uninstalled my brew installed version to avoid any problems with paths, executables, etc and built it without any errors popping. I see the two executables and they have the right permissions but for some reason vivify-server just runs and gets killed and viv gets stuck. May be related to my work setup so can't confirm it is until I get home.

@jannis-baum
Copy link
Owner

Okay, thanks for the information & the testing! I am considering just merging & releasing to get around potential setup-related problems since the PR fixes it for @tuurep and me. Will do that tomorrow unless something else pops up over night :)

@rhatos
Copy link
Author

rhatos commented Aug 6, 2024

@rhatos could it be that you still have the AUR version installed somewhere and that it is in front of your own build on PATH? Could you try starting vivify-server with the full path that you configured before make install and/or deleting the AUR version? You could also try running which vivify-server to see which one is being started by default.

You were right, had the AUR version still installed. Removed it and ran which vivify-server to confirm it was gone.

Interestingly, the compiled version when running ./vivify-server I get a segmentation fault.

           PID: 3420 (vivify-server)
           UID: 1000 (rhatos)
           GID: 1000 (rhatos)
        Signal: 11 (SEGV)
     Timestamp: Tue 2024-08-06 05:50:00 SAST (4min 23s ago)
  Command Line: ./vivify-server
    Executable: /home/rhatos/.local/bin/viv/vivify-server
 Control Group: /user.slice/user-1000.slice/[email protected]/kitty-3132-0.scope
          Unit: [email protected]
     User Unit: kitty-3132-0.scope
         Slice: user-1000.slice
     Owner UID: 1000 (rhatos)
       Boot ID: eb2cf3d0fa8f4530be7fb40ba6415256
    Machine ID: c9129491ae1040b4a4ca9565c4a517f7
      Hostname: nerv
       Storage: /var/lib/systemd/coredump/core.vivify-server.1000.eb2cf3d0fa8f4530be7fb40ba6415256.3420.1722916200000000.zst (present)
  Size on Disk: 286.7K
       Message: Process 3420 (vivify-server) of user 1000 dumped core.
                
                Module /home/rhatos/.local/bin/viv/vivify-server without build-id.
                Module /home/rhatos/.local/bin/viv/vivify-server
                Stack trace of thread 3420:
                #0  0x00007334e736e867 n/a (/usr/lib/ld-linux-x86-64.so.2 + 0xd867)
                #1  0x00007334e7381071 n/a (/usr/lib/ld-linux-x86-64.so.2 + 0x20071)
                #2  0x00007334e737d786 n/a (/usr/lib/ld-linux-x86-64.so.2 + 0x1c786)
                #3  0x00007334e737f0de n/a (/usr/lib/ld-linux-x86-64.so.2 + 0x1e0de)
                #4  0x00007334e737ddc8 n/a (/usr/lib/ld-linux-x86-64.so.2 + 0x1cdc8)
                ELF object binary architecture: AMD x86-64

And the --version parameter still hangs on ./viv

@rhatos
Copy link
Author

rhatos commented Aug 6, 2024

Just for sanity sake, I tested on my other machine and I get the same results.

Also running arch.

@sollymay
Copy link

sollymay commented Aug 6, 2024

Sorry for the late response here, but I was able to test at home and I am also getting a segfault running on Arch.

Seems like the same behavior I was getting on my work laptop but that would not print the segfault completely, but just quit instead of throwing the sefault line

@jannis-baum
Copy link
Owner

Thanks for testing guys! I just made a new release, let me know if this fixes it for you. You can

  • remove all installed versions of Vivify you have,
  • download the new executables from the release page,
  • put them into your install locations, and
  • test from there.

If things work our, we will update the packages (@tuurep for AUR, me for Brew).


The segfaults you get are probably related to the Node versions that were used for compilation; we haven't had this exact behavior1 but we have found that Node from package managers on Linux tends to not work, while the nvm versions do.

I don't want to bother you guys more with this, but just in case you are interested in building and/or contributing more to Vivify anyways, maybe you could let us know where your Node comes from (the one at command -v node in case you already have multiple versions) and/or try with an nvm-installed version :) This way we could also update the contribution guide to include this exact error.

Footnotes

  1. Have we? @tuurep

@tuurep
Copy link
Collaborator

tuurep commented Aug 6, 2024

To me it sounds like the same thing, but our build instruction isn't clear/explicit enough since the segfault error is currently the norm rather than the exception 😄

I've also updated the AUR packages to 0.3.1 now

@tuurep
Copy link
Collaborator

tuurep commented Aug 6, 2024

To be very clear, the way I build on Arch right now is:

nvm install node
yarn install
./configure ~/.local/bin
make install

nvm can be installed from the AUR


The reason for this shenanigans is because Node SEA is currently alpha/experimental and we are early adopting it, things will possibly get easier in the future :)

@jannis-baum
Copy link
Owner

Thanks @tuurep!

I'll close this for now, if it still doesn't work we can reopen later.

@rhatos
Copy link
Author

rhatos commented Aug 6, 2024

Sorry to bump this, but thought I'd just let you know it is working now installed from the AUR!

Thanks for the quick updates!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type:bug Something isn't working
Projects
None yet
Development

No branches or pull requests

4 participants