| OvenWerks | kubuntu uses it even less... | 02:20 |
|---|---|---|
| Eickmeyer[m] | OvenWerks: Well, that means it's a flaw in systemd in that the graphical target isn't being used yet. Chances are, it was never implemented in the systemd code. | 03:12 |
| Eickmeyer[m] | Hence why xdg/autostart is still in use. | 03:12 |
| OvenWerks | That still leaves us with processes that don't stop | 03:21 |
| OvenWerks | (leaves everybody with) | 03:22 |
| Eickmeyer[m] | Unless we have the daemon check for a keepalive somehow. | 03:26 |
| Eickmeyer[m] | OR, set a pid file somewhere that if it sees it, it kills the previous process and sets a new pid. | 03:26 |
| OvenWerks | Ya, which one? | 03:26 |
| OvenWerks | it won't see a previour pid if it a different user | 03:27 |
| Eickmeyer[m] | Why not if it's in /tmp | 03:27 |
| OvenWerks | unless we start thinking sudo stuff | 03:27 |
| Eickmeyer[m] | And there's another idea. Why not a systemd daemon that watches for multiple instances of autojack and kills the first one spawned if another one launches? | 03:28 |
| Eickmeyer[m] | I'm just trying to think outside the box here. | 03:31 |
| OvenWerks | Ya, I know. | 03:32 |
| Eickmeyer[m] | Basically, anything we come up with might not be necessarily "correct", but we need to get the job done. | 03:32 |
| OvenWerks | I can make it work in xfce with no problem... it is the making de agnostic part that is hard. | 03:35 |
| Eickmeyer[m] | Yeah. I understand. | 03:36 |
| OvenWerks | It seems all the people who use ubuntu/debian/whatever never logout to login as another user. | 03:36 |
| OvenWerks | this is certainly why this bug has been around for years... | 03:36 |
| Eickmeyer[m] | I mean, there has to be a workaround, or something we can do. | 03:41 |
| OvenWerks | There will be | 03:41 |
| OvenWerks | We may have to generate our own target(s) to do it. | 03:42 |
| Eickmeyer[m] | Isn't that what that link was about? | 03:43 |
| OvenWerks | All of them so far at least get to default.target going one way... we may have to sense session end and send our own dbus signal to get rid of the rest of the session. | 03:43 |
| OvenWerks | this one? : https://superuser.com/questions/759759/writing-a-service-that-depends-on-xorg | 03:45 |
| Eickmeyer[m] | Yeah, that's what I was talking about. | 03:45 |
| OvenWerks | it is more about starting things than finishing | 03:45 |
| Eickmeyer[m] | Though, that's for starting something than for... yeah, that. | 03:45 |
| OvenWerks | I wonder if I can set up a *.path unit | 03:53 |
| Eickmeyer[m] | ¯\_(ツ)_/¯ idk | 03:56 |
| OvenWerks | I logged out and found I have three sessions going (according to longind) | 04:02 |
| Eickmeyer[m] | Oof | 04:03 |
| OvenWerks | Eickmeyer[m]: I am not sure if this is a logind, systemd (both are the same anyway) or DE bug, | 20:43 |
| OvenWerks | Once a DE allows itself to be run by logind, I think that DE should realize it's responceablity to inform logind/systemd when it is finished | 20:44 |
| Eickmeyer[m] | I'd think logind should be able to sense when a session is done and kill all processes started by that user in that session. | 20:45 |
| OvenWerks | On the other hand, depending on how the DE session is started... a process that is detached/backgrounded may not show up as a part of that session. | 20:47 |
| OvenWerks | if I use a display manager to start a session, that is a session. If I then login SSH to a tarminal (or even ssh -Y for a graphic session, that is another session already. | 20:48 |
| OvenWerks | And that second session should not get killed by the local session logging out. | 20:49 |
| OvenWerks | There are two ways of ending a session: Telling logind to exit... very harsh. Telling systemd to goto the exit.target... much more ordered shutdown. | 20:50 |
| OvenWerks | Eickmeyer[m]: I think that because the DE has decided to be responcible to call systemd:reboot,halt,poweroff, etc, the DE should also do the call to systemd to start target exit.target | 20:53 |
| OvenWerks | it is too bad that the systemd method for doing so is completely different for exiting a session that it is for poweroff or reboot but it does make sense. | 20:55 |
| Eickmeyer[m] | We just need to have autojack listen for a dmesg that the session is ending, if possible. | 20:55 |
| OvenWerks | autojack already does that | 20:56 |
| OvenWerks | That part is not hard | 20:56 |
| OvenWerks | even apart from Studio's problem with loosing access to sound devices, it is still a bug that after logging in and out a few times with no reboot, _all_ the sessions ever logged into are still running | 20:57 |
| OvenWerks | This is also bad from our point of view as we don't know what other bits of code are still running from a previous login (either our own or another). | 20:58 |
| OvenWerks | Eickmeyer[m]: in the mean time, we need to change the message after adding the user to the audio group from you need to logout and back in to you need to reboot. | 20:59 |
| OvenWerks | in fact we could even put up a dialog simial to a kernel install that says "reboot now?", "reboot later" | 21:00 |
| OvenWerks | *similar | 21:00 |
| OvenWerks | I am going to put in a pr the xfce project to fix xfce... it should be relatively easy and would just fix our problem | 21:02 |
| Eickmeyer[m] | Right, but how does that work for other DEs? | 21:03 |
| OvenWerks | I will put in bug reports to the other DEs with a pointer to the fix on xfce :) | 21:03 |
| Eickmeyer[m] | Ok, seems fair. | 21:03 |
| OvenWerks | It is not that hard. | 21:04 |
| OvenWerks | The other thing we could do, is to just come up with script to run on DE shutdown for each DE (they are all different) that runs the call to systemd... | 21:05 |
| OvenWerks | That would be even easier, but, it may not allow the DE to properly shut down | 21:06 |
| OvenWerks | That is the DE may run those scritps before they have done session save kinds of things (they shouldn't but...) | 21:06 |
| Eickmeyer[m] | When the app gets the SIGTERM signal, then it could be passed to a shutdown process. | 21:07 |
| OvenWerks | I suppose we could fork the shutdown script and add a delay :P | 21:07 |
| OvenWerks | I am not sure that systemd when it changes targets uses a sigterm. | 21:08 |
| Eickmeyer[m] | Something has to use a sigterm. | 21:09 |
| OvenWerks | autojack now catches all the signals it can and I have never seen any in the log file... so it may be that they jusy go kill -9 | 21:09 |
| OvenWerks | if I send autojack a kill -sigint I see it in the logfile | 21:10 |
| Eickmeyer[m] | Possible, but I've had processes literally hold a DE open because they're still completing their SIGTERM-induced shutodown procedures. It could be that it's getting sigkilled because it's not listening for sigterm. | 21:10 |
| OvenWerks | that is the DE | 21:10 |
| Eickmeyer[m] | brb | 21:10 |
| OvenWerks | autojack seems to run outside of the DE | 21:10 |
| Eickmeyer[m] | That's a problem. | 21:30 |
| OvenWerks | Eickmeyer[m]: it's not the only thing. | 21:33 |
| OvenWerks | Eickmeyer[m]: for 2004 I thik we will add an /etc/xdg/autostart/sessionkill.desktop | 21:35 |
| Eickmeyer[m] | Yep, that should fix the issue. Yes, I know xdg/autostart is going away eventually, but that can't happen until systemd gets their S fixed. | 21:36 |
| OvenWerks | It will run a script with & and wait 10 sec (5 maybe/, an ssd run system only needs 1 sec) and then send a dbus message to systemd to hit the exit.target | 21:37 |
| OvenWerks | Eickmeyer[m]: how quick do you think someone can relogin? | 21:38 |
| OvenWerks | I am thinking with an ssd it may be as short as 3 sec | 21:39 |
| OvenWerks | though autojack does have a builtin delay before trying to do anything to wait for pulse to settle. | 21:40 |
| OvenWerks | Eickmeyer[m]: I think lubuntu uses a lot of xfce bits or at least follows xfce ways of doing things | 21:42 |
| OvenWerks | well they used to before qt | 21:43 |
| OvenWerks | plasma has another way of setting scripts to run at exit but it is different enough from anything else we can probably install a script there and it won't affect xfce | 21:44 |
| OvenWerks | I don't know how gnome does things, but I suspect a systemd unit would work in their case | 21:45 |
| OvenWerks | in gnome's case at least some units quit on session stop so set something up to see that go away and call exit target (again with a delay) | 21:46 |
| OvenWerks | I don't know which DEs this misses | 21:47 |
| Eickmeyer[m] | Budgie and Cinnamon, I think. | 21:54 |
| Eickmeyer[m] | OvenWerks: Budgie, Cinnamon, and MATE. | 21:56 |
| * OvenWerks is not knowing how they do things | 22:02 | |
| OvenWerks | It seems to me they are all related to some version of gnome, either dirrectly or as a modified fork. | 22:03 |
| OvenWerks | gnome2 had no idea of systemd (lucky dogs) | 22:04 |
| Eickmeyer[m] | Cinnamon is a fork of Gnome 3, Budgie is a rebase on Gnome, and MATE is a fork of Gnome 2 that now uses GTK 3. | 22:05 |
| Eickmeyer[m] | Might have to ask #ubuntu-flavors how they do things, though I do see Wimpress lurking in here. He may be able to answer MATE questions. | 22:06 |
| Eickmeyer[m] | I might be able to get bashfulrobot in here to talk about how Budgie does stuff. That should cover the actual flavors as they are now. | 22:07 |
| OvenWerks | BTW, I have no problem with systemd, just the mess during switchover | 22:09 |
| Eickmeyer[m] | Yeah. | 22:09 |
| Eickmeyer[m] | I can probably get ItzSwirlz to talk about Cinnamon. | 22:10 |
| OvenWerks | Anyone who is using gnome3 probably does startup/exit in a similar way. | 22:11 |
| Eickmeyer[m] | Not necessarily. Cinnamon forked before systemd was in wide use. | 22:11 |
| OvenWerks | Eickmeyer[m]: for 2004 we just need to worry about xfce anyway. | 22:12 |
| OvenWerks | any other DE we can recommend no to logout but to reboot instead | 22:12 |
| OvenWerks | as we work on thing after 2002, backports will deal with it | 22:13 |
| Eickmeyer[m] | That's a good point. | 22:14 |
| OvenWerks | we can point out in our recomendation that the reason for reboot instead of logout is a bug in the way systemd is being used by "some" DEs (so we are not pointing fingers at any one) | 22:15 |
| Eickmeyer[m] | Though, it would be nice to get as much covered as possible. | 22:15 |
| OvenWerks | like evryone else, I have other fish to fry... | 22:16 |
| OvenWerks | For each DE I even send a bug report to, I have to dl the iso, install, test, create some text files that show the problem then I can file a BUG report | 22:17 |
| OvenWerks | That is a fair amount of time required | 22:18 |
| Eickmeyer[m] | Yeah, I get that. I think just covering KDE, Gnome, and Xfce, in terms of workaround, might be good enough. | 22:25 |
| Eickmeyer[m] | Not necessarily bug report because, lets face it, that's not going to get fixed in time for 20.04. | 22:25 |
| OvenWerks | right, but it is not right or fair to the DE to use a hack without at least filing a bugreport to show why | 22:26 |
| Eickmeyer[m] | Yeah. I say do the bug reports as you have time. | 22:28 |
| * RikMills checks the room for existence | 22:54 | |
| RikMills | seems ok | 22:54 |
| Eickmeyer[m] | RikMills: Right??? bashfulrobot's client is off its rocker. | 22:59 |
| OvenWerks | Eickmeyer[m]: regarding kill signals, init (and maybe upstart?) seemed to have the idea that they would send a kill, wait for a timeout then kill -9 whatever was left. systemd does not seem to be set up that way... though it could just be a default setting in systemd. | 23:01 |
| Eickmeyer[m] | OvenWerks: You could be right. | 23:05 |
| bashfulrobot | Eickmeyer: hey | 23:11 |
| bashfulrobot | Looks like it was a line wrapping thing. | 23:11 |
| Eickmeyer[m] | Ah. | 23:12 |
| Eickmeyer[m] | bashfulrobot: How does Budgie handle terminating applications on exit? We have a daemon (autojack) that runs as part of Ubuntu Studio Controls that we need to have exit upon logout, but currently isn't for some unknown reason. | 23:13 |
| Eickmeyer[m] | OvenWerks has more details as he's working on it. | 23:13 |
| OvenWerks | bashfulrobot: after logout and back in loginctl list shows the old session is still running... and after yet another logout and in there are now three sessions running. In all the DEs we have tried so for this seems to be the case (xfce, plasma, lubuntu) | 23:15 |
| OvenWerks | we noticed this because, the sound device remains locked by the first session | 23:16 |
| OvenWerks | (jackdbus continues to run) | 23:17 |
| OvenWerks | it tends to go un-noticed because logou and in is not really a thing with most people | 23:17 |
| OvenWerks | we do have a solution at least for xfce4-session-manager. But would like to see the other flavours benefit as well. | 23:19 |
| bashfulrobot | I have asked to see if David can jump in. I honestly am not sure why that would happen. | 23:19 |
| OvenWerks | the why is very obvous | 23:20 |
| bashfulrobot | Hey fossfreedom. Thanks for jumping on. | 23:20 |
| fossfreedom | yw | 23:21 |
| OvenWerks | with regard to session start up and stop, logind does two things, it starts the DE and it starts a systemd --user instance or session | 23:22 |
| OvenWerks | when the DE quits, the systemd --user session persists | 23:23 |
| OvenWerks | and the second login may loose access to resources the first session now own. | 23:23 |
| OvenWerks | using jouralctl --user -b shows the user session going through its targets to default (or beyond in some DEs) and then at de logout that session remains active | 23:24 |
| OvenWerks | using loginctl shows that all login sessions since boot are still active. | 23:25 |
| OvenWerks | we were wondering if Budgie has the same problem or if not how it has been avoided. | 23:26 |
| OvenWerks | we noticed this because the audio device ends up locked by the first session and not available on another session | 23:27 |
| fossfreedom | hmm - don't think we can be useful here. We are using gnome-session to logout. If its using systemd behind the scenes we aren't aware - gnome-session is handling it all for us. | 23:28 |
| OvenWerks | When I looked ast xfce4-session-manager, I can see that for reboot, halt, poweroff, etc. a dbus message is sent to systemd, but for logout no. | 23:29 |
| OvenWerks | fossfreedom: so you may have the same problem but be unaware of it. | 23:29 |
| OvenWerks | is the gnome session that you use the same as gnome 3? | 23:30 |
| fossfreedom | I'm missing the scrollback - so I'm not following what the issue is. | 23:30 |
| fossfreedom | yes - same as GNOME3 | 23:30 |
| OvenWerks | good, if gnome3 gets fixed so would you. | 23:31 |
| Eickmeyer[m] | fossfreedom: TL;DR: We have a daemon (autojack) that runs as part of Ubuntu Studio Controls that we need to have exit upon logout, but currently isn't for some unknown reason. | 23:31 |
| OvenWerks | the problem is that logind sessions never exit | 23:31 |
| OvenWerks | the reason is because the systemd session does not end, because xfce doesn't tell it to. | 23:32 |
| fossfreedom | ok - understand. thanks for the background | 23:32 |
| OvenWerks | to check logout->login in a terminal type loginctl (aka loginctl list) and you should only see one session listed | 23:34 |
| OvenWerks | if you see two, then the problem is there too. | 23:34 |
| OvenWerks | hmm that was not clear | 23:34 |
| OvenWerks | open the terminal after the second login :) | 23:34 |
| OvenWerks | a thrid login will show three sessions etc. | 23:37 |
| fossfreedom | on 20.04 UB logged out as one user - then logged into another user. Ran loginctl list-sessions and it shows 1 session | 23:38 |
| OvenWerks | good. | 23:38 |
| Eickmeyer[m] | Ok, then that means that Budgie and Gnome run as intended. | 23:38 |
| OvenWerks | fossfreedom: thankyou for testing for us | 23:40 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!