[15:48] OvenWerks: Controls FTBFS? [15:55] Nm, looks like you fixed it. [21:25] I am downloading 20.04 to install and play with. [21:26] Eickmeyer[m]: I am thinking that systemd session starting/stopping is broken and am hoping it has been fixed since [21:27] OvenWerks: Let me know what you find out. [21:28] There are a number of systemd user services listed in 18.04 that never seem to start. I do not want to bind to xfce4... it apperas that graphical-session never gets reached [21:28] (as a target) [21:29] I think it goes as far as multiuser, then launches the wm as part of target.multiuser. [21:29] That is system that launches systemd --user [21:30] systemd --user gets to the default.target and also xfce4-session.target (which I don't want to use) [21:31] but never to graphical-session.target. [21:32] it may be a problem with how xubuntu is set up. I am not sure if that is a part of session settings or what. [21:36] The whole systemd setup looks wonkie to me. They do not have a session target by default... rather a user target... but that target does not end on session logout but rather not until all processes that belong to that user have ended :P and of course the process that needs to be ended belongs to the user ... [21:38] I notice pulse seems to have the same trouble [21:44] I'd take a look and see how ubuntu is doing it. We want to keep it as DE-independent as possible. [21:46] look in /usr/lib/systemd/usr/ [21:46] but... just because it is there doesn't mean anything [21:47] It may be a bug in xubuntu rather than ubuntu... hopefully fixed by now. [21:50] Highly doubt it. Might be the xfce utilization of systemd, but I don't know that much. I do know that we're not pulling-in any xubuntu-specific systemd items, so it likely just comes from xfce. [21:50] I found that I raised the loggin level (/etc/systemd/user.conf) [21:50] I guess I equate xubuntu with xfce :/ [21:54] Then I do journelctl --user -b and search for "target" (with /target ) [21:55] That will tell you which targets actually are being used [21:56] So, are you trying to call a systemd function from a user at login? Is that what I'm understanding? [21:56] yes [21:56] because that is what putting a desktop file in /etc/xdg/autostart/ does these days [21:57] Wouldn't a better way be to place a .desktop file in ~/.config/autostart ? [21:57] but that has the same trouble... the process does not stop [21:57] a package should never put anything in ~/ [21:57] I see. The idea is that the process would have to be killed at logout. [21:57] yes [21:58] 18.04 does not do that [21:58] so for a single user it is no problem [21:58] In theory, then, it's a process that has to be done by the user so that it gets killed at logout. [21:58] but if the first user logs out and a second user logs, they have no sound [21:59] So, having controls install it to ~/.config/autostart upon first run would be ideal. [21:59] the user should not have to kill autojack or pulse [21:59] no [21:59] autostart does not work and is going to go away anyway [22:00] Not .config/autostart, that's not going anywhere. [22:00] autostart is handled by systemd creating a phantom service that does the actual running. [22:00] Maybe xdg/autostart, but I don't know. Where did you hear this from? [22:00] the freedesktop page [22:01] But ~/.config/autostart/*.desktop is handled by the DE, not systemd. [22:01] not anymore. [22:01] That is why things stopped working [22:03] I will try something else to check though. But at least pulseaudio doesn't seem to work. The second login pulse startup gives "pulseaudio already running" [22:04] I've never once had any issues from applications started via ~/.config/autostart/*.desktop. Even GNOME still uses that to create autostart upon login. It hasn't been removed from the code. I understand why /etc/xdg/autostart might be going away, but if GNOME is still handling it (and they depend on systemd) then it's likely not going anywhere. [22:04] Additionally, gnome-tweaks can be used to add items to ~/.config/autostart as of the latest version. [22:05] I just read the spec, and it only refers to /etc/xdg/autostart, not anything in the user home folder. [22:05] yes the /etc/xdg/autostart/ directory is still there, but it is handled by systemd [22:06] any startup script in ~/.config/autostart can not be properly removed with package removal [22:06] (that is why cadence won't remove correctly) [22:07] everythng we install needs to be outside of the user directory [22:07] I'm not saying it's installed by us, I'm saying it's installed by the user as part of running -controls for the first time. [22:07] Same as cadence [22:08] not acceptable. That is the same as it being installed there by the package [22:08] it still will not be removed by removing the package [22:08] Unfortunately, there's no systemd call (that I know of) that can be run by the user. It has to be run by the root AS a different user, and does not depend on user login/out. [22:09] systemd --user start [22:09] That's fine, because if it's calling usr/bin/autojack and it fails, nothing happens. [22:10] ^ That isn't called by any DE that I know of upon login. [22:11] no logind calls something like that though [22:11] no worrys I will figure it out [22:11] Ok.