jannis-baum / Vivify

Bring your Markdown to life
GNU General Public License v3.0
24 stars 3 forks source link

VIV_PORT environment variable not set automatically #157

Closed rhatos closed 1 month ago

rhatos commented 1 month ago

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.

jannis-baum commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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

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

sollymay commented 1 month ago

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 commented 1 month ago

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

jannis-baum commented 1 month ago

@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 commented 1 month ago

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 commented 1 month ago

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

jannis-baum commented 1 month ago

I could reproduce viv hanging after deleting my config.json on current main, but https://github.com/jannis-baum/Vivify/pull/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 commented 1 month ago

@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 commented 1 month ago

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 commented 1 month ago

@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/user@1000.service/kitty-3132-0.scope
          Unit: user@1000.service
     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 commented 1 month ago

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

Also running arch.

sollymay commented 1 month ago

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 commented 1 month ago

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

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[^1] 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.

[^1]: Have we? @tuurep

tuurep commented 1 month ago

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

I've also updated the AUR packages to 0.3.1 now

tuurep commented 1 month ago

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 commented 1 month ago

Thanks @tuurep!

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

rhatos commented 1 month ago

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!