Arch Linux User Repository

There are reports about this software dying after 15s again.
known workarounds:
• use another pdf-reader whereever possible
• use acroread windows version in wine (HowTo: https://appdb.winehq.org/objectManager.php?sClass=version&iId=27093&iTestingId=92286)
• remove /opt/Adobe/Reader9/Reader/intellinux/plug_ins/EFS.api (this might have unknown consequences regarding your data and software functionality, especially related to internet connectivity)
• comment out the ipv6 line (::1) in /etc/hosts (this might impair your ipv6 connectivity and functionality of locally communicating programs)

This package *is not* out-of-date, it serves outdated software.

The lib32-gtk2 dependency was missing for me. It seems to be missing in package() when depends is overwritten.

The crash issues got fixed for me with the last update. Thank you!

@dion_starfire: thank you, this fixes the crashes for me.
everyone please check, at least for 64bit this might be the solution.

Checking the dependencies of /opt/Adobe/Reader9/Reader/intellinux/plug_ins/EFS.api, I noticed that libcurl.so.3 was not found. On a hunch, I installed multilib/lib32-libcurl-compat, which provides a lib32 version of libcurl.so.3. Sure enough, acroread stopped crashing.

So, we may be able to fix the 15s crash issue by simply adding multilib/lib32-libcurl-compat as another dependency for the package.

For those who previously deleted/disabled EFS.api, I did have to nuke my ~/.adobe/Acrobat/ before I was able to get into the Preferences dialog again - it seemed to think that the dialog was open in another window, despite there being no other running instances of acroread.

My guess is that EFS.api tries to use libcurl if it's on the system, and if it can't find it falls back to an internal mechanism that doesn't understand IPv6, which is what causes the crash.

To enable multilingual support, you need to set PSRESOURCEPATH=/usr/lib/acroread variable.

@Xezlec

Thanks for the solution.

Not sure about any security holes but your program doesn't pass any args to acroread so doesn't support opening a file directly.

This fixes it (only for 1 file though, you could rewrite to pass multiple args but i didn't have a need)

echo $'#include <unistd.h>\n#include <stdio.h>\nint main(int argc, char *argv[]){char u[99];sprintf(u,"-u#%d",(int)getuid());return execl("/usr/bin/unshare","","-n","sudo",u,"ACRO_ALLOW_SUDO=1","/usr/bin/acroread.bin",argv[1],NULL);}\n'|gcc -x c - -o acroread

Is there still any multilingual support ?
Only english seems available.
Thanks

"sudo unshare -n sudo -u ${USER} ACRO_ALLOW_SUDO=1 acroread" is a better solution than deleting EFS.api, because EFS.api is needed to show the Preferences dialog if I want to change Acrobat Reader's settings.

For a permanent workaround (albeit one that still breaks Acrobat Reader's network features if you are the rare person who cares about that), try this simple five-command sequence:

$ echo $'#include <unistd.h>\n#include <stdio.h>\nint main(){char u[99];sprintf(u,"-u#%d",(int)getuid());return execl("/usr/bin/unshare","","-n","sudo",u,"ACRO_ALLOW_SUDO=1","/usr/bin/acroread.bin",NULL);}\n'|gcc -x c - -o acroread
$ sudo mv /usr/bin/acroread{,.bin}
$ sudo mv acroread /usr/bin
$ sudo chown root:root /usr/bin/acroread
$ sudo chmod 4755 /usr/bin/acroread

(EDIT: Does this present any security holes that anyone can think of though? How safe is unshare to run with setuid root?)

sudo unshare -n sudo -u ${USER} ACRO_ALLOW_SUDO=1 acroread

This seems to work for me, but it's awkward to first start it from command line in order to open a pdf e.g. from within a mail. Is there a way to make this permanent (for the time being)?
Because, the problem can't be solved with other workarounds on my PC, it seems.

Thanks,
Martin

Another workaround for the crash on reading /etc/hosts is to start acroread as follows:

sudo unshare -n sudo -u ${USER} ACRO_ALLOW_SUDO=1 acroread

This disables network access for the application, apparently that's enough to keep it from crashing.