[ale] Lab Workstation Mystery

[DJ-Pfulio]

Just to clarify, not all Ubuntu systems work that way.  On a 14.04 box:

$ psg systemd
root     31358     1  0 Apr16 ?   00:00:01 /lib/systemd/systemd-udevd --daemon
root     31427     1  0 Apr16 ?   00:00:00 /lib/systemd/systemd-logind

Zero ibus stuff. Way too many dbus things.
message+   810     1  0 Apr10 ?   00:00:01 dbus-daemon --system --fork

That's all.
I only run LTS, so don't have any 15.xx to check. Need to install a play 16.04
this week to see what they've done this time. Heard they removed all the
external amazon data transfers as the default, finally.

On 04/25/2016 07:25 AM, Jim Kinney wrote:
> I checked my centos 7 and fedora 23 systems. They don't spawn off as user owned
> processes. In fact, they don't fork at all. The systemd processes handle the
> needs directly.
> 
> I find it very odd that ubuntu and centos have such very different systemd
> methodology.
> 
> On Apr 24, 2016 11:48 AM, "Todor Fassl" <fassl.tod at gmail.com
> <mailto:fassl.tod at gmail.com>> wrote:
> 
>     I'm at home this morning on an ubuntu 15.10 system with a local home
>     directory and no autofs. Ps shows that all 4 of those processes are running
>     for me -- systemd, (sd-pam), ibus-daemon, and ibus-dconf. BTW, I googled for
>     sd-pam and it looks like that is a fork/rename of the systemd process
>     intended to desstroy the session. ie., sd-pam means "session destroy pam". 
>     Apparently, when you fork/rename a process, you can rename it whatever you
>     like including putting parens around the name. But those parens don't mean
>     anything.
> 
>     I suspect ubuntu starts a per-user systemd process.  The one thing that
>     might be non-standard for my users is that the default window manager is
>     gnome, not unity. I'll have to experiment with that. Another thing I'll have
>     to try is to uninstall the screen reader. I've mentioned before that I am
>     blind. You can press Alt+Super+s to start the screen reader at the lightdm
>     login screen. I don't *think* that requires a special process to run unless
>     you actually use the hotkey. Most of my end-users would not be firing up the
>     screen reader so I doubt it has anything to do with that.
> 
>     But I'll have to do a straight up install of ubuntu and log in to unity as a
>     local user and then log out. The log out part might be tricky. I might have
>     to get sighted assistance to do that. Oh, as I write this, it occurs to me
>     that there is probably a hotkey in unity to log out. So set up a plain
>     vanilla system, log in, log out, and see if those processes hang around.
> 
>     On 04/23/2016 10:43 AM, Jim Kinney wrote:
>>
>>     That is odd. I have systemd machines with automount and I don't see an
>>     individual systemd process per user. On my centos7 workstations, I have
>>     only a single systemd process for the systemd itself plus others named
>>     like systemd-udevd, etc, and all are root owned.
>>
>>     On Apr 23, 2016 11:36 AM, "Todor Fassl" <fassl.tod at gmail.com
>>     <mailto:fassl.tod at gmail.com>> wrote:
>>
>>
>>         The first thing I did was add that option to the nfs mount in the
>>         autofs config. I thought it didn't work but back then   I didn't have
>>         as good of a handle on the problem as I do now.  I found bug reports
>>         related to the default timeout for aufs not working. The bug reports
>>         said the timeout worked if you set itimplicitly for each share in the
>>         autofs config files. But that turned out being another red-herring.
>>
>>         I am pretty sure this is a systemd problem. I just did an experiment
>>         -- I killed off the processes left over after a user logged out on 3
>>         different workstations but I did not unmount their home directory.
>>         Each of the 3 had the same 4 processes running, systemd,(sd-pam),
>>         ibus-daemon, and ibus-dconf. All I did was kill off those 4 processes
>>         and after the usual time, the automounter unmounted their home
>>         directory. So I am about as sure as I can be that this is not an
>>         automounter or nfs problem. It's systemd not killing off those
>>         processes when a user logs out.
>>
>>         Three days -- so far so good.
>>
>>         On 04/22/2016 11:27 AM, Scott Plante wrote:
>>>         This isn't a solution to the underlying problem, but you might want
>>>         to consider the "soft" option for the NFS mount. By default, NFS is
>>>         designed to act like a physical disk in the sense that once the user
>>>         initiates a write, it will block at that spot until the write
>>>         completes. This is great if you have a NAS unit in the next rack slot
>>>         from your database server. However, if you don't need quite that
>>>         level of write assurance, the "soft" option acts more like a typical
>>>         remote network share. If a problem occurs, the writer will just get
>>>         an I/O error and be forced to deal with it. You won't get the kind of
>>>         system hanging you experience with hard mounts. If you're just saving
>>>         documents and doing that kind of basic file I/O this is perfect.
>>>         You're mounting home directories, so you're somewhere in between, but
>>>         depending on what your users are actually doing, soft mounts may be
>>>         for you. Again, this doesn't explain the whole re-mounting read-only
>>>         behavior but it may still be helpful for you to look into.
>>>
>>>         Scott
>>>