Description of problem: A little of background: While separating mariadb namespace from mysql names we do quite easy thing for the first look: changing mysqld.service to be a symlink to mariadb.service instead of being it the opposite way. So before it looked like this until now (variant A): /usr/lib/systemd/system/mariadb.service -> mysqld.service and now it will become this (variant B): /usr/lib/systemd/system/mysqld.service -> mariadb.service We're doing so because we want to keep mysqld.service for some time for backward compatibility but will remove mysqld.service symlink at some point in the future. However, when trying to update to the new version (B), the running server (started as variant A) is not shut down properly. More concretely only mysqld_safe process is killed properly after timeout, while mysqld is not (mysqld_safe forks to mysqld during start of the daemon). I think that if the first process is able to be killed and the other one is running in the same group, it should be killed as well. Maybe systemd doesn't like "Type=simple" services to fork? In case systemd loses necessary information to kill all processes by converting the service mysqld to a symlink, how come the mysqld_safe is killed properly? The "Steps to reproduce" bellow basically imitate what is going to happen during F19->F20 upgrade in case we change mariadb to variant (B) in F20. Version-Release number of selected component (if applicable): # rpm -q systemd mariadb systemd-204-9.fc19.x86_64 mariadb-5.5.32-8.fc19.x86_64 How reproducible: every-time Steps to Reproduce: 1. Install mariadb and have mysqld.service installed (no other service file) 2. # cd /usr/lib/systemd/system/ 3. # mv mysqld.service mariadb.service 4. # ln -s mariadb.service mysqld.service 5. # systemctl daemon-reload 6. # systemctl stop mysqld.service Actual results: "systemctl stop ..." command timeouts and after timeout only mysqld_safe is killed properly, while mysqld is kept running Expected results: both processes (mysqld_safe and mysqld) are killed Additional info: In case this is not able to be fixed, is there any work-around we can use? I have only idea to explicitly stop mysqld before upgrading, which should then allow to upgrade cleanly.
Can you please post here output of systemctl status and show for both of them?
Sure, here you are with ps output before stopping and after stopping (mysqld_safe process was killed, but mysqld not): # ps -A|grep mysql 10810 ? 00:00:00 mysqld_safe 10967 ? 00:00:00 mysqld # systemctl stop mysqld.service # systemctl status mysqld.service mariadb.service - MariaDB database server Loaded: loaded (/usr/lib/systemd/system/mariadb.service; disabled) Active: failed (Result: signal) since Mon 2013-09-02 15:54:57 CEST; 2min 22s ago Main PID: 10810 (code=killed, signal=KILL) CGroup: name=systemd:/system/mariadb.service # systemctl show mysqld.service Id=mariadb.service Names=mysqld.service mariadb.service Requires=basic.target Conflicts=shutdown.target Before=shutdown.target After=syslog.target network.target systemd-journald.socket basic.target Description=MariaDB database server LoadState=loaded ActiveState=failed SubState=failed FragmentPath=/usr/lib/systemd/system/mariadb.service UnitFileState=disabled InactiveExitTimestamp=Mon 2013-09-02 15:41:30 CEST InactiveExitTimestampMonotonic=2102655249956 ActiveEnterTimestamp=Mon 2013-09-02 15:41:32 CEST ActiveEnterTimestampMonotonic=2102657351853 ActiveExitTimestamp=Mon 2013-09-02 15:49:57 CEST ActiveExitTimestampMonotonic=2103162471569 InactiveEnterTimestamp=Mon 2013-09-02 15:54:57 CEST InactiveEnterTimestampMonotonic=2103462474182 CanStart=yes CanStop=yes CanReload=no CanIsolate=no StopWhenUnneeded=no RefuseManualStart=no RefuseManualStop=no AllowIsolate=no DefaultDependencies=yes OnFailureIsolate=no IgnoreOnIsolate=no IgnoreOnSnapshot=no NeedDaemonReload=no JobTimeoutUSec=0 ConditionTimestamp=Mon 2013-09-02 15:41:30 CEST ConditionTimestampMonotonic=2102655248507 ConditionResult=yes Type=simple Restart=no NotifyAccess=none RestartUSec=100ms TimeoutUSec=5min TimeoutStartUSec=5min TimeoutStopUSec=5min WatchdogUSec=0 WatchdogTimestampMonotonic=0 StartLimitInterval=10000000 StartLimitBurst=5 StartLimitAction=none ExecStartPre={ path=/usr/libexec/mysqld-prepare-db-dir ; argv[]=/usr/libexec/mysqld-prepare-db-dir %n ; ignore_errors=no ; start_time=[n/a] ; stop_time=[n/a] ; pid=0 ; code=(null) ; status=0/0 } ExecStart={ path=/usr/bin/mysqld_safe ; argv[]=/usr/bin/mysqld_safe --basedir=/usr ; ignore_errors=no ; start_time=[n/a] ; stop_time=[n/a] ; pid=0 ; code=(null) ; status=0/0 } ExecStartPost={ path=/usr/libexec/mysqld-wait-ready ; argv[]=/usr/libexec/mysqld-wait-ready $MAINPID ; ignore_errors=no ; start_time=[n/a] ; stop_time=[n/a] ; pid=0 ; code=(null) ; status=0/0 } PermissionsStartOnly=no RootDirectoryStartOnly=no RemainAfterExit=no GuessMainPID=yes MainPID=0 ControlPID=0 Result=signal UMask=0022 LimitCPU=18446744073709551615 LimitFSIZE=18446744073709551615 LimitDATA=18446744073709551615 LimitSTACK=18446744073709551615 LimitCORE=18446744073709551615 LimitRSS=18446744073709551615 LimitNOFILE=4096 LimitAS=18446744073709551615 LimitNPROC=62150 LimitMEMLOCK=65536 LimitLOCKS=18446744073709551615 LimitSIGPENDING=62150 LimitMSGQUEUE=819200 LimitNICE=0 LimitRTPRIO=0 LimitRTTIME=18446744073709551615 OOMScoreAdjust=0 Nice=0 IOScheduling=0 CPUSchedulingPolicy=0 CPUSchedulingPriority=0 TimerSlackNSec=50000 CPUSchedulingResetOnFork=no NonBlocking=no StandardInput=null StandardOutput=journal StandardError=inherit TTYReset=no TTYVHangup=no TTYVTDisallocate=no SyslogPriority=30 SyslogLevelPrefix=yes SecureBits=0 CapabilityBoundingSet=18446744073709551615 User=mysql Group=mysql MountFlags=0 PrivateTmp=yes PrivateNetwork=no SameProcessGroup=no ControlGroupModify=no ControlGroupPersistent=no IgnoreSIGPIPE=yes NoNewPrivileges=no KillMode=control-group KillSignal=15 SendSIGKILL=yes ExecMainStartTimestamp=Mon 2013-09-02 15:41:30 CEST ExecMainStartTimestampMonotonic=2102655308675 ExecMainExitTimestamp=Mon 2013-09-02 15:41:30 CEST ExecMainExitTimestampMonotonic=2102655308675 ExecMainPID=10810 ExecMainCode=2 ExecMainStatus=9 DefaultControlGroup=name=systemd:/system/mariadb.service ControlGroups=cpu:/system/mariadb.service name=systemd:/system/mariadb.service # ps -A|grep mysql 10967 ? 00:00:00 mysqld
This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 19 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle. Changing version to '22'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22
This bug is no longer reproducible from F22 onward.