Sorry for the delay, I wanted to make sure my answer is accurate.
I have three machines set up with 17.10 afresh. mbpr13a 8GB, 4.13.0-25-generic mbpr15a 16GB, 4.13.0-25-generic mbpr13b 16GB, 4.13.0-32-generic
mbpr15a does backups ooB mbpr13a/b have the reported issue
The original line in /etc/xdg/autostart/org.gnome.DejaDup.Monitor.desktop
Exec=sh -c "ulimit -v 1000000; exec /usr/lib/x86_64-linux-gnu/deja-dup/deja-dup-monitor"
leads to the issue
Setting ulimit -n or ulimit -s additionally does not remedy the error
This line worked
Exec=sh -c "ulimit -s 16384; ulimit -n 4096; exec /usr/lib/x86_64-linux-gnu/deja-dup/deja-dup-monitor"
@Vaclav #35: I always test after reboot and consequently after suspend to RAM. The solution works under those conditions.
What irritates my: mbpr15a works with the original line. ???
Sorry for the delay, I wanted to make sure my answer is accurate.
I have three machines set up with 17.10 afresh.
mbpr13a 8GB, 4.13.0-25-generic
mbpr15a 16GB, 4.13.0-25-generic
mbpr13b 16GB, 4.13.0-32-generic
mbpr15a does backups ooB
mbpr13a/b have the reported issue
The original line in /etc/xdg/ autostart/ org.gnome. DejaDup. Monitor. desktop
Exec=sh -c "ulimit -v 1000000; exec /usr/lib/ x86_64- linux-gnu/ deja-dup/ deja-dup- monitor"
leads to the issue
Setting ulimit -n or ulimit -s additionally does not remedy the error
This line worked
Exec=sh -c "ulimit -s 16384; ulimit -n 4096; exec /usr/lib/ x86_64- linux-gnu/ deja-dup/ deja-dup- monitor"
@Vaclav #35: I always test after reboot and consequently after suspend to RAM.
The solution works under those conditions.
What irritates my: mbpr15a works with the original line. ???