VIV_PORT environment variable not set automatically about vivify HOT 22 CLOSED

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!

from vivify.

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.

from vivify.

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

from vivify.

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?

from vivify.

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.

from vivify.

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?

from vivify.

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

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

from vivify.

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 😂.

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

from vivify.

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

from vivify.

@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.

from vivify.

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

from vivify.

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

from vivify.

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?

from vivify.

@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.

from vivify.

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 :)

from vivify.

@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

from vivify.

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

Also running arch.

from vivify.

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

from vivify.

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 behavior¹ 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.

from vivify.

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

from vivify.

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 :)

from vivify.

Thanks @tuurep!

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

from vivify.