[ale] Lab Workstation Mystery

Wed Apr 27 13:49:41 EDT 2016

It is probably not surprising that there are differences on what systemd 
processes are running between 14.04 and 15.10.  Upstart was the default 
launcher daemon in 14.04 and systemd is the default for 15.10. They 
changed the default somewhere around 15.04.

I am kind of bummed out. I did a fresh install of ubuntu 15.10 and 
logged in and logged out. No problem. I configured ldap authentication 
and nfs home directories, logged in and logged out, no problem. That 
means that one of the eleventy gazillion things I do when setting up a 
workstation is the culprit. We do our installs via FAI (Fully Automated 
Install) and it is going to be very difficult to pin down the cause.

On 04/25/2016 07:42 AM, DJ-Pfulio wrote:
> 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
>>>>
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at
> http://mail.ale.org/mailman/listinfo
>

-- 
Todd