Arch Linux User Repository

Thanks for the help https://calendrier2019.info/

ziggi, yes, of course.

vp1981, can I add your service file to the package?

For those who uses several Yandex accounts and wants to use 'yandex-disk' may use following service file:

[Unit]
Description=Yandex-Disk service for %i
After=local-fs.target network.target
ConditionPathExists=%h/.config/yandex-disk/%i.cfg

[Service]
Type=forking
ExecStart=/usr/bin/yandex-disk start -c %h/.config/yandex-disk/%i.cfg
ExecStop=/usr/bin/yandex-disk stop -c %h/.config/yandex-disk/%i.cfg

[Install]
WantedBy=default.target

(link to the service https://bitbucket.org/vp1981/pkgbuild/src/7090062b17dd082adb205c6a8a33569199ff520c/yandex-disk/yandex-disk@.service?at=master&fileviewer=file-view-default).

To use the service one has to setup configuration for every Yandex account, give them appropriate names, change settings in configuration as well. Then enable service as

systemctl --user enable yandex-disk@ACCOUNT.service
systemctl --user start yandex-disk@ACCOUNT.service

> In the systemd service file I've found the following line:
> ExecReload=/usr/bin/killall -qw yandex-disk
>
> I really appreciate your work and I beg your pardon, ziggi, but are
> you kidding me? :) Why bother implementing a "reload" command if it
> merely kills ALL the processes that have "yandex-disk" in their names?
>
> There is a wonderful systemctl command named 'reload-or-restart' that
> restarts a service if it doesn't have the "reload" command
> implemented, so what you have done is certainly a misuse of the
> ExecReload parameter. If you can prove me wrong please let me know.

I kill the process and him will be started automatically soon.

> Also in the docs they mention that the daemon has to be stopped with
> the command "yandex-disk stop": https://yandex.com/support/disk/cli-
> clients.html#cli-daemon__cli-commands . There is the "ExecStop"
> parameter (man 5 systemd.service) which one can utilize to achieve the
> desired behaviour. Well I guess nothing bad will happen if the daemon
> is stopped with the SIGTERM signal, but nevertheless.

"yandex-disk stop" doesn't kill the systemd daemon.

> And I can't keep myself from mentioning the "RestartSec" parameter
> which is set to 60. Do you have any special reason to override the
> default systemd behaviour? I mean, is anything bad going to happen if
> it is restarted with, let's say, a second timeout?

Yes, without some delay daemon won't start. And I don't know exactly how much him need.

> The last but not the least. You have that weird shell script that
> apparently parses the configuration file and appends the parsed values
> to the yandex-disk command line. Well, to begin with, it happily
> parses all the commented lines producing stuff like `--#proxy=socks4`.
> And why did you even bother with that? The daemon reads that file by
> default (unless you specify the "-c"/"--config" option).

Because "-c" option is not supported with "--no-daemon" mode. But I found the way how it can be fixed.

P.S. This service works good but if you want to suggest any changes - just show me your service configuration file. Because any program has specific behavior and any decision has specific causes. Anyway, thanks for reporting.

Hi ziggi!

In the systemd service file I've found the following line:
ExecReload=/usr/bin/killall -qw yandex-disk

I really appreciate your work and I beg your pardon, ziggi, but are you kidding me? :) Why bother implementing a "reload" command if it merely kills ALL the processes that have "yandex-disk" in their names?

There is a wonderful systemctl command named 'reload-or-restart' that restarts a service if it doesn't have the "reload" command implemented, so what you have done is certainly a misuse of the ExecReload parameter. If you can prove me wrong please let me know.

Also in the docs they mention that the daemon has to be stopped with the command "yandex-disk stop": https://yandex.com/support/disk/cli-clients.html#cli-daemon__cli-commands . There is the "ExecStop" parameter (man 5 systemd.service) which one can utilize to achieve the desired behaviour. Well I guess nothing bad will happen if the daemon is stopped with the SIGTERM signal, but nevertheless.

And I can't keep myself from mentioning the "RestartSec" parameter which is set to 60. Do you have any special reason to override the default systemd behaviour? I mean, is anything bad going to happen if it is restarted with, let's say, a second timeout?

The last but not the least. You have that weird shell script that apparently parses the configuration file and appends the parsed values to the yandex-disk command line. Well, to begin with, it happily parses all the commented lines producing stuff like `--#proxy=socks4`. And why did you even bother with that? The daemon reads that file by default (unless you specify the "-c"/"--config" option).

Thanks for your attention.

ziggi, I just checked sha512sum of yandex-disk.install. And it`s correct. Probably something wrong with my system.

mamantoha, everything works, I have tested it.

Can't install the latest version:

==> Validating source files with sha512sums...
yandex-disk_0.1.5.948_amd64.deb ... Passed
yandex-disk.install ... FAILED
yandex-disk.service ... Passed
==> ERROR: One or more files did not pass the validity check!
==> ERROR: Makepkg was unable to build yandex-disk.
==> Restart building yandex-disk ? [y/N]
==> ------------------------------------

kfr2359, thank you for this information. I will wait for new kernel in stable repo. So I hope this update will solve this issue on my system too.