rickyrockrat / parcellite

GNU General Public License v3.0
220 stars 29 forks source link

Add systemd service file to the instalation #71

Closed felagund closed 1 year ago

felagund commented 2 years ago

I am using systemd to automatically start Parcellite, it would be good if a service file were included in the default install.

I use this one:

[Unit]
Description=Parcellite clipboard manager

[Service]
ExecStart=parcellite -n
Restart=on-failure
RestartSec=1

[Install]
WantedBy=graphical.target

in /etc/systemd/system and then enabling it like "systemctl --user enable --now parcellite". That should probly then go to the readme and manual page.

I guess the default service file should probably not have the -n switch. However, I am not sure if in its current state, parcellite is dealing with autostart in any way or if it is left to the user.

rickyrockrat commented 2 years ago

I don't run systemd unless it's forced on me. I wasn't aware that systemd started user services unless it was in the user's directory, and of course parcellite should never be run as root. I either use an xinit to auto start or use a session manager to restore it like XFCE4 has. I would guess your window manager has a similar option. I will check into this but it's not a high priority right now.

felagund commented 2 years ago

I actually quite like systemd, it is to me way easier to use, but I never learnt to understand other init systems. That is personal taste:-).

What actually happens is that by placing the service file into /etc/systemd/system, systemd than can enable autostarting parcellite easily. Running --user enable actually copies the service file to the user directory. Running that command is of course vastly easier than writing a service file from scratch, even if that is also somewhat easy.

It never gets run as root by systemd because it does not know what X display it could connect to (and probably a bunch of other needed variables).

In theory, this should also ensure that Parcellite gets restarted automatically if it ever crashes. I think I occasionaly do that manually, but I am not sure, it is quite rare. I actually have ~/.config/autostart/parcellite.desktop but for some reason it does not work, KDE is also moving to systemd so maybe this is a victim of it, creating a systemd file was easier than solving the issue at hand.

ernstki commented 1 year ago

I either use an xinit to auto start or use a session manager to restore it like XFCE4 has. I would guess your window manager has a similar option.

Agreed that it would be better to stick with whatever mechanism the desktop environment provides you for running programs on startup. In addition to whatever GUI option the DE has, you can put .desktop files in ~/.config/autostart (what the GUI is doing anyway), as well as the old-school .Xsession, .xinitrc, and so on.

My default expectation as a user is that a userspace program has to be run as the user. It's alarming enough that /etc/xdg/autostart/parcellite-startup.desktop gets installed by the Debian maintainers, and the default permissions are such that every user on a Debian system will have access to your history file by default. Please let's not add a systemd unit file on top of that, such that Parcellite is also resurrected if you try to kill it.

Edit: anyway, wouldn't supplying a systemd unit file be the responsibility of the packagers for your distro?

felagund commented 1 year ago

ernski, I think that is a misunderstanding - installing systemd service file does not mean that file is run or that systemd then starts managing parcellite. It still needs to be explicitly allowed. (of course, it could be packaged in a way that this would be the default, but I am not requesting that). Regarding the edit, I think it is quite common to supply systemd service with upstream software. The point of systemd is that it should kind of work across different distros.

rickyrockrat commented 1 year ago

There's no worries on that point. I don't think it's Parcellite's job to auto-launch, any more than I think thunderbird or firefox should. And it's Linux, why are you starting more than every 10 years anyway? :) As to a systemd file, it is just one more non-clipboard function I would have to maintain...and if I'm doing it for that, I may as well do it for sysv, runit, xxx. No thank you. And shame on Debian for adding an autostart. :) I run Alpine as a desktop with Xfcd4-session and I have to say I absolutely love it, but it's not for the faint of heart. there are a couple things I have to run in a chroot, but by and large, Alpine has been extremely stable and functional.

felagund commented 1 year ago

Well, I am bombarded by new kernels quite often, if anything else:-).

You are the maintainer so you get to decide of course:-). I would though argue that it is common practice to include systemd unit files upstream (see for example here: https://fedoraproject.org/wiki/Packaging:Systemd#Unit_Files). It saves a quite some work for the various distributions (most of which do use systemd). And to me, parcellite is something that makes a lot of sense to autostart. But I understand it is annoying to maintain it if yo udo not run system yourself.

rickyrockrat commented 1 year ago

A good session managing X window manager should handle all the user specific starts. I have a few of them, but none of them are started by the system scripts, for example pulse audio, orage, blueman. IMO, systemd, like any other init system should start system level executables, NOT user applications. It is a UNIX philosophy - do ONE thing and do it well. I realize systemd is a major departure from that, but I still agree with the UNIX philosophy. Failing that, there are plenty of other auto-start options.