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

"--no-sandbox" incorrectly parsed as a file? #1056

Closed
2 tasks done
rpavlik opened this issue Jun 27, 2022 · 8 comments
Closed
2 tasks done

"--no-sandbox" incorrectly parsed as a file? #1056

rpavlik opened this issue Jun 27, 2022 · 8 comments
Assignees

Comments

@rpavlik
Copy link

rpavlik commented Jun 27, 2022

Preflight Checklist

  • I agree to follow the Code of Conduct that this project adheres to.
  • I have searched the issue tracker for a feature request that matches the one I want to file, without success.

Describe the bug
I'm trying to run drawio on CI, in a docker container. I have to add --no-sandbox to get it to almost start. However, it then dies with "Error: input file/directory not found". I suspect it's trying to treat --no-sandbox as another file to process, but am not 100% sure.

To Reproduce
Steps to reproduce the behavior:

  1. Install some way that gives you a drawio command
  2. Run drawio --export --format pdf --embed-diagram --output architecture.drawio.pdf architecture.drawio as a normal user, not in docker: it should work if you have an "architecture.drawio" file.
  3. Now run drawio --no-sandbox --export --format pdf --embed-diagram --output architecture.drawio.pdf architecture.drawio
  4. See error

Expected behavior
It should run, but without using the sandboxing features from electron

Screenshots
If applicable, add screenshots to help explain your problem.

draw.io version (In the Help->About menu of the draw.io editor):

  • draw.io version 19.0.3

Desktop (please complete the following information):

  • OS: Linux: Debian Bullseye AMD64

Additional context
If there's an alternate preferred way to script this, I'd be happy to hear it, especially since using the desktop deb requires an Xvfb fake X server, asound, etc: lots of things that the actual command-line usage shouldn't probably use, but which are getting pulled in by being part of a larger app.

@mgrzybek
Copy link

mgrzybek commented Aug 2, 2022

Hi,

Same behaviour using a Debian 11.3 container and Draw.io 19.0.3. Here are the logs:

$ drawio --border=0 --export --no-sandbox --output diagrams/schema.png --page-index=3 \
        diagrams/schema.drawio
[20489:0802/112631.689242:ERROR:node_bindings.cc(276)] Most NODE_OPTIONs are not supported in packaged apps. See documentation for more details.
[20489:0802/112632.026361:ERROR:ozone_platform_x11.cc(248)] Missing X server or $DISPLAY
[20489:0802/112632.026380:ERROR:env.cc(226)] The platform failed to initialize.  Exiting.
The futex facility returned an unexpected error code.
make: *** [Makefile:164: diagrams/schema.png] Aborted (core dumped)

@modelmat
Copy link

A solution for this is to have --no-sandbox as the last argument:

#249 (comment) (a previous issue which was closed, probably because it got slightly derailed)

As for the "preferred" way to script this, as far as I know the recommendation is either to use Xvfb or to use the web server to export it (as recommended #127 (comment))

graemefoster added a commit to graemefoster/AzureResourceMap that referenced this issue Jan 15, 2023
@stale stale bot added the wontfix label Dec 21, 2023
@rpavlik
Copy link
Author

rpavlik commented Dec 21, 2023

Still there in the latest release.

drawio --border=0 --export --no-sandbox --output test.png lifecycle-original-draw-io.svg

gives

Checking for beta autoupdate feature for deb/rpm distributions
Found package-type: deb
Error: input file/directory not found

@stale stale bot removed the wontfix label Dec 21, 2023
@jgraph jgraph deleted a comment from stale bot Dec 22, 2023
@m-mohamedin
Copy link
Contributor

Thanks for the report. It will be fixed in the next release.

@davidjgraph
Copy link
Contributor

In 24.5.3.

@kalvdans
Copy link

@davidjgraph do you have a reference to the individual commit that fixed the issue?

@davidjgraph
Copy link
Contributor

No, it wasn't made in a public repo.

@kalvdans
Copy link

Seems to be 32badd8 by @m-mohamedin

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants