Thanks; I tried those two commands and both give an error:
No files found for gnome-terminal-service.service.
(or "dbus.service" for the dbus variant). I guess this is because Ubuntu GNOME 16.04 is using dbus to launch gnome-terminal, not systemd?
Your suggestion of a DefaultUMask option for user.conf sounds as though it would fix the problem in the same way as the equivalent DBus option, but I think it should be raised by someone on the gnome-session team, because it needs to be documented as part of the requirements of gnome-session (otherwise, gnome-session has an undocumented reliance on a particular configuration of systemd simply to fix this bug). This also sounds like a rather fragile fix (because it relies on configuring an underlying component in a particular way). Is there a better way to do this?
For example, it's a surprise to me that systemd --user does not run in the scope of the user's .profile. Is there a reason for this? Can it be changed so that it does? This is presumably not just a matter of the umask, but more fundamentally of anything else set in the user's .profile (environment variables are certainly not respected at present, for example; what about ulimit parameters?). This is a fundamental (in the literal sense) breakage of the normal expectations of session login, and it requires a robust fix.
Reopening, since regardless of where the fix is located, it's a bug in GNOME.
Thanks; I tried those two commands and both give an error:
No files found for gnome-terminal- service. service.
(or "dbus.service" for the dbus variant). I guess this is because Ubuntu GNOME 16.04 is using dbus to launch gnome-terminal, not systemd?
Your suggestion of a DefaultUMask option for user.conf sounds as though it would fix the problem in the same way as the equivalent DBus option, but I think it should be raised by someone on the gnome-session team, because it needs to be documented as part of the requirements of gnome-session (otherwise, gnome-session has an undocumented reliance on a particular configuration of systemd simply to fix this bug). This also sounds like a rather fragile fix (because it relies on configuring an underlying component in a particular way). Is there a better way to do this?
For example, it's a surprise to me that systemd --user does not run in the scope of the user's .profile. Is there a reason for this? Can it be changed so that it does? This is presumably not just a matter of the umask, but more fundamentally of anything else set in the user's .profile (environment variables are certainly not respected at present, for example; what about ulimit parameters?). This is a fundamental (in the literal sense) breakage of the normal expectations of session login, and it requires a robust fix.
Reopening, since regardless of where the fix is located, it's a bug in GNOME.