Skip to content
This repository has been archived by the owner on Mar 7, 2020. It is now read-only.

Time to retire cerbere? #36

Closed
davidmhewitt opened this issue Jan 7, 2020 · 15 comments
Closed

Time to retire cerbere? #36

davidmhewitt opened this issue Jan 7, 2020 · 15 comments

Comments

@davidmhewitt
Copy link
Member

While looking into the various polkit issues reported recently, I've found that it's probably something related to things like #35 or #33 . It seems cerbere clings on (despite being told to exit), even at logout and leaves behind a mess that the next session can't quite clean up and recover from.

I've tried digging into the cause of these issues a bit further and I'm making very slow progress due to the difficulty in debugging Cerbere.

I've already ran a little experiment that proves it would be possible to have gnome-session launch and relaunch (in the case of failure) components that are currently looked after by cerbere (plank and wingpanel), but there are a couple of points to consider:

  • There's a hardcoded restart limit within gnome-session wherein if something crashes or is killed more than once within a minute, it's considered dead.
  • If this crashing/killed component is listed as a required component of the session, then the session is considered dead too and you get kicked back to the login screen.

So there's a decision to be made as to whether wingpanel and/or plank should be considered required components of the session. It feels as though if wingpanel is failing to start, then it would make sense to drop out of the session as pantheon isn't much use without wingpanel. However, I feel as though crashing more than once within a minute being considered a failure is a bit aggressive.

The immediate concern for me is that the above makes developing wingpanel (or indicators) hard because if you restart wingpanel more than once within a minute (which I frequently do while working on wingpanel), then you kill your session.

However, if we don't list plank and wingpanel as required components of the session, then they should be restarted as long as they're not crashing more than once every minute. If the limit is breached, then the automatic restarting stops and you're left in a session without wingpanel and/or plank.

I suppose another option would be to leave them as required components but patch gnome-session to make this limit less aggressive.

I think the controllability of these limits improves slightly in GNOME >3.34 as I believe they're using systemd to manage session components now instead of custom code within gnome-session. But I think even migrating to using gnome-session at this point could still be worthwhile as it's slightly closer to the current/future GNOME philosophy and it's probably a quick way to clean up a few of the bugs we're seeing related to cerbere.

Thoughts?

@danirabbit
Copy link
Member

I think moving to using GNOME Session without the required option is probably going to give us the most similar outcome to the current behavior. Cerbere stops trying to restart the component after some limit that's less agressive, but realistically if we're seeing some kind of crashing in shell components that frequently that seems like a bigger issue.

I think I agree with you that leaving off the required option is probably better for development since getting kicked out the session while working on the panel would be a pain.

Maybe can re-investigate having a developer session or something in the future so that we can give users this extra protection of exiting the session. But I would consider that outside the scope of the current issue.

I'm in favor of retiring cerbere and using GNOME session here :)

@tintou
Copy link
Member

tintou commented Jan 7, 2020

I'm also in favor of retiring cerbere and using GNOME Session without the required field as it is not a core component like Gala would be for instance.

@davidmhewitt
Copy link
Member Author

Further experiments with this show that wingpanel is happy being launched and managed by gnome-session in this way, but plank fails to start for some reason and I can't find a single reason why in the logs.

Continuing to investigate...

@davidmhewitt
Copy link
Member Author

Ok, figured that out, there was a NotShowIn=Pantheon; in the plank desktop file that was telling gnome-session not to start it. I now have a session where plank and wingpanel are launched by gnome-session and aren't required components. Cerbere isn't running and doesn't need to run anymore and I don't seem to be having issues with polkit anymore.

However, they're not automatically restarted when they crash or are killed. I think we need to add some extra code to wingpanel and plank so they register with the session manager properly. I'll test this out next.

@davidmhewitt
Copy link
Member Author

davidmhewitt commented Jan 9, 2020

Not as complicated as I thought, I'd just typo'd something. It's just changes to some install paths and desktop files to replace cerbere with gnome-session and make polkit work again...

In summary, we need to ensure the following are set in the desktop files for wingpanel and plank and ensure we remove any NotShowIn=Pantheon keys:

NoDisplay=true
X-GNOME-Autostart-Notify=false
X-GNOME-AutoRestart=true
X-GNOME-Autostart-enabled=true
X-GNOME-Autostart-Phase=Panel
OnlyShowIn=Pantheon;

We also need to install those desktop files to /etc/xdg/autostart and we need to disable cerbere in some way, which is as simple as removing its autostart file from the same folder, or maybe removing plank and wingpanel from it's config of watched applications.

When these fixes are released to users, there will obviously need to be a simultaneous plank, cerbere and wingpanel release.

There are reasons why I haven't just gone ahead and done PRs for that:

  • There's a desktop file specific to elementary/pantheon for plank that I can't find in a repository anywhere. It appears at some point in launchpad as a patch, but I can't track down the source, so 🤷‍♂️
  • I'm not sure of the best way to disable cerbere, I guess we need to make a new release that's essentially an empty package to sunset it for current users, but unsure if that's correct?
  • Also unsure how these changes to desktop files and installing them into the autostart folder affects other distros and their packaging.

I don't have a huge amount of time at the moment to look into the above as I'm really busy with my day job, but hopefully this investigation helps and provides some relatively bite sized tasks for someone else to pick up and finish off the fix.

@danirabbit
Copy link
Member

danirabbit commented Jan 10, 2020

Wingpanel autostart desktop added in elementary/wingpanel#274

@quequotion

This comment has been minimized.

@davidmhewitt

This comment has been minimized.

@quequotion

This comment has been minimized.

@davidmhewitt

This comment has been minimized.

@quequotion

This comment has been minimized.

@davidmhewitt

This comment has been minimized.

@quequotion
Copy link

quequotion commented Jan 13, 2020

Definitely worth discussing, and apologies if I came across as abrupt or dismissive. We're trying to pursue this as a quick fix to a number of quite major problems in the currently released version of elementary cause by cerbere so thinking about how this might work in the future is a low priority. However, I did say I was unsure how this would affect other distros, so this is useful information and we'd certainly be interested to hear your findings and any solutions you find.

No worries; I'll keep digging. It does sound like this is likely to require (a) separate issue report(s), toward the eventual implementation of user systemd services for wingpanel and plank (as much as I'd rather not dictate use of systemd.. the facts are that I am already using it and so is every elementary OS user).

Edit: I found a workaround. In order to use X-GNOME-AutoRestart with gnome-session 3.34+, it is necessary to start gnome-session with --builtin, and avoid systemd session management altogether!

@MamasLT

This comment has been minimized.

@danirabbit
Copy link
Member

Closing since this should now be completed

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

6 participants