Release: 2.0.2.20 (Canary) 2018-02-27

Releases
21

So is uninstall - reinstall the only way to get a clean process manager in this? :wink:
Why is the reason for this if i may ask?
And are these things chaining up) i mean, if i did some updates do i have as many processes as i did updates?

22

No quite, because it also does the same even if the base version is the latest. In that case it just launches itself again. You need to set the environment variable AUTOUPDATER_DUPLICATI_SKIP_UPDATE=1 to disable the auto-update system.

A bit off topic, but no they do not chain.

The reason for this setup is that the main process stays alive. Then after an update is applied, the spawned process quits with a special signal that causes the main process to start the latest (aka the updated) version. This allows the process to ā€œre-startā€ without actually restarting the parent process.

We tried to use an in-process updater system previously (based on isolation with app-domains) but a number of users reported that it did not work cleanly in their setups. You can revert to this by setting the environment variable AUTOUPDATER_USE_APPDOMAIN=1.

23

Thank you very much.
It helps to understand why things are as they are :slight_smile:

24

It is always tricky to merge in changes after, because they need testing, but I have made a list of potential commits that we merge into the experimental:

25

That should be manageable :slight_smile:

The really tricky part is that those are all completely new changes that were submitted after this post. The scope of the experimental release keeps expanding :sweat_smile:

26

Yesā€¦ that is exactly why I am so poor at getting new experimental/beta releases out. There are so many great fixes I want to get in thereā€¦ but then they need testing ā€¦ and then we start over :slight_smile:

1 Like
27

FYI itā€™s been 3 days, have done full restarts with full restarts of Chrome along with a forced cache clear, and the live log conditions still appear as in my previous screenshot (i.e. long log lines overlapping on top of the log lines below them). Iā€™m becoming kinda skeptical that this particular issue actually got fixed in the update, unless Iā€™ve really missed something.

28

I donā€™t know what I was doing the other day to somehow see that it was workingā€¦ Now I see the same as youā€¦ Maybe I mistakenly looked at the general page after refreshing the cache?

In either case I guess on 2nd look Iā€™m in the same boat as you with the live logs page not appearing to be fixed (with the css changes i added missing).

53
Screen Shot 2018-03-05 at 22.34.53.png1450Ɨ1034 314 KB

Specifically I removed the css entry:

.logpage .entries.livedata li {
    height: 1.2em;
}

Itā€™s whatā€™s causing the overlap since itā€™s forcing long lines to only take up 1.2em instead of their full height.

This was merged 16 days ago in Live log height by Pectojin Ā· Pull Request #3033 Ā· duplicati/duplicati Ā· GitHub

1 Like
30

I did a rebuild of the css after the canary build, and I will try to get a new canary out today to see if this is fixed.

1 Like
31

Ok, so no bad things reported for the canary. I will try to get the experimental out tomorrow, fixes are merged into the experimental branch and ready to go.

1 Like
32

It seems itā€™s been pretty stable with no surprises.

So the experimental is based on 2.0.2.20 with 8 commits cherry picked.

The commits look pretty sane and should not be introducing any new issues, so Iā€™d say ship it :smiley:

2 Likes
33

Ok, building the experimental ā€¦