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

Hanging chromium processes #480

Closed
makarychev13 opened this issue Jul 25, 2022 · 3 comments
Closed

Hanging chromium processes #480

makarychev13 opened this issue Jul 25, 2022 · 3 comments
Labels
chromium documentation Documentation update request

Comments

@makarychev13
Copy link

Version
Gotenberg 7.5.3
go 1.18.3

Description of the problem
Child chromium processes keep running after pdf conversion. And these processes die only after restarting the application. This problem was "fixed" in this PR.

There is a similar open issue in chromedp.

Code example

package main

import (
	"bytes"
	"context"
	"io"
	"mime/multipart"
	"net/http"
	"os"
)

func main() {
	var buf bytes.Buffer

	//read html from disk
	html, err := os.ReadFile("index.html")
	if err != nil {
		panic(err)
	}

	//prepare http request
	w := multipart.NewWriter(&buf)

	fw, _ := w.CreateFormFile("files", "index.html")
	if _, err := io.Copy(fw, bytes.NewReader(html)); err != nil {
		panic(err)
	}

	if err = w.Close(); err != nil {
		panic(err)
	}

	req, err := http.NewRequestWithContext(context.Background(), http.MethodPost, "http://127.0.0.1:3000/forms/chromium/convert/html", &buf)
	if err != nil {
		panic(err)
	}
        req.Header.Set("Content-Type", w.FormDataContentType())

	resp, err := http.DefaultClient.Do(req)
	if err != nil {
		panic(err)
	}

	//save pdf to disk
	var pdf bytes.Buffer
	if _, err = io.Copy(&pdf, resp.Body); err != nil {
		panic(err)
	}

	if err := os.WriteFile("index.pdf", pdf.Bytes(), 0666); err != nil {
		panic(err)
	}
}

Effects
image

@gulien
Copy link
Collaborator

gulien commented Aug 1, 2022

Hello @makarychev13,

It was indeed resolved in versions 6.x.x, where I was handling the Chrome process myself. In versions 7.x.x, I let chromedp do the heavy lifting.

That being said, I have no idea why it happens in our case:

All Tini does is spawn a single child (Tini is meant to be run in a container), and wait for it to exit all the while reaping zombies and performing signal forwarding.

Also, on the demo instance, there is 0 zombie process 🤔 (it has been up for 124 consecutive days)

@gulien gulien added bug Something isn't working chromium maybe labels Aug 1, 2022
@ismurov
Copy link

ismurov commented Aug 30, 2022

Hi, @gulien. 👋

We found the problem. We just redefine ENTRYPOINT of Docker container while using in K8S by command property instead using arguments. And Tini was not used in our pods. Ha-Ha!

We apologize for the trouble.

@gulien
Copy link
Collaborator

gulien commented Aug 31, 2022

Hello @ismurov,

Thanks for the heads up! I'll update the documentation so that one could avoid this mistake 😄

@gulien gulien added documentation Documentation update request and removed bug Something isn't working maybe labels Aug 31, 2022
@gulien gulien closed this as completed Aug 31, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
chromium documentation Documentation update request
Projects
None yet
Development

No branches or pull requests

3 participants