Page 2 of 2 FirstFirst 12
Results 11 to 14 of 14

Thread: Shutdown not working from daemonized service

  1. #11
    Join Date
    Jan 2014
    Location
    Erlangen
    Posts
    3,846

    Default Re: Shutdown not working from daemonized service

    Quote Originally Posted by JulinaB View Post
    If I kill the daemon started by systemd and then manually start it as follows (using the same command arguments), but do so by sudoing to the same fetchmail user:

    Code:
    skylab:~ # ps -ef | grep fetch
    fetchma+  1492     1  0 12:48 ?        00:00:00 /usr/bin/fetchmail -d 60 -a -L /var/log/fetchmail -f /etc/fetchmailrc
    root      7951  7902  0 14:06 pts/0    00:00:00 grep --color=auto fetch
    skylab:~ # kill 1492
    skylab:~ # ps -ef | grep fetch
    root      7977  7902  0 14:06 pts/0    00:00:00 grep --color=auto fetch
    skylab:~ # sudo -u fetchmail /usr/bin/fetchmail -d 60 -a -L /var/log/fetchmail -f /etc/fetchmailrc
    fetchmail: warning: multidrop for 192.168.100.1 requires envelope option!
    fetchmail: warning: Do not ask for support if all mail goes to postmaster!
    skylab:~ # ps -ef | grep fetch
    fetchma+  7981     1  0 14:07 ?        00:00:00 /usr/bin/fetchmail -d 60 -a -L /var/log/fetchmail -f /etc/fetchmailrc
    root      7983  7902  0 14:07 pts/0    00:00:00 grep --color=auto fetch
    It works! So there is something about the service that is started by systemd that prevents sudo working.

    This is the /etc/systemd/system/multi-user.target.wants/fetchmail.service file.

    Code:
    [Unit]
    Description=A remote-mail retrieval utility
    After=network.target
    
    
    [Service]
    # added automatically, for details please see
    # https://en.opensuse.org/openSUSE:Security_Features#Systemd_hardening_effort
    PrivateDevices=true
    ProtectHostname=true
    ProtectClock=true
    ProtectKernelTunables=true
    ProtectKernelModules=true
    ProtectKernelLogs=true
    ProtectControlGroups=true
    RestrictRealtime=true
    # end of automatic additions
    EnvironmentFile=-/etc/sysconfig/fetchmail
    User=fetchmail
    ExecStart=/usr/lib/fetchmail-systemd-exec
    RestartSec=1
    
    
    [Install]
    WantedBy=multi-user.target
    FYI: I am using fetchmail.service for many years and it never showed unexpected behavior you are claiming to observe.
    Code:
    erlangen:~ # systemctl cat fetchmail.service                                                      
    # /usr/lib/systemd/system/fetchmail.service
    [Unit] 
    Description=A remote-mail retrieval utility 
    After=network.target 
    
    [Service] 
    # added automatically, for details please see 
    # https://en.opensuse.org/openSUSE:Security_Features#Systemd_hardening_effort 
    PrivateDevices=true 
    ProtectHostname=true 
    ProtectClock=true 
    ProtectKernelTunables=true 
    ProtectKernelModules=true 
    ProtectKernelLogs=true 
    ProtectControlGroups=true 
    RestrictRealtime=true 
    # end of automatic additions  
    EnvironmentFile=-/etc/sysconfig/fetchmail 
    User=fetchmail 
    ExecStart=/usr/libexec/fetchmail-systemd-exec 
    RestartSec=1 
    
    [Install] 
    WantedBy=multi-user.target 
    erlangen:~ #
    I suggest you first check whether a direct invocation works:
    Code:
    erlangen:~ # systemctl stop fetchmail.service        
    Warning: Stopping fetchmail.service, but it can still be activated by: 
      fetchmail.timer 
    erlangen:~ # systemctl status fetchmail.service  
    × fetchmail.service - A remote-mail retrieval utility 
         Loaded: loaded (/etc/systemd/system/fetchmail.service; static) 
         Active: failed (Result: exit-code) since Wed 2022-05-18 16:05:37 CEST; 13s ago 
    TriggeredBy:  fetchmail.timer 
        Process: 26340 ExecStart=/usr/libexec/fetchmail-systemd-exec (code=exited, status=1/FAILURE)
       Main PID: 26340 (code=exited, status=1/FAILURE) 
            CPU: 209ms 
    
    May 18 16:01:05 erlangen systemd[1]: Started A remote-mail retrieval utility. 
    May 18 16:01:05 erlangen fetchmail[26340]: fetchmail 6.4.30 Dämon wird gestartet 
    May 18 16:05:37 erlangen systemd[1]: Stopping A remote-mail retrieval utility... 
    May 18 16:05:37 erlangen fetchmail[26340]: beendet mit Signal 15 
    May 18 16:05:37 erlangen systemd[1]: fetchmail.service: Main process exited, code=exited, status=1/FAILURE
    May 18 16:05:37 erlangen systemd[1]: fetchmail.service: Failed with result 'exit-code'.
    May 18 16:05:37 erlangen systemd[1]: Stopped A remote-mail retrieval utility. 
    erlangen:~ #
    i7-6700K (2016), i5-8250U (2018), AMD Ryzen 5 3400G (2020), 5600X (2022) openSUSE Tumbleweed, KDE Plasma

  2. #12
    Join Date
    Sep 2012
    Posts
    7,690

    Default Re: Shutdown not working from daemonized service

    Quote Originally Posted by JulinaB View Post
    Just need to find out which line is the critical one.
    This is RestrictRealtime which implies NoNewPrivileges which sets no_new_privs flag on all processes started as part fo this service. no_new_privs ignores suid bit (it does not allow privilege elevation) and cannot be undone.
    Code:
    leap15:/run/systemd/system # systemctl cat testsuid.service | grep Real
    RestrictRealtime=true
    leap15:/run/systemd/system # systemctl status testsuid.service
    ● testsuid.service - A remote-mail retrieval utility
         Loaded: loaded (/run/systemd/system/testsuid.service; static)
         Active: active (running) since Wed 2022-05-18 16:40:16 MSK; 37min ago
       Main PID: 13224 (sleep)
          Tasks: 1 (limit: 1133)
         CGroup: /system.slice/testsuid.service
                 └─13224 /usr/bin/sleep 100000000
    
    
    May 18 16:40:16 leap15 systemd[1]: Started A remote-mail retrieval utility.
    leap15:/run/systemd/system # grep NoNew /proc/13224/status
    NoNewPrivs:    1
    leap15:/run/systemd/system #

  3. #13
    Join Date
    Apr 2016
    Location
    Cambridge, UK
    Posts
    302

    Default Re: Shutdown not working from daemonized service

    Quote Originally Posted by arvidjaar View Post
    This is RestrictRealtime which implies NoNewPrivs which sets no_new_privs flag on all processes started as part fo this service. no_new_privs ignores suid bit (it does not allow privilege elevation) and cannot be undone.
    Code:
    leap15:/run/systemd/system # systemctl cat testsuid.service | grep Real
    RestrictRealtime=true
    leap15:/run/systemd/system # systemctl status testsuid.service
    ● testsuid.service - A remote-mail retrieval utility
         Loaded: loaded (/run/systemd/system/testsuid.service; static)
         Active: active (running) since Wed 2022-05-18 16:40:16 MSK; 37min ago
       Main PID: 13224 (sleep)
          Tasks: 1 (limit: 1133)
         CGroup: /system.slice/testsuid.service
                 └─13224 /usr/bin/sleep 100000000
    
    
    May 18 16:40:16 leap15 systemd[1]: Started A remote-mail retrieval utility.
    leap15:/run/systemd/system # grep NoNew /proc/13224/status
    NoNewPrivs:    1
    leap15:/run/systemd/system #

    Many thanks for the explanation. I think I need to do some more reading up on systemd at some point.

  4. #14
    Join Date
    Sep 2012
    Posts
    7,690

    Default Re: Shutdown not working from daemonized service

    Quote Originally Posted by arvidjaar View Post
    This is RestrictRealtime
    Sorry, I was wrong. Almost every other Protect* or Restrict* option used here implies NoNewPrivileges. See also "man systemd.exec". And as far as I can tell it cannot be overridden by explicit NoNewPrivileges=false.

    You may consider writing PolicyKit rule to allow "systemctl shutdown" for user fetchmail instead ...

Page 2 of 2 FirstFirst 12

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •