I have enabled service like sxhkd, picom, dunst, flameshot, betterlockscreen, mpd and keyring. Now it should build a the config and systemd-service, right?! it does build the config for dunst, sxhkd and picom but doesn’t create the systemd service to start with the system. and services like flameshot or keyring; it doesn’t take effect at all…
Hope someone to have any idea, my config to check it out
By “create” do you mean start or “create” as in creating the service files? They should be located in ~/.config/systemd/user/<service>.
Can you systemctl status --user dunst.service for example?
If they are actually there, just not starting, are you on NixOS or another distro? You might need to get your distro to start your user services, and the configuration for that might differ a bit distro-to-distro.
Well, it appeared they get created in ~/.config/systemd/user/ as you said. But yet they are not active, and I am not able to make them active.
mahmoud in ~
⨟ systemctl status --user dunst.service
○ dunst.service - Dunst notification daemon
Loaded: loaded (/home/mahmoud/.config/systemd/user/dunst.service; linked; preset: enabled)
Active: inactive (dead)
mahmoud in ~
✘ systemctl enable --user dunst.service
The unit files have no installation config (WantedBy=, RequiredBy=, Also=,
Alias= settings in the [Install] section, and DefaultInstance= for template
units). This means they are not meant to be enabled using systemctl.
Possible reasons for having this kind of units are:
• A unit may be statically enabled by being symlinked from another unit's
.wants/ or .requires/ directory.
• A unit's purpose may be to act as a helper for some other unit which has
a requirement dependency on it.
• A unit may be started when needed via activation (socket, path, timer,
D-Bus, udev, scripted systemctl call, ...).
• In case of template units, the unit is meant to be enabled with some
instance name specified.
Yeah, dunst is started because it is PartOf graphical-session.target. Generally, nix manages symlinking the services into place itself, so you’re not supposed to use systemctl enable - that’s not reproducible, after all.
We need to get graphical-session.target to start, which your OS is responsible for. If you’re not on NixOS that may take some additional configuration. systemctl status --user graphical-session.target will confirm if it’s not started.
I am on NixOS already. It seems loaded but not running
$ systemctl status --user graphical-session.target
○ graphical-session.target - Current graphical user session
Loaded: loaded (/etc/systemd/user/graphical-session.target; static)
Drop-In: /nix/store/z6av18ds7dqf1ispfj7sdzbbwif549r9-user-units/graphical-session.target.d
└─overrides.conf
Active: inactive (dead)
Docs: man:systemd.special(7)
Do you use a display manager? If you don’t you will need to add starting that target to your session scripts: nixpkgs/default.nix at 6594eb2fc86e22005f48aaeb1011b5a72d99e58e · NixOS/nixpkgs · GitHub
If you insist on not using a display manager, I’d recommend reading through that file in general, as it contains a lot of setup required for various things that won’t be run if you don’t have one.
I don’t use a display manager, and I like to keep it so. I will check that file, hope to figure it out.
But I have to ask, do you have an already configured for this xsession script!?
Thanks for your help!
I do use a display manager 
I’ve not seen anyone actually go through the effort of going without either, but it’s worth looking around others’ git repos.
If you think you have a setup that works well, you could consider upstreaming it to the startx “display manager”. I don’t think that one should ignore the global display manager settings like it does currently.
Alright, Thanks 
I have understood the problem thanks to you, Now will search for a solution
EDIT: found a way around, I just added exec $HOME/.xsession into .xinitrc to start the session. And that fixed the problem.