xfce4-clipman requires access to your Xorg display (the X11 graphics system) – not just because it's indeed a graphical app, but also because it's a clipboard manager and X11 covers that as well.
The (main) problem: Your Xorg display isn't actually available at startup yet. It is launched on login, long after the system startup has finished. Therefore it's impossible to launch xfce4-clipman "on startup" – what you actually want is to launch the app on login as well.
(Linux is built to support multiple users, who can log in & log out at any time – each user gets a brand new copy of Xorg running, and the login screen itself gets one as well. So services cannot count on Xorg being available at all.)
Launching apps on login
Most desktop environments, including Xfce, can launch "login" tasks via
*.desktop files (which is indeed how various Xfce components are launched).
They are located in
/etc/xdg/autostart/ for global services, and
~/.config/autostart/ for personal ones. After you create one, it is "enabled" by default, although can still be disabled via
In fact, even xfce4-clipman installs its own autostart file to /etc/xdg/autostart – it is named
xfce4-clipman-plugin-autostart.desktop. It should work automatically as long as you're using Xfce4 (due to the
But if your system is missing that file, or if you want to use xfce4-clipman in a non-Xfce desktop environment, then you can create a new one. Autostart
.desktop files generally look like this:
Launching non-CLI programs manually
Many desktop environments have a "Run" dialog at AltF2, which lets you run programs without occupying a terminal.
Various methods of doing the same from a terminal are:
(setsid xfce4-clipman 2>/dev/null &)
nohup xfce4-clipman &
xfce4-clipman & disown
- and so on.
Other problems with your init.d script
In situations where system services are apropriate, you should remember that files in /etc/init.d are not just simple scripts they're also run on shutdown, and must accept subcommands such as "stop" or "restart". When the system calls
/etc/init.d/your_service stop, the initscript needs to actually stop the service – not start it again!
You've tagged the question with systemd, so why not save yourself a lot of trouble and write a native systemd
*.service file instead? While "proper" init.d scripts can fill several screens, systemd .services are often less than a dozen lines.
Even more importantly: There are many dozens of services starting up at various points in time. At later stages, some facilities are available that earlier stages do not have. (For example, networking.)
If your initscript does not explicitly state its ordering requirements ("must run before Y, but after Z"), the OS will run it at an unpredictable stage, in parallel with everything else. If you're very lucky, it will run at the right moment – but most of the time it will run too early for anything to work.
In native systemd unit files, ordering is specified using
After= parameters. (It's a good idea to specify dependencies using
Wants=, as well.) Meanwhile, init.d scripts (with both SysVinit and systemd) use a special comment block marked
### BEGIN INIT INFO, with parameters such as