Cloudron makes it easy to run web apps like WordPress, Nextcloud, GitLab on your server. Find out more or install now.


Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Bookmarks
  • Search
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Brand Logo

Cloudron Forum

Apps | Demo | Docs | Install
  1. Cloudron Forum
  2. Support
  3. Ubuntu 20.04 "landscape" user account running mysqld

Ubuntu 20.04 "landscape" user account running mysqld

Scheduled Pinned Locked Moved Solved Support
mysqllandscape
24 Posts 3 Posters 2.4k Views 3 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • d19dotcaD Offline
      d19dotcaD Offline
      d19dotca
      wrote on last edited by girish
      #1

      I was just looking at top output, and sorted by memory usage. The top user is mysqld which makes sense, but the user for it is a user named landscape (had to look it up in the /etc/passwd file). I don't believe I ever saw that user before.

      I'm on a new Vultr server, so I suspect this may be part of their Ubuntu image by default. Any insight into whether I can remove this user / mysqld process from running with landscape user account? I did a quick search and seems landscape may be referring to https://landscape.canonical.com

      Trying to make sure that my server isn't using memory unnecessarily. If that process doesn't need to be running, then I'd like to kill it and prevent it from running. I noticed there is a mysqld process run by the mysql user which I assume is the one Cloudron uses?

          PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND                      
       944441 landsca+  20   0 2117548 512052  12652 S   0.7   6.3  46:07.32 mysqld                       
       948075 yellowt+  20   0 1212232 197468   7428 S   0.0   2.4   1:03.32 ruby2.7                      
       948080 yellowt+  20   0 1212232 165064   7732 S   0.0   2.0   1:04.72 ruby2.7                      
       947549 yellowt+  20   0  411812 130972   3468 S   0.0   1.6   2:18.52 ruby2.7                      
        57251 mysql     20   0 2099864 111712   4924 S   0.0   1.4  89:31.31 mysqld                       
          762 yellowt+  20   0  983452 110204  16368 S   0.0   1.4 286:15.49 node                         
       948338 yellowt+  20   0   10.9g 100668  14156 S   0.0   1.2   3:26.48 node                         
       947547 yellowt+  20   0  468668  99380   1984 S   0.0   1.2   0:21.64 ruby2.7                      
      4099406 www-data  20   0  162064  80756  34464 S   0.0   1.0   0:00.26 php                          
      3505159 yellowt+  20   0  111756  77764   6232 S   0.0   1.0   0:17.31 spamd child                  
      4101518 www-data  20   0  157532  76676  34256 S   0.0   0.9   0:00.21 php7.4                       
      4089812 www-data  20   0  386708  76260  55560 S   0.0   0.9   0:00.80 /usr/sbin/apach              
      4099413 www-data  20   0  157568  76092  34260 S   0.0   0.9   0:00.22 php                          
      4101528 www-data  20   0  157568  75896  34060 S   0.0   0.9   0:00.21 php7.4                       
      4088551 www-data  20   0  380776  74264  59220 S   0.0   0.9   0:00.54 /usr/sbin/apach               
      

      If it's the Ubuntu Landscape subsystems that I'm thinking it is, I found https://blog.giantgeek.com/?p=1409 which speaks to how to remove it. Anyone have experience with doing this, is it "safe"?

      --
      Dustin Dauncey
      www.d19.ca

      nebulonN girishG 2 Replies Last reply
      0
      • d19dotcaD d19dotca

        I was just looking at top output, and sorted by memory usage. The top user is mysqld which makes sense, but the user for it is a user named landscape (had to look it up in the /etc/passwd file). I don't believe I ever saw that user before.

        I'm on a new Vultr server, so I suspect this may be part of their Ubuntu image by default. Any insight into whether I can remove this user / mysqld process from running with landscape user account? I did a quick search and seems landscape may be referring to https://landscape.canonical.com

        Trying to make sure that my server isn't using memory unnecessarily. If that process doesn't need to be running, then I'd like to kill it and prevent it from running. I noticed there is a mysqld process run by the mysql user which I assume is the one Cloudron uses?

            PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND                      
         944441 landsca+  20   0 2117548 512052  12652 S   0.7   6.3  46:07.32 mysqld                       
         948075 yellowt+  20   0 1212232 197468   7428 S   0.0   2.4   1:03.32 ruby2.7                      
         948080 yellowt+  20   0 1212232 165064   7732 S   0.0   2.0   1:04.72 ruby2.7                      
         947549 yellowt+  20   0  411812 130972   3468 S   0.0   1.6   2:18.52 ruby2.7                      
          57251 mysql     20   0 2099864 111712   4924 S   0.0   1.4  89:31.31 mysqld                       
            762 yellowt+  20   0  983452 110204  16368 S   0.0   1.4 286:15.49 node                         
         948338 yellowt+  20   0   10.9g 100668  14156 S   0.0   1.2   3:26.48 node                         
         947547 yellowt+  20   0  468668  99380   1984 S   0.0   1.2   0:21.64 ruby2.7                      
        4099406 www-data  20   0  162064  80756  34464 S   0.0   1.0   0:00.26 php                          
        3505159 yellowt+  20   0  111756  77764   6232 S   0.0   1.0   0:17.31 spamd child                  
        4101518 www-data  20   0  157532  76676  34256 S   0.0   0.9   0:00.21 php7.4                       
        4089812 www-data  20   0  386708  76260  55560 S   0.0   0.9   0:00.80 /usr/sbin/apach              
        4099413 www-data  20   0  157568  76092  34260 S   0.0   0.9   0:00.22 php                          
        4101528 www-data  20   0  157568  75896  34060 S   0.0   0.9   0:00.21 php7.4                       
        4088551 www-data  20   0  380776  74264  59220 S   0.0   0.9   0:00.54 /usr/sbin/apach               
        

        If it's the Ubuntu Landscape subsystems that I'm thinking it is, I found https://blog.giantgeek.com/?p=1409 which speaks to how to remove it. Anyone have experience with doing this, is it "safe"?

        nebulonN Offline
        nebulonN Offline
        nebulon
        Staff
        wrote on last edited by
        #2

        @d19dotca the landscape tools come out of the box with ubuntu and we at least don't actively purge them from the server during installation. It should however be safe to remove that via apt.

        Not sure how much of it came pre-installed for you on that Vultr server, but the following should catch all relevant packages:

        apt-get purge landscape-client landscape-client-ui landscape-client-ui-install landscape-common
        
        d19dotcaD 1 Reply Last reply
        1
        • nebulonN nebulon

          @d19dotca the landscape tools come out of the box with ubuntu and we at least don't actively purge them from the server during installation. It should however be safe to remove that via apt.

          Not sure how much of it came pre-installed for you on that Vultr server, but the following should catch all relevant packages:

          apt-get purge landscape-client landscape-client-ui landscape-client-ui-install landscape-common
          
          d19dotcaD Offline
          d19dotcaD Offline
          d19dotca
          wrote on last edited by d19dotca
          #3

          @nebulon Excellent, thanks! I'll try to remove those later tonight after taking a VM snapshot to be extra safe. 😉 I've never seen or noticed "landscape" user before so I guess that was already absent from previous web hosts implementations of Ubuntu.

          --
          Dustin Dauncey
          www.d19.ca

          1 Reply Last reply
          0
          • d19dotcaD d19dotca

            I was just looking at top output, and sorted by memory usage. The top user is mysqld which makes sense, but the user for it is a user named landscape (had to look it up in the /etc/passwd file). I don't believe I ever saw that user before.

            I'm on a new Vultr server, so I suspect this may be part of their Ubuntu image by default. Any insight into whether I can remove this user / mysqld process from running with landscape user account? I did a quick search and seems landscape may be referring to https://landscape.canonical.com

            Trying to make sure that my server isn't using memory unnecessarily. If that process doesn't need to be running, then I'd like to kill it and prevent it from running. I noticed there is a mysqld process run by the mysql user which I assume is the one Cloudron uses?

                PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND                      
             944441 landsca+  20   0 2117548 512052  12652 S   0.7   6.3  46:07.32 mysqld                       
             948075 yellowt+  20   0 1212232 197468   7428 S   0.0   2.4   1:03.32 ruby2.7                      
             948080 yellowt+  20   0 1212232 165064   7732 S   0.0   2.0   1:04.72 ruby2.7                      
             947549 yellowt+  20   0  411812 130972   3468 S   0.0   1.6   2:18.52 ruby2.7                      
              57251 mysql     20   0 2099864 111712   4924 S   0.0   1.4  89:31.31 mysqld                       
                762 yellowt+  20   0  983452 110204  16368 S   0.0   1.4 286:15.49 node                         
             948338 yellowt+  20   0   10.9g 100668  14156 S   0.0   1.2   3:26.48 node                         
             947547 yellowt+  20   0  468668  99380   1984 S   0.0   1.2   0:21.64 ruby2.7                      
            4099406 www-data  20   0  162064  80756  34464 S   0.0   1.0   0:00.26 php                          
            3505159 yellowt+  20   0  111756  77764   6232 S   0.0   1.0   0:17.31 spamd child                  
            4101518 www-data  20   0  157532  76676  34256 S   0.0   0.9   0:00.21 php7.4                       
            4089812 www-data  20   0  386708  76260  55560 S   0.0   0.9   0:00.80 /usr/sbin/apach              
            4099413 www-data  20   0  157568  76092  34260 S   0.0   0.9   0:00.22 php                          
            4101528 www-data  20   0  157568  75896  34060 S   0.0   0.9   0:00.21 php7.4                       
            4088551 www-data  20   0  380776  74264  59220 S   0.0   0.9   0:00.54 /usr/sbin/apach               
            

            If it's the Ubuntu Landscape subsystems that I'm thinking it is, I found https://blog.giantgeek.com/?p=1409 which speaks to how to remove it. Anyone have experience with doing this, is it "safe"?

            girishG Offline
            girishG Offline
            girish
            Staff
            wrote on last edited by
            #4

            @d19dotca Given that Cloudron already runs mysqld, it seems strange that landscape can also run mysqld on the host. Somehow, this seems unlikely to me. A better explanation might be that the mysqld you are seeing running as the "landscape" user is actually the mysql addon. Do you see any other mysqld other than the two you listed in the ps output?

            ps has no knowledge of containers. So, it will blindly map the user id in the container's user id namespace to the host namespace. This is why you see many programs above running ruby as yellowtent user (there is no yellowtent user in the containers, only on the host). In reality, what's happening is that the "id" in container happens to be same of that of yellowtent on host. Can you check "id landscape" on host and see what it outputs ?

            d19dotcaD 1 Reply Last reply
            1
            • girishG girish

              @d19dotca Given that Cloudron already runs mysqld, it seems strange that landscape can also run mysqld on the host. Somehow, this seems unlikely to me. A better explanation might be that the mysqld you are seeing running as the "landscape" user is actually the mysql addon. Do you see any other mysqld other than the two you listed in the ps output?

              ps has no knowledge of containers. So, it will blindly map the user id in the container's user id namespace to the host namespace. This is why you see many programs above running ruby as yellowtent user (there is no yellowtent user in the containers, only on the host). In reality, what's happening is that the "id" in container happens to be same of that of yellowtent on host. Can you check "id landscape" on host and see what it outputs ?

              d19dotcaD Offline
              d19dotcaD Offline
              d19dotca
              wrote on last edited by d19dotca
              #5

              @girish - I agree, it's likely some abstraction layer of some sort rather than it actually running MySQL, though what's odd is the memory usage is higher for the landscape lines than the yellowtent or mysql ones.

              Here's what I can see, if this helps. It seems it duplicates almost everything that Cloudron would be running such as MySQL, PostegreSQL, MongoDB, Dovecot, Turn, etc.

              id landscape
              uid=107(landscape) gid=113(landscape) groups=113(landscape)
              
              ps aux | head -1; ps aux | sort -rnk 4 | grep land*
              USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
              landsca+  944441  1.9  6.7 2114148 554240 ?      Sl   May26  59:12 /usr/sbin/mysqld
              landsca+  944442  0.0  0.5 617712 42208 ?        Sl   May26   0:22 node /app/code/service.js
              landsca+  945567  0.3  0.3 1907948 30932 ?       Sl   May26  10:30 mongod --config /etc/mongodb.conf --auth
              landsca+  942747  1.0  0.2 118748 22820 ?        Sl   May26  30:43 /usr/bin/python3 /usr/bin/carbon-cache --debug --config=/etc/carbon/carbon.conf start
              landsca+  877995  0.0  0.2 150432 19188 ?        Ss   17:31   0:00 postgres: 12/main: usere18fa18bb1764b25bf784d82c022b0f5 dbe18fa18bb1764b25bf784d82c022b0f5 172.18.17.160(59512) idle
              landsca+  869854  0.0  0.2 150432 18928 ?        Ss   17:25   0:00 postgres: 12/main: usere18fa18bb1764b25bf784d82c022b0f5 dbe18fa18bb1764b25bf784d82c022b0f5 172.18.17.160(53876) idle
              landsca+  955217  0.0  0.1 156708 15912 ?        Ss   May26   0:00 postgres: 12/main: usere18fa18bb1764b25bf784d82c022b0f5 dbe18fa18bb1764b25bf784d82c022b0f5 172.18.17.160(36962) idle
              landsca+  945568  0.0  0.0 887140  1648 ?        Sl   May26   0:01 node /app/code/service.js
              landsca+  943437  0.0  0.0 394036  6564 ?        Sl   May26   0:01 uwsgi --master --workers 2 --buffer-size 16384 --no-orphans --ini /etc/uwsgi/apps-enabled/graphite-uwsgi.ini
              landsca+  943435  0.0  0.0 395640  6276 ?        Sl   May26   0:00 uwsgi --master --workers 2 --buffer-size 16384 --no-orphans --ini /etc/uwsgi/apps-enabled/graphite-uwsgi.ini
              landsca+  942745  0.0  0.0  76192    80 ?        S    May26   0:06 uwsgi --master --workers 2 --buffer-size 16384 --no-orphans --ini /etc/uwsgi/apps-enabled/graphite-uwsgi.ini
              landsca+  940938  0.0  0.0 148672   812 ?        Ss   May26   0:00 postgres: 12/main: logical replication launcher   
              landsca+  940937  0.0  0.0  67336   980 ?        Ss   May26   0:04 postgres: 12/main: stats collector   
              landsca+  940936  0.0  0.0 148832  3268 ?        Ss   May26   0:01 postgres: 12/main: autovacuum launcher   
              landsca+  940935  0.0  0.0 148136  1620 ?        Ss   May26   0:02 postgres: 12/main: walwriter   
              landsca+  940934  0.0  0.0 148136  1644 ?        Ss   May26   0:01 postgres: 12/main: background writer   
              landsca+  940932  0.0  0.0 148292  6108 ?        Ss   May26   0:00 postgres: 12/main: checkpointer   
              landsca+  940656  0.0  0.0 883480  5988 ?        Sl   May26   0:00 node /app/code/service.js
              landsca+  940655  0.0  0.0 148136  3584 ?        S    May26   0:03 /usr/lib/postgresql/12/bin/postmaster --config-file=/etc/postgresql/12/main/postgresql.conf
              landsca+  934057  0.0  0.0 559180   956 ?        Ssl  May26   1:19 /usr/bin/turnserver -c /run/turnserver/turnserver.conf --pidfile /run/turnserver/turnserver.pid
              landsca+  676796  0.0  0.0 149268  7528 ?        Ss   15:04   0:00 postgres: 12/main: root postgres 127.0.0.1(49710) idle
              landsca+ 3876135  0.0  0.0 149268  4984 ?        Ss   03:04   0:00 postgres: 12/main: root postgres 127.0.0.1(52774) idle
              landsca+ 3505163  0.0  0.0  23128  1720 ?        S    May27   0:03 dovecot/auth
              landsca+ 3505162  0.0  0.0   5040  1680 ?        S    May27   0:03 dovecot/stats
              landsca+ 3505117  0.0  0.0   4380   148 ?        S    May27   0:01 dovecot/anvil
              landsca+ 2867491  0.0  0.0 149268  2816 ?        Ss   May27   0:00 postgres: 12/main: root postgres 127.0.0.1(47314) idle
              landsca+ 1867396  0.0  0.0 149268  2552 ?        Ss   May27   0:00 postgres: 12/main: root postgres 127.0.0.1(51906) idle
              

              Here's an example of the mysql memory differences (basically 554 MB used by the landscape version, and just over 100 MB by the mysql user which I assume is the one used by Cloudron?):

              ps aux | head -1; ps aux | sort -rnk 4 | grep mysql*
              USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
              landsca+  944441  1.9  6.7 2115172 554368 ?      Sl   May26  59:14 /usr/sbin/mysqld
              mysql      57251  0.5  1.2 2099864 104272 ?      Ssl  May17  93:44 /usr/sbin/mysqld
              

              --
              Dustin Dauncey
              www.d19.ca

              1 Reply Last reply
              0
              • d19dotcaD Offline
                d19dotcaD Offline
                d19dotca
                wrote on last edited by d19dotca
                #6

                Update: I removed landscape tonight. I had to run a different command because the one provided and also seen in many other articles online couldn't find two of the packages so threw this error:

                sudo apt-get purge landscape-client landscape-client-ui landscape-client-ui-install landscape-common
                Reading package lists... Done
                Building dependency tree       
                Reading state information... Done
                E: Unable to locate package landscape-client-ui
                E: Unable to locate package landscape-client-ui-install
                

                So in order for it to work, I had to run this command instead:

                sudo apt-get purge landscape-client landscape-common
                Reading package lists... Done
                Building dependency tree       
                Reading state information... Done
                Package 'landscape-client' is not installed, so not removed
                The following packages will be REMOVED:
                  landscape-common*
                0 upgraded, 0 newly installed, 1 to remove and 20 not upgraded.
                After this operation, 410 kB disk space will be freed.
                Do you want to continue? [Y/n] Y
                (Reading database ... 112984 files and directories currently installed.)
                Removing landscape-common (19.12-0ubuntu4.2) ...
                Processing triggers for man-db (2.9.1-1) ...
                (Reading database ... 112904 files and directories currently installed.)
                Purging configuration files for landscape-common (19.12-0ubuntu4.2) ...
                

                What's weird though is that after removing landscape, and rebooting the server, I still see the processes running as the same user ID (107), so I'm not sure if I really solved anything 😞

                    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND                                                                               
                  15631 yellowt+  20   0  413968 257640  22380 S   0.0   3.2   0:05.81 ruby2.7                                                                               
                  15700 yellowt+  20   0 1144740 256476  11404 S   0.0   3.1   0:00.13 ruby2.7                                                                               
                  15630 yellowt+  20   0  468764 254692  22740 S   0.0   3.1   0:05.35 ruby2.7                                                                               
                  15701 yellowt+  20   0 1144740 251736   9608 S   0.0   3.1   0:00.04 ruby2.7                                                                               
                  12150 107       20   0 2091216 240492  37868 S  28.5   2.9   0:05.46 mysqld     
                

                --
                Dustin Dauncey
                www.d19.ca

                girishG 1 Reply Last reply
                0
                • d19dotcaD d19dotca

                  Update: I removed landscape tonight. I had to run a different command because the one provided and also seen in many other articles online couldn't find two of the packages so threw this error:

                  sudo apt-get purge landscape-client landscape-client-ui landscape-client-ui-install landscape-common
                  Reading package lists... Done
                  Building dependency tree       
                  Reading state information... Done
                  E: Unable to locate package landscape-client-ui
                  E: Unable to locate package landscape-client-ui-install
                  

                  So in order for it to work, I had to run this command instead:

                  sudo apt-get purge landscape-client landscape-common
                  Reading package lists... Done
                  Building dependency tree       
                  Reading state information... Done
                  Package 'landscape-client' is not installed, so not removed
                  The following packages will be REMOVED:
                    landscape-common*
                  0 upgraded, 0 newly installed, 1 to remove and 20 not upgraded.
                  After this operation, 410 kB disk space will be freed.
                  Do you want to continue? [Y/n] Y
                  (Reading database ... 112984 files and directories currently installed.)
                  Removing landscape-common (19.12-0ubuntu4.2) ...
                  Processing triggers for man-db (2.9.1-1) ...
                  (Reading database ... 112904 files and directories currently installed.)
                  Purging configuration files for landscape-common (19.12-0ubuntu4.2) ...
                  

                  What's weird though is that after removing landscape, and rebooting the server, I still see the processes running as the same user ID (107), so I'm not sure if I really solved anything 😞

                      PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND                                                                               
                    15631 yellowt+  20   0  413968 257640  22380 S   0.0   3.2   0:05.81 ruby2.7                                                                               
                    15700 yellowt+  20   0 1144740 256476  11404 S   0.0   3.1   0:00.13 ruby2.7                                                                               
                    15630 yellowt+  20   0  468764 254692  22740 S   0.0   3.1   0:05.35 ruby2.7                                                                               
                    15701 yellowt+  20   0 1144740 251736   9608 S   0.0   3.1   0:00.04 ruby2.7                                                                               
                    12150 107       20   0 2091216 240492  37868 S  28.5   2.9   0:05.46 mysqld     
                  
                  girishG Offline
                  girishG Offline
                  girish
                  Staff
                  wrote on last edited by
                  #7

                  @d19dotca atleast you removed unused packages 🙂 the id inside the container is 107 (mysqld). you can do docker exec -ti mysql /bin/bash and do id mysql that will be 107.

                  d19dotcaD 1 Reply Last reply
                  0
                  • girishG girish

                    @d19dotca atleast you removed unused packages 🙂 the id inside the container is 107 (mysqld). you can do docker exec -ti mysql /bin/bash and do id mysql that will be 107.

                    d19dotcaD Offline
                    d19dotcaD Offline
                    d19dotca
                    wrote on last edited by d19dotca
                    #8

                    @girish said in Ubuntu 20.04 "landscape" user account running mysqld:

                    @d19dotca atleast you removed unused packages 🙂 the id inside the container is 107 (mysqld). you can do docker exec -ti mysql /bin/bash and do id mysql that will be 107.

                    Very interesting, but now I'm a bit confused, lol. I realize though this is probably a bit outside the realm of Cloudron so no worries if you can't really explain it. Here's what I've seen, if you're able to somehow make heads or tails of this, I'd really appreciate your insight:

                    When I ran the docker exec -ti mysql /bin/bash and then id mysql, you are correct, the UID is 107, as seen below from the container commands output:

                    root@mysql:/# id mysql
                    uid=107(mysql) gid=109(mysql) groups=109(mysql)
                    

                    But what I'm confused on is that the output prior was also UID 107 for the landscape user in the Ubuntu operating system (not in any containers):

                    id landscape
                    uid=107(landscape) gid=113(landscape) groups=113(landscape)
                    

                    And the MySQL user in the Ubuntu operating system is a different UID than the MySQL user in the container:

                    id mysql
                    uid=112(mysql) gid=118(mysql) groups=118(mysql)
                    

                    When I do a top -u 107 command, I get the output below which is basically the exact same services being run as it was when it was the landscape user (and remember above that the UID for landscape was also 107):

                        PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND                                                 
                      58166 107       20   0  119160  29928   3668 S   7.3   0.4   9:45.91 carbon-cache                                            
                      58266 107       20   0  400292   2572   1760 S   0.7   0.0   2:35.07 uwsgi                                                   
                      58356 107       20   0 2093932 587804  16052 S   0.7   7.2  17:28.52 mysqld                                                  
                      55356 107       20   0   76192   2700   1780 S   0.0   0.0   0:04.05 uwsgi                                                   
                      55431 107       20   0  559180   2960   1972 S   0.0   0.0   0:20.28 turnserver                                              
                      58125 107       20   0    4380    768    644 S   0.0   0.0   0:01.45 anvil                                                   
                      58129 107       20   0    5048   2148   1532 S   0.0   0.0   0:02.41 stats                                                   
                      58131 107       20   0  754016   2992   2992 S   0.0   0.0   0:00.34 node                                                    
                      58138 107       20   0  684644  11556   7104 S   0.0   0.1   0:00.26 node                                                    
                      58139 107       20   0  148136   6424   5836 S   0.0   0.1   0:00.74 postmaster                                              
                      58158 107       20   0   23124   2820   2432 S   0.0   0.0   0:02.68 auth                                                    
                      58159 107       20   0  148276   6356   5700 S   0.0   0.1   0:00.13 postmaster                                              
                      58160 107       20   0  148136   4356   3800 S   0.0   0.1   0:00.57 postmaster                                              
                      58161 107       20   0  148136   3740   3208 S   0.0   0.0   0:00.87 postmaster                                              
                      58162 107       20   0  148832   3812   3096 S   0.0   0.0   0:00.46 postmaster                                              
                      58163 107       20   0   67336   1428    740 S   0.0   0.0   0:01.03 postmaster                                              
                      58164 107       20   0  148672   1988   1380 S   0.0   0.0   0:00.02 postmaster                                              
                      58184 107       20   0 1845196  37176   8872 S   0.0   0.5   3:19.42 mongod                                                  
                      58188 107       20   0  607972  39000   8752 S   0.0   0.5   0:05.85 node                                                    
                      58265 107       20   0  388688   2500   1760 S   0.0   0.0   0:00.28 uwsgi                                                   
                      97998 107       20   0  152832  18840  15760 S   0.0   0.2   0:00.26 postmaster                                              
                     725610 107       20   0  149768   9380   8932 S   0.0   0.1   0:00.00 postmaster                                              
                    1353755 107       20   0  150720  20448  17460 S   0.0   0.3   0:00.01 postmaster                                              
                    1369625 107       20   0  150432  19640  16944 S   0.0   0.2   0:00.01 postmaster  
                    

                    Notice the above services are all what Cloudron would be running too (I think anyways), like node, mysql, mongodb, turnserver, etc.

                    When I run top | grep mysql I get both UID 107 running it alongside the actual mysql user too:

                    top | grep mysql
                      58356 107       20   0 2092908 587516  16008 S   0.8   7.2  17:33.18 mysqld                                                  
                        638 mysql     20   0 2094924 124588  10788 S   0.0   1.5   5:29.17 mysqld       
                    

                    In other words, I sort of feel like I didn't really gain any performance or reduce memory usage by removing landscape. Maybe I'm looking at it wrong though?

                    Does the above make any sense? I'm not quite following how this works. It almost seems like the landscape-common was uninstalled from the system which removed the landscape user too, but it's effectively still running just as a UID instead of any username. But am I totally misunderstanding this? lol Any insight would be awesome! 🙂

                    PS - I guess this isn’t a Cloudron item so much as an Ubuntu thing, so maybe this should be pushed to Discussion rather than Support? Totally fine with me if you’d prefer that. 🙂

                    --
                    Dustin Dauncey
                    www.d19.ca

                    1 Reply Last reply
                    0
                    • d19dotcaD Offline
                      d19dotcaD Offline
                      d19dotca
                      wrote on last edited by
                      #9

                      Interestingly, when I tempoprarily spun up a new Cloudron image using the Vultr Marketplace, and if I removed the landscape-common first thing, then it seemed the MySQL instances and everything were only seen in top with the MySQL user, no landscape or 107 seen. So I'm going to try spinning up a new permanent Cloudron server using the Cloudron app image on Vultr Marketplace and restore using Cloudron backups. I hope this will clean things up better with any luck. 🙂

                      --
                      Dustin Dauncey
                      www.d19.ca

                      1 Reply Last reply
                      0
                      • d19dotcaD Offline
                        d19dotcaD Offline
                        d19dotca
                        wrote on last edited by
                        #10

                        So I’m definitely confused. When I spin up a new image, while Landscape is installed it isn’t actively used (I can’t find any running processes with that user), but it definitely gets triggered later when Cloudron is running. I reimaged my server last night to the new Cloudron marketplace app in Vultr, removed landscape before restoring, but eventually ended up in the exact same spot of landscape uninstalled but it’s UID 107 still running (as a UID only) it’s processes as it did earlier when it was installed. It’s the weirdest thing.

                        --
                        Dustin Dauncey
                        www.d19.ca

                        1 Reply Last reply
                        0
                        • d19dotcaD Offline
                          d19dotcaD Offline
                          d19dotca
                          wrote on last edited by
                          #11

                          Okay digging into it further, I dropped into bash prompts for other containers like mail, postgresql, etc. And the main service ID in all of them is 107. So I guess this UID 107 when viewing ps or too makes sense? I’m just still confused because I’ve never noticed that behaviour before in the last two or so years of using Cloudron. Why is UID 107 chosen for all containers? How does that UID get set? Also why doesn’t the process list see that user? I swear I never had UIDs shown before in previous installs of Cloudron. I can’t wrap my head around this. Lol. But I admit I guess the landscape packages are indeed removed then, and I guess it’s a coincidence that the main user ID for each Cloudron service container is 107?

                          --
                          Dustin Dauncey
                          www.d19.ca

                          1 Reply Last reply
                          0
                          • d19dotcaD Offline
                            d19dotcaD Offline
                            d19dotca
                            wrote on last edited by d19dotca
                            #12

                            Okay so here's my theory of what's happened before, would love it if @girish could sort of sanity check this for me.

                            In previous installs, there was no UID 107 used either in Ubuntu or Cloudron services. When I tried a default install in OVH where I didn't ever see landscape before, it turns out landscape DID exist but was never seen in top because it had a UID of 113 or something like that, not 107.

                            Since in my case, the Vultr Ubuntu image has landscape as UID 107 by default, so all the container services running as UID 107 (but mysql, postreqsql, dovecot, etc) would then appear to be run by Lanscape user when it really was just a mix of different users all with the same UID of 107.

                            Thus when I removed landscape which also removed the user that was mapped to UID 107, then since the Cloudron services are coincidentally using UID 107, top output now shows user 107.

                            Curious though... where does UID 107 come from? I.e. How did Cloudron pick that UID, and why is that UID shared among all the containers but using different usernames in the containers with that UID?

                            Is my current setup best practice? Is there any issue with there only being a UID shown and no associated username? Would this be resolved if I reimaged the appliance, and then removed landscape prior to even starting the Cloudron install (last time I did it a few minutes during the install so I wonder if I did it too late), would it then create a user properly for that? I tried briefly to do that and then install Cloudron on a new smaller VPS in Vultr, and it seemed like it created MySQL user at 107 instead or something, so the MySQL user in Ubuntu was running many of the services for Cloudron. But I should probably test again.

                            I've never seen a UID before at all in my Cloudron servers which aren't associated to any username when looking at top, so I feel like this is just a very unusual circumstance in that Cloudron is running its own services with UID 107 in containers, but Ubuntu image in Vultr had UID 107 associated to Landscape, causing the confusions.

                            Hopefully the above makes sense. Would love your insight into this.

                            --
                            Dustin Dauncey
                            www.d19.ca

                            girishG 1 Reply Last reply
                            0
                            • d19dotcaD d19dotca

                              Okay so here's my theory of what's happened before, would love it if @girish could sort of sanity check this for me.

                              In previous installs, there was no UID 107 used either in Ubuntu or Cloudron services. When I tried a default install in OVH where I didn't ever see landscape before, it turns out landscape DID exist but was never seen in top because it had a UID of 113 or something like that, not 107.

                              Since in my case, the Vultr Ubuntu image has landscape as UID 107 by default, so all the container services running as UID 107 (but mysql, postreqsql, dovecot, etc) would then appear to be run by Lanscape user when it really was just a mix of different users all with the same UID of 107.

                              Thus when I removed landscape which also removed the user that was mapped to UID 107, then since the Cloudron services are coincidentally using UID 107, top output now shows user 107.

                              Curious though... where does UID 107 come from? I.e. How did Cloudron pick that UID, and why is that UID shared among all the containers but using different usernames in the containers with that UID?

                              Is my current setup best practice? Is there any issue with there only being a UID shown and no associated username? Would this be resolved if I reimaged the appliance, and then removed landscape prior to even starting the Cloudron install (last time I did it a few minutes during the install so I wonder if I did it too late), would it then create a user properly for that? I tried briefly to do that and then install Cloudron on a new smaller VPS in Vultr, and it seemed like it created MySQL user at 107 instead or something, so the MySQL user in Ubuntu was running many of the services for Cloudron. But I should probably test again.

                              I've never seen a UID before at all in my Cloudron servers which aren't associated to any username when looking at top, so I feel like this is just a very unusual circumstance in that Cloudron is running its own services with UID 107 in containers, but Ubuntu image in Vultr had UID 107 associated to Landscape, causing the confusions.

                              Hopefully the above makes sense. Would love your insight into this.

                              girishG Offline
                              girishG Offline
                              girish
                              Staff
                              wrote on last edited by girish
                              #13

                              @d19dotca I got a bit lost with all the notes, but I think you are looking for some understanding of why UIDs are not consistent ? On linux, there's only user ids (user names are just a "friendly" thing for the user which is got from /etc/passwd). In those user ids, 0 (root) is special, rest are all just the same inside the kernel. Ultimately, non-0 uids control the permissions to "files" and "processes". Also, the ids are generated dynamically. So, if you install mysql after 10 different programs, mysql user will have a different id than if you had installed it first. For the kernel and the end user, it makes no difference what the ids are. The mysql files in the file system gets the right dynamic "ids".

                              Now, for containers, they have their own uid namespace but Cloudron does not use this feature (yet). The uids only control "files" as said above and each container has it's own file system. So, the uids can be totally different inside each container (depending on how you installed programs inside it) but functionally the same (sorry, don't know how to explain this better without writing a full article 🙂 )

                              d19dotcaD 1 Reply Last reply
                              0
                              • girishG girish

                                @d19dotca I got a bit lost with all the notes, but I think you are looking for some understanding of why UIDs are not consistent ? On linux, there's only user ids (user names are just a "friendly" thing for the user which is got from /etc/passwd). In those user ids, 0 (root) is special, rest are all just the same inside the kernel. Ultimately, non-0 uids control the permissions to "files" and "processes". Also, the ids are generated dynamically. So, if you install mysql after 10 different programs, mysql user will have a different id than if you had installed it first. For the kernel and the end user, it makes no difference what the ids are. The mysql files in the file system gets the right dynamic "ids".

                                Now, for containers, they have their own uid namespace but Cloudron does not use this feature (yet). The uids only control "files" as said above and each container has it's own file system. So, the uids can be totally different inside each container (depending on how you installed programs inside it) but functionally the same (sorry, don't know how to explain this better without writing a full article 🙂 )

                                d19dotcaD Offline
                                d19dotcaD Offline
                                d19dotca
                                wrote on last edited by
                                #14

                                @girish haha, sorry, I was kind of just brain dumping as I learned more about it myself, didn't mean to make it extra confusing. 👼

                                Okay so I understood how UIDs on the Ubuntu system level work, but I guess where I'm confused is how Cloudron specifies a UID for it's main process in each container, and why are they all the same (in my case they're all UID 107 in each service container, is it always 107 even in new installs?). I think that's where it's throwing me off. Why is Cloudron using UID 107 for example in all of it's service containers running user (like mysql, dovecot, postgresql, etc)?

                                Additionally, I never have seen a UID used when looking at top before, so is there something perhaps not "registered" properly in my install?

                                As I understand it, Cloudron's containers - at least in my case - are using it's main user accounts for various services with UID 107. In Ubuntu, UID 107 happened to match the landscape user. So when I uninstalled landscape which removed the user too, now there's no system level UID 107 in Ubuntu, but I guess top sees the UID from the container as UID 107 running the process like mysql, so it outputs 107.

                                I have just never seen this before in any of my many other servers I've build with Cloudron.... so I'm confused I guess by why this is happening in this server seemingly alone, where UID 107 gets generated from in Cloudron's container services, etc.

                                Hopefully that helps a little bit clarify where my confusion is and what I'm hoping to understand better. 🙂

                                --
                                Dustin Dauncey
                                www.d19.ca

                                girishG 1 Reply Last reply
                                0
                                • d19dotcaD d19dotca

                                  @girish haha, sorry, I was kind of just brain dumping as I learned more about it myself, didn't mean to make it extra confusing. 👼

                                  Okay so I understood how UIDs on the Ubuntu system level work, but I guess where I'm confused is how Cloudron specifies a UID for it's main process in each container, and why are they all the same (in my case they're all UID 107 in each service container, is it always 107 even in new installs?). I think that's where it's throwing me off. Why is Cloudron using UID 107 for example in all of it's service containers running user (like mysql, dovecot, postgresql, etc)?

                                  Additionally, I never have seen a UID used when looking at top before, so is there something perhaps not "registered" properly in my install?

                                  As I understand it, Cloudron's containers - at least in my case - are using it's main user accounts for various services with UID 107. In Ubuntu, UID 107 happened to match the landscape user. So when I uninstalled landscape which removed the user too, now there's no system level UID 107 in Ubuntu, but I guess top sees the UID from the container as UID 107 running the process like mysql, so it outputs 107.

                                  I have just never seen this before in any of my many other servers I've build with Cloudron.... so I'm confused I guess by why this is happening in this server seemingly alone, where UID 107 gets generated from in Cloudron's container services, etc.

                                  Hopefully that helps a little bit clarify where my confusion is and what I'm hoping to understand better. 🙂

                                  girishG Offline
                                  girishG Offline
                                  girish
                                  Staff
                                  wrote on last edited by
                                  #15

                                  @d19dotca said in Ubuntu 20.04 "landscape" user account running mysqld:

                                  Okay so I understood how UIDs on the Ubuntu system level work, but I guess where I'm confused is how Cloudron specifies a UID for it's main process in each container, and why are they all the same (in my case they're all UID 107 in each service container, is it always 107 even in new installs?). I think that's where it's throwing me off. Why is Cloudron using UID 107 for example in all of it's service containers running user (like mysql, dovecot, postgresql, etc)?

                                  Ah, I think that's just a happy coincidence. We build all the containers out of the base image . So if you see docker run -ti cloudron/base:3.0.0 /bin/bash and then inspect /etc/passwd:

                                  systemd-resolve:x:103:104:systemd Resolver,,,:/run/systemd:/usr/sbin/nologin
                                  messagebus:x:104:106::/nonexistent:/usr/sbin/nologin
                                  redis:x:105:107::/var/lib/redis:/usr/sbin/nologin
                                  sshd:x:106:65534::/run/sshd:/usr/sbin/nologin
                                  cloudron:x:1000:1000:Cloudron,,,:/home/cloudron:/bin/bash
                                  

                                  It ends at 106. And the first user that gets installed after gets the UID 107. So, in the addon containers first thing we do is to install the database program which adds their own database user. So, they happen to get 107.

                                  d19dotcaD 1 Reply Last reply
                                  0
                                  • girishG girish

                                    @d19dotca said in Ubuntu 20.04 "landscape" user account running mysqld:

                                    Okay so I understood how UIDs on the Ubuntu system level work, but I guess where I'm confused is how Cloudron specifies a UID for it's main process in each container, and why are they all the same (in my case they're all UID 107 in each service container, is it always 107 even in new installs?). I think that's where it's throwing me off. Why is Cloudron using UID 107 for example in all of it's service containers running user (like mysql, dovecot, postgresql, etc)?

                                    Ah, I think that's just a happy coincidence. We build all the containers out of the base image . So if you see docker run -ti cloudron/base:3.0.0 /bin/bash and then inspect /etc/passwd:

                                    systemd-resolve:x:103:104:systemd Resolver,,,:/run/systemd:/usr/sbin/nologin
                                    messagebus:x:104:106::/nonexistent:/usr/sbin/nologin
                                    redis:x:105:107::/var/lib/redis:/usr/sbin/nologin
                                    sshd:x:106:65534::/run/sshd:/usr/sbin/nologin
                                    cloudron:x:1000:1000:Cloudron,,,:/home/cloudron:/bin/bash
                                    

                                    It ends at 106. And the first user that gets installed after gets the UID 107. So, in the addon containers first thing we do is to install the database program which adds their own database user. So, they happen to get 107.

                                    d19dotcaD Offline
                                    d19dotcaD Offline
                                    d19dotca
                                    wrote on last edited by
                                    #16

                                    @girish Ahhh okay, haha, than I guess that makes sense. What a bizarre thing, lol. So if I understand correctly, the next UID in your service containers will get UID 107 since the Docker images you base from go up to UID 106 already. And in my case, since Vultr has it's Ubuntu image using landscape as UID 107 on the operating system level, that's why it looks all weird for me. Okay, I think that makes more sense to me then. haha.

                                    Though one last question... if there was no UID 107 in the /etc/passwd file for example (which I confirmed last night is the case with OVH's instance of Ubuntu), then when Cloudron sets its containers and its user is the given UID 107 in the container, why does top not show 107 there instead since there's no system UID 107? I should investigate that a bit more, I think that's the last part of my curiosity. haha.

                                    Thanks for bearing with me and explaining everything Girish! I really appreciate it. Always love learning from the experts on these things. 🙂

                                    --
                                    Dustin Dauncey
                                    www.d19.ca

                                    girishG 2 Replies Last reply
                                    0
                                    • d19dotcaD d19dotca

                                      @girish Ahhh okay, haha, than I guess that makes sense. What a bizarre thing, lol. So if I understand correctly, the next UID in your service containers will get UID 107 since the Docker images you base from go up to UID 106 already. And in my case, since Vultr has it's Ubuntu image using landscape as UID 107 on the operating system level, that's why it looks all weird for me. Okay, I think that makes more sense to me then. haha.

                                      Though one last question... if there was no UID 107 in the /etc/passwd file for example (which I confirmed last night is the case with OVH's instance of Ubuntu), then when Cloudron sets its containers and its user is the given UID 107 in the container, why does top not show 107 there instead since there's no system UID 107? I should investigate that a bit more, I think that's the last part of my curiosity. haha.

                                      Thanks for bearing with me and explaining everything Girish! I really appreciate it. Always love learning from the experts on these things. 🙂

                                      girishG Offline
                                      girishG Offline
                                      girish
                                      Staff
                                      wrote on last edited by
                                      #17

                                      @d19dotca said in Ubuntu 20.04 "landscape" user account running mysqld:

                                      @girish Ahhh okay, haha, than I guess that makes sense. What a bizarre thing, lol. So if I understand correctly, the next UID in your service containers will get UID 107 since the Docker images you base from go up to UID 106 already. And in my case, since Vultr has it's Ubuntu image using landscape as UID 107 on the operating system level, that's why it looks all weird for me. Okay, I think that makes more sense to me then. haha.

                                      Yup, that's exactly right! I have to say I never noticed this myself, good spot 🙂

                                      1 Reply Last reply
                                      0
                                      • d19dotcaD d19dotca

                                        @girish Ahhh okay, haha, than I guess that makes sense. What a bizarre thing, lol. So if I understand correctly, the next UID in your service containers will get UID 107 since the Docker images you base from go up to UID 106 already. And in my case, since Vultr has it's Ubuntu image using landscape as UID 107 on the operating system level, that's why it looks all weird for me. Okay, I think that makes more sense to me then. haha.

                                        Though one last question... if there was no UID 107 in the /etc/passwd file for example (which I confirmed last night is the case with OVH's instance of Ubuntu), then when Cloudron sets its containers and its user is the given UID 107 in the container, why does top not show 107 there instead since there's no system UID 107? I should investigate that a bit more, I think that's the last part of my curiosity. haha.

                                        Thanks for bearing with me and explaining everything Girish! I really appreciate it. Always love learning from the experts on these things. 🙂

                                        girishG Offline
                                        girishG Offline
                                        girish
                                        Staff
                                        wrote on last edited by
                                        #18

                                        @d19dotca said in Ubuntu 20.04 "landscape" user account running mysqld:

                                        Though one last question... if there was no UID 107 in the /etc/passwd file for example (which I confirmed last night is the case with OVH's instance of Ubuntu), then when Cloudron sets its containers and its user is the given UID 107 in the container, why does top not show 107 there instead since there's no system UID 107?

                                        It totally should! What does it show if not for the raw number "107" ?

                                        1 Reply Last reply
                                        0
                                        • girishG Offline
                                          girishG Offline
                                          girish
                                          Staff
                                          wrote on last edited by
                                          #19

                                          So, in vultr this was uuidd (107) in the host image. I removed that line entirely in /etc/passwd. Then, I did ps aux | grep mysql and I got the raw 107 as expected. All the other stuff like postgres, mongo etc show raw 107 as well.

                                          107         4065  0.4  5.8 1559384 235096 ?      Sl   May27  23:31 /usr/sbin/mysqld
                                          
                                          d19dotcaD 1 Reply Last reply
                                          0
                                          • girishG girish

                                            So, in vultr this was uuidd (107) in the host image. I removed that line entirely in /etc/passwd. Then, I did ps aux | grep mysql and I got the raw 107 as expected. All the other stuff like postgres, mongo etc show raw 107 as well.

                                            107         4065  0.4  5.8 1559384 235096 ?      Sl   May27  23:31 /usr/sbin/mysqld
                                            
                                            d19dotcaD Offline
                                            d19dotcaD Offline
                                            d19dotca
                                            wrote on last edited by
                                            #20

                                            @girish Yeah that's in Vultr though and what my latest experience has been too. But I guess what I'm meaning is when I have used CLoudron on other providers like LunaNode, OVH, etc. I've never seen this issue before. I suspect it's because there is no UID 107 in the Ubuntu OS in those provider's implementations of it, but if that were the case then I'd supposedly see "107" in all my top output which I've never ever noticed before. That's what I want to try and figure out next, curiosity is getting the better of me. haha. This has been a very interesting puzzle and learning experience. 🙂

                                            --
                                            Dustin Dauncey
                                            www.d19.ca

                                            1 Reply Last reply
                                            0
                                            Reply
                                            • Reply as topic
                                            Log in to reply
                                            • Oldest to Newest
                                            • Newest to Oldest
                                            • Most Votes


                                              • Login

                                              • Don't have an account? Register

                                              • Login or register to search.
                                              • First post
                                                Last post
                                              0
                                              • Categories
                                              • Recent
                                              • Tags
                                              • Popular
                                              • Bookmarks
                                              • Search