Arch Linux

Not sure if basic.target is possibly and/or desired. Are you fine with sysinit.target?

Sure. Any targets before network would be great.

Currently we install with WantedBy=multi-user.target, but we order with Before=sysinit.target - so this should be as requested already.
Do you have any cases where you see issue with the current version?

I will test with WantedBy=sysinit.target and push changes when everything works as expected.

Aug 23 18:19:02 localhost ss-server[244]: 2018-08-23 18:19:02 INFO: using tcp fast open
Aug 23 18:19:02 localhost ss-server[244]: 2018-08-23 18:19:02 INFO: plugin "obfs-server" enabled
Aug 23 18:19:02 localhost ss-server[244]: 2018-08-23 18:19:02 INFO: UDP relay enabled
Aug 23 18:19:02 localhost ss-server[244]: 2018-08-23 18:19:02 INFO: enable TCP no-delay
Aug 23 18:19:02 localhost ss-server[244]: 2018-08-23 18:19:02 INFO: initializing ciphers... chacha20-ietf-poly1305
Aug 23 18:19:02 localhost ss-server[244]: 2018-08-23 18:19:02 INFO: This system doesn't provide enough entropy to quickly generate high-quality random numbers.
Aug 23 18:19:02 localhost ss-server[244]: Installing the rng-utils/rng-tools, jitterentropy or haveged packages may help.
Aug 23 18:19:02 localhost ss-server[244]: On virtualized Linux environments, also consider using virtio-rng.
Aug 23 18:19:02 localhost ss-server[244]: The service will not start until enough entropy has been collected.

Here is the .service file:
https://git.archlinux.org/svntogit/community.git/tree/trunk/shadowsocks-libev-server@.service?h=packages/shadowsocks-libev

Why do we provide our own service file at all, instead of enabling systemd in the configure script to install this service file right here: https://github.com/jirka-h/haveged/blob/master/init.d/service.suse

(Note that this file already uses WantedBy=sysinit.target )

Because we add some extra security.

New package haveged 1.9.4-3 installs for sysinit.target. Please note you have to reenable the service!

So we should just start patching all our packages ever, in order to "add some extra security", instead of like submitting upstream requests or at least using a reasonable system like *.d/ dropin directories?

I guess I was mistaken in believing that Arch Linux was a KISS distro priding itself on "ships software as released by the original developers".

Well, that would certainly explain why upstreams so often don't bother to provide such things themselves.

RIP.

I guess we provide a systemd service since we switched to systemd. Upstream did not have one at that time.
Things evolved in parallel, and I did some work for our unit file lately.

I plan to submit it upstream, but want to finalize it before. I know our distribution principles pretty well and I am perfectly sure nobody (and upstream the least) is happy with "please commit upstream, it is work-in-progress, next change soon".

> or at least using a reasonable system like *.d/ dropin directories

IMHO the correct way to handle this is *not* to continually track upstream *and* your own improvements at the same time. It is to use upstream's file + the builtin method of enhancing a systemd unit to *add* onto upstream's file.

That would result in not having to e.g. duplicate the upstream functionality of using sysinit.target due to hard-masking their file with yours.

End of discussion as not related to the issue. If you want to escalate drop me a mail.