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

PDF export hangs forever under Linux (Ubuntu 20.04) / multi user issue #5966

Open
3 tasks done
stm-at-esd opened this issue Jan 30, 2024 · 2 comments
Open
3 tasks done

Comments

@stm-at-esd
Copy link

  • Searched existing issues to avoid creating duplicates.

  • Confirmed that it can be reproduced in built-in themes without customized css.

    If it only exists in 3rd party themes or css, you can still report it, but please attach the theme target or the css file. We may not "fix" it, if it is caused by 3rd party themes or css styles that we cannot support.

  • Searched http://support.typora.io/


Describe the bug
On a multi user Linux installation the issue occurs when two users each try to export a document as pdf. The "first"
user's export will succeed. The "second" users PDF export will hang "forever".

To Reproduce
Steps to reproduce the behavior:

  1. Have a multi user Linux machine with Typora installed. Involve two users in the test named "first" and "second". Remove any "/tmp/Typora" directory recursively to get a clean slate.
  2. User "first" opens a document and uses "file -> export -> pdf". This works and during this operation a directory /tmp/Typora and a file /tmp/Typora/-..*.html get created both owned by user "first" and group "users". The directory gets the permissions 0755 and the file has permissions 0644 then. The user "first" may then exit Typora.
  3. User "second" opens a document and uses "file -> export -> pdf". This operation will hang with the message "Exportieren aktiv ..." (German UI) and will not return. Typora than only can be left with "file -> close".

Note: The error may be masked by a reboot of the machine because the /tmp/ directory may be cleaned during reboot.

Expected behavior
I would expect that on a multi user machine not only the first user that makes a PDF export will be able to do so.

The source of the problem is that the directory /tmp/Typora is created by the user currently running Typora (user "first") and having the restrictive permissions of 0755. This way the "second" user can't write its temporary html file to /tmp/Typora.

A possible (and tested) workaround is to change the permissions of the /tmp/Typora directory manually to 0777 after the "first" user has created this directory. This way the PDF export also works for the "second" user.

A possible way for Typora to get around this issue is to create a temporary directory for each user. A possible way to do this is to add the user id as part of the directory name like "/tmp/Typora.". In the case user "first" has uid 1000 and user "second" has uid 1001 then the directories "/tmp/Typora.1000" and "/tmp/Typora.1001" would be created and the issue can't happen.

Sample Markdown File
Any content will do.

Desktop (please complete the following information):

  • OS:
$ lsb_release -a
LSB Version:	core-11.1.0ubuntu2-noarch:security-11.1.0ubuntu2-noarch
Distributor ID:	Ubuntu
Description:	Ubuntu 20.04.6 LTS
Release:	20.04
Codename:	focal

Typora Version
At least all versions since 1.7.6. The version 0.11.18 doesn't have this issue because it does not create the intermediate directory /tmp/Typora but creates directly the file /tmp/*-?.*html.

Additional context
I assume that bug #5846 is similar / the same bug regarding the "freeze" part of that bug report.

@abnerlee
Copy link
Contributor

abnerlee commented Feb 6, 2024

Was this fixed in 1.8.9?

@stm-at-esd
Copy link
Author

The bug is still present in 1.8.9-1, which we already installed last week.

Retested today: When starting Typora the directory /tmp/Typora is immediately created for the calling user, if it is not present. But it has permissions 0755 which makes a Typora started from another user account hang on PDF export. The workaround and the recommendations for a solution are still valid.

Other tools create a per user temporary directory like this:

user@host:~$ ls -ldn /tmp/tracker-extract-files.*
drwx------ 2 147 3130 4096 2024-01-24 16:51:33 /tmp/tracker-extract-files.147
drwx------ 2 149 3130 4096 2024-02-01 14:43:34 /tmp/tracker-extract-files.149
drwx------ 2 2019 3012 4096 2024-02-01 14:43:34 /tmp/tracker-extract-files.2019
drwx------ 2 2035 100 4096 2024-02-01 14:43:34 /tmp/tracker-extract-files.2035
drwx------ 2 2041 100 4096 2024-02-01 14:43:35 /tmp/tracker-extract-files.2041
drwx------ 2 2044 100 4096 2024-02-06 15:37:39 /tmp/tracker-extract-files.2044

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

No branches or pull requests

2 participants