[15:48] <Eickmeyer[m]> OvenWerks: Controls FTBFS?
[15:55] <Eickmeyer[m]> Nm, looks like you fixed it.
[21:25] <OvenWerks> I am downloading 20.04 to install and play with.
[21:26] <OvenWerks> Eickmeyer[m]: I am thinking that systemd session starting/stopping is broken and am hoping it has been fixed since
[21:27] <Eickmeyer[m]> OvenWerks: Let me know what you find out.
[21:28] <OvenWerks> 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] <OvenWerks> (as a target)
[21:29] <Eickmeyer[m]> I think it goes as far as multiuser, then launches the wm as part of target.multiuser.
[21:29] <OvenWerks> That is system that launches systemd --user
[21:30] <OvenWerks> systemd --user gets to the default.target and also xfce4-session.target (which I don't want to use)
[21:31] <OvenWerks> but never to graphical-session.target.
[21:32] <OvenWerks> 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] <OvenWerks> 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] <OvenWerks> I notice pulse seems to have the same trouble
[21:44] <Eickmeyer[m]> I'd take a look and see how ubuntu is doing it. We want to keep it as DE-independent as possible.
[21:46] <OvenWerks> look in /usr/lib/systemd/usr/
[21:46] <OvenWerks> but... just because it is there doesn't mean anything
[21:47] <OvenWerks> It may be a bug in xubuntu rather than ubuntu... hopefully fixed by now.
[21:50] <Eickmeyer[m]> 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] <OvenWerks> I found that I raised the loggin level (/etc/systemd/user.conf)
[21:50] <OvenWerks> I guess I equate xubuntu with xfce :/
[21:54] <OvenWerks> Then I do journelctl --user -b and search for "target" (with /target )
[21:55] <OvenWerks> That will tell you which targets actually are being used
[21:56] <Eickmeyer[m]> So, are you trying to call a systemd function from a user at login? Is that what I'm understanding?
[21:56] <OvenWerks> yes
[21:56] <OvenWerks> because that is what putting a desktop file in /etc/xdg/autostart/ does these days
[21:57] <Eickmeyer[m]> Wouldn't a better way be to place a .desktop file in ~/.config/autostart ?
[21:57] <OvenWerks>  but that has the same trouble... the process does not stop
[21:57] <OvenWerks> a package should never put anything in ~/
[21:57] <Eickmeyer[m]> I see. The idea is that the process would have to be killed at logout.
[21:57] <OvenWerks> yes
[21:58] <OvenWerks> 18.04 does not do that
[21:58] <OvenWerks> so for a single user it is no problem
[21:58] <Eickmeyer[m]> In theory, then, it's a process that has to be done by the user so that it gets killed at logout.
[21:58] <OvenWerks> but if the first user logs out and a second user logs, they have no sound
[21:59] <Eickmeyer[m]> So, having controls install it to ~/.config/autostart upon first run would be ideal.
[21:59] <OvenWerks> the user should not have to kill autojack or pulse
[21:59] <OvenWerks> no
[21:59] <OvenWerks> autostart does not work and is going to go away anyway
[22:00] <Eickmeyer[m]> Not .config/autostart, that's not going anywhere.
[22:00] <OvenWerks> autostart is handled by systemd creating a phantom service that does the actual running.
[22:00] <Eickmeyer[m]> Maybe xdg/autostart, but I don't know. Where did you hear this from?
[22:00] <OvenWerks> the freedesktop page
[22:01] <Eickmeyer[m]> But ~/.config/autostart/*.desktop is handled by the DE, not systemd.
[22:01] <OvenWerks> not anymore.
[22:01] <OvenWerks> That is why things stopped working
[22:03] <OvenWerks> 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] <Eickmeyer[m]> 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] <Eickmeyer[m]> Additionally, gnome-tweaks can be used to add items to ~/.config/autostart as of the latest version.
[22:05] <Eickmeyer[m]> I just read the spec, and it only refers to /etc/xdg/autostart, not anything in the user home folder.
[22:05] <OvenWerks> yes the /etc/xdg/autostart/ directory is still there, but it is handled by systemd
[22:06] <OvenWerks> any startup script in ~/.config/autostart can not be properly removed with package removal
[22:06] <OvenWerks>  (that is why cadence won't remove correctly)
[22:07] <OvenWerks> everythng we install needs to be outside of the user directory
[22:07] <Eickmeyer[m]> 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] <OvenWerks> Same as cadence
[22:08] <OvenWerks> not acceptable. That is the same as it being installed there by the package
[22:08] <OvenWerks> it still will not be removed by removing the package
[22:08] <Eickmeyer[m]> 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] <OvenWerks> systemd --user start <service_name.service>
[22:09] <Eickmeyer[m]> That's fine, because if it's calling usr/bin/autojack and it fails, nothing happens.
[22:10] <Eickmeyer[m]> ^ That isn't called by any DE that I know of upon login.
[22:11] <OvenWerks> no logind calls something like that though
[22:11] <OvenWerks> no worrys I will figure it out
[22:11] <Eickmeyer[m]> Ok.