[SOLVED]Systemd autostart conky

DarkLite1 · 2014-05-16 16:54:50

Hi guys, as a new Arch user I tried to play a bit with systemd to have it automatically start Conky after logon. When I try to start conky manually from the terminal it all works perfectly but when systemd needs to do it as a unit (service) it's not possible as Conky doesn't accept the rc file it's been given. It seems that the variable $HOME or %h is unknown to systemd. Below some details

Starting my 2 Conky files from the Gnome terminal is no problem:

conky -d -c $HOME/.Conky/ConkyToprc
conky -d -c $HOME/.Conky/ConkyLogrc

cat /etc/systemd/system/conky.service:

[Unit]
Description=Conky system monitor
Documentation=man:conky(1)

[Service]
Type=forking
ExecStart=/usr/bin/conky -d -c /home/viper/.Conky/ConkyToprc

[Install]
WantedBy=xinitrc.target

[root@Arch viper]# systemctl status conky.service
● conky.service - Conky system monitor
   Loaded: loaded (/etc/systemd/system/conky.service; disabled)
   Active: failed (Result: core-dump) since Fri 2014-05-16 18:39:51 CEST; 10min ago
     Docs: man:conky(1)
  Process: 4833 ExecStart=/usr/bin/conky -d -c /home/viper/.Conky/ConkyToprc (code=dumped, signal=ABRT)

May 16 18:39:51 Arch conky[4833]: Conky: $HOME environment variable doesn't exist
May 16 18:39:51 Arch conky[4833]: conky: malloc.c:2369: sysmalloc: Assertion `(old_top == (((mbinptr) (((char *) &((av)->bins[((1) - 1) * 2])) - __builtin_offsetof (struct malloc_chunk, fd)))) && old_size == ...
May 16 18:39:51 Arch systemd-coredump[4834]: Process 4833 (conky) dumped core.
May 16 18:39:51 Arch systemd[1]: conky.service: control process exited, code=dumped status=6
May 16 18:39:51 Arch systemd[1]: Failed to start Conky system monitor.
May 16 18:39:51 Arch systemd[1]: Unit conky.service entered failed state.
Hint: Some lines were ellipsized, use -l to show in full.

So even after changing the systemd unit file to use the full path /home/viper/.Conky/ConkyToprc it's still not working. I think after changing $HOME or %h Conky did accept the config file but doesn't recognize the $HOME variable in the config file anymore. Or maybe I'm missing something here... And I'm not even trying to load the second conky file Anyone an idea as where I need to look? Any help is highly appreciated. Thank you in advance.

It seems to be a bit related to this: http://lists.freedesktop.org/archives/s … 06217.html

Last edited by DarkLite1 (2014-05-17 16:48:04)

6ng4n · 2014-05-16 17:07:32

Why don't you try your DE's autostart settings? Both KDE and GNOME has autostart function, all you needed write a simple script and put it ~/.config/autostart

DarkLite1 · 2014-05-16 17:11:31

Thank you for your help, I did what you said already and it works like a charm. However, I wanted to go the systemd way to learn how it works.. Fyi, this is my working .desktop file to launch only one of both conky scripts. If I wanted to launch 2 at the same time I have to modify it probably a bit, but I'd rather go the systemd way, no?

[viper@Arch ~]$ cat /usr/share/gnome/autostart/conky.desktop
[Desktop Entry]
Type=Application
Name=Conky
Comment=Start conky script
Exec=conky -d
OnlyShowIn=GNOME;
X-GNOME-Autostart-Phase=Application

Last edited by DarkLite1 (2014-05-17 16:19:06)

ANOKNUSA · 2014-05-16 18:31:44

You're trying to learn how to use something properly by using it improperly. systemd is intended to run system services and daemons; conky is not a system service or daemon. Starting it with systemd won't really teach you anything, because a) you'll basically be using systemd in a way that wasn't intended, to run an application in a way that wasn't intended; and b) you'll need to add a bunch of extra conditions to get it to work properly. Take this line from your error output:

May 16 18:39:51 Arch conky[4833]: Conky: $HOME environment variable doesn't exist

systemd is trying to start conky using a configuration file from your home directory, but since it runs all services at boot time simultaneously it's trying to start conky before you've logged in, so $HOME has no meaning. It doesn't exist yet. If you replace "$HOME" in the unit file with the full path of the configuration (which you did) it would again fail, because you don't have an X server display yet. If you tell it to wait until you've had a chance to log in and start X, you'll then need to fiddle with it to get the timing right, assuming nothing changes between boot-ups to affect boot time.

Or you could just add "conky -d -c /home/viper/.Conky/ConkyToprc" to your .xinitrc file, as was intended, and it would start just fine. If you want to learn systemd services by tinkering with unit files, find a situation in which a unit file is actually necessary and changing it is useful.

tomk · 2014-05-16 19:17:56

In $RANDOM days/weeks/months, systemd/user will become usable, at which point you can revisit this thread.

For now, do as recommended above.

twelveeighty · 2014-05-16 19:47:45

I would never recommend this, since systemd is already doing so much more than what (in my opinion) it should stick to, but this Wiki suggests that systemd can run in the "context" of a non-root user: https://wiki.archlinux.org/index.php/Sy … ur_Session. I don't know if systemd --user understands $HOME but I doubt if it can interact with the Gnome desktop of the same user that "happens" to be logged in. The way I read it is that systemd --user runs outside of the actual user session, so you would have to marshal information from the "systemd conky" session to the logged-in user session. I would stick to autostart, which is all contained within the logged-in user session itself.

DarkLite1 · 2014-05-17 07:58:54

Thank you everyone for your feedback, I really appreciate it Some things I would still like to clarify although I fully agree with your reasoning of not using systemd for my 'conky' idea here.

@ANOKNUSA: Yes you are right, systemd starts everything simultaneously at boot time. The way I did my test was to start the unit manually from the Gnome terminal after already being logged on to Gnome. So in my point of view the $HOME variable did already exist at that point and there was no need to wait for the X server... So in theory, it should've been able to get the job done.

@twelveeighty: So yes, I do believe you are right. systemd doesn't know $HOME at all.

Than my final question to have this solved for me. What is the best way to have 2 instances of Conky running with each it's own config file? I tried the following already, but it was unsuccessful:

cat /etc/profile.d/autostart.sh 
Exec=/usr/sbin/conky -d -c /home/viper/.Conky/ConkyToprc
Exec=/usr/sbin/conky -d -c /home/viper/.Conky/ConkyLogrc

 cat /usr/share/gnome/autostart/conky.desktop
[Desktop Entry]
Type=Application
Name=Conky
Comment=Start conky script
Exec=/usr/sbin/conky -d -c /home/viper/.Conky/ConkyToprc
Exec=/usr/sbin/conky -d -c /home/viper/.Conky/ConkyLogrc
OnlyShowIn=GNOME;
X-GNOME-Autostart-Phase=Application

When trying to follow the proposed solution found here https://wiki.archlinux.org/index.php/xinitrc there is no example file availble for .xinitrc in /etc/skel as suggested 'Copy the sample /etc/skel/.xinitrc file to your home directory' And if there was, how would the syntax be for 2 instances of Conky? Because when I read the Note it's not possible to add 2 lines of EXEC:

Note: Make sure to uncomment only one exec line, since that will be the last command run from the script; all the following lines will just be ignored. Do NOT attempt to background your WM by appending a `&` to the line.

/again: thanks for still helping me out and reading my jibber/jabber. I sometimes really feel like a noob here between all you pro's. But the only way of getting there is by falling and learning how to get up? Right Bruce?

Last edited by DarkLite1 (2014-05-17 16:18:43)

ooo · 2014-05-17 08:31:38

you simply have to create two separate .desktop files for each conky instance in the autostart directory, for example conky-top.desktop and conky-log.desktop, each launching conky with desired config.

also, you can put these files ~/.config/autostart/ or ~/.local/share/gnome/autostart/ to enable them for your user only and not system wide.

it's also possible to achieve this using .xinitrc, but it may not be the simplest solution unless you use xinit for starting X and already know how the file works

btw, you really should use

[code] <- code tags -> [/code]

when posting configs. It makes your post much easier to read

Last edited by ooo (2014-05-17 08:32:06)

DarkLite1 · 2014-05-17 16:46:15

Thank you OOO, I really appreciate your help. I've updated my posts with your example to be in line with the Arch expectations. And indeed, it's much more readable

On top of that I also solved my problem with following your suggestion. At first there was no ~/.config/autostart directory, but after trying out the Gnome-Tweak-Tool it got created automatically. After which I decided to use it as you suggested.

The best solution in the end was 2 separate .desktop files:

[viper@Arch ~]$ cat ~/.config/autostart/Conkylog.desktop 
[Desktop Entry]
Type=Application
Name=Conky
Comment=Start conky script
Exec=/usr/sbin/conky -d -c /home/viper/.Conky/ConkyLogrc
OnlyShowIn=GNOME;
X-GNOME-Autostart-Phase=Application

[viper@Arch ~]$ cat ~/.config/autostart/Conkytop.desktop 
[Desktop Entry]
Type=Application
Name=Conky
Comment=Start conky script
Exec=/usr/sbin/conky -d -c /home/viper/.Conky/ConkyToprc
OnlyShowIn=GNOME;
X-GNOME-Autostart-Phase=Application

Once again, thank you for helping this noob out I will try to update the title with [SOLVED].

Last edited by DarkLite1 (2014-05-17 16:47:39)

Arch Linux

#1 2014-05-16 16:54:50

[SOLVED]Systemd autostart conky

#2 2014-05-16 17:07:32

Re: [SOLVED]Systemd autostart conky

#3 2014-05-16 17:11:31

Re: [SOLVED]Systemd autostart conky

#4 2014-05-16 18:31:44

Re: [SOLVED]Systemd autostart conky

#5 2014-05-16 19:17:56

Re: [SOLVED]Systemd autostart conky

#6 2014-05-16 19:47:45

Re: [SOLVED]Systemd autostart conky

#7 2014-05-17 07:58:54

Re: [SOLVED]Systemd autostart conky

#8 2014-05-17 08:31:38

Re: [SOLVED]Systemd autostart conky

#9 2014-05-17 16:46:15

Re: [SOLVED]Systemd autostart conky

Board footer