[opensuse-factory] Apparmor fails to start on boot in Tumbleweed
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, After doing the latest updates for tumbleweed, I have noticed that it is failing to start on boot: linux-jyg:~ # systemctl status apparmor -l ● apparmor.service - LSB: AppArmor initialization Loaded: loaded (/etc/init.d/boot.apparmor) Active: inactive (dead) Docs: man:systemd-sysv-generator(8) Mar 29 12:22:46 linux-2jim systemd[1]: Job apparmor.service/start deleted to break ordering cycle starting with sysinit.target/start Mar 29 12:22:46 linux-2jim systemd[1]: Job apparmor.service/start deleted to break ordering cycle starting with basic.target/start Mar 29 12:22:46 linux-2jim systemd[1]: Job apparmor.service/start deleted to break ordering cycle starting with sysinit.target/start Mar 29 12:29:14 linux-jyg systemd[1]: Stopped LSB: AppArmor initialization. However, if I do systemctl start apparmor it will run fine. Is there some way I can determine what is causing apparmor to fail on boot? - -- Regards, Uzair Shamim -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJVGCj6AAoJEM66EOTZRH6+UQMQALWH2nmFNyrIEGhFiDjSeGaD Pvnc/WdO0e2NyhluPf0SinEtC5YlEbNvBkniHSPEcYEBU0So6N8qbLvXxJ5146HF swvZAX4DaIlE70754DldA1Onz3AAaHZaCmFs3RijhaATGhOMm/8/zxezR1xlvu7N CO/fNF0vZs32j6Cewg7Z3AIcC1/c796PK0tUep7cbSjoctTH8QFwb3kI7NWAjGFF ezH1KsS5cOkClzN8eUOKfHAV6JyKrL9CK9XHYk4bYOZlpZ+ucQi1JV4JihtO8/N5 cP+QHA92nWskEtI2PBObCJmUaMW0BOYEzposZuxIJ+EBccjuDb0cXmHDVonirnqj 6JKI9n+LHoqI74PxczzqCa3ORShQfHdabBhi108ywYapJtfwV7YdWE8E0SuDvpav Y3oRfLFQzhICB7nh1VA07SReZYaXAlyf3lvG23ZvbX2PZqJ9qIKshJnoQ5WBzWwl DcDBvmPGWP7pbgdZenfTkbUWZfSaJ3otwzhsZrPEhA2eGMpMa0HgTLURwT2FBiv6 Z+sSmocZIHlxxWTxkC8Z9skU6VLoMvQRhSGZ+kFKk5yvQCoyC2I24q8yYC6+Wo52 6gRU33DqZBhjs/WDgMZzFKU4Y8LUIHBbQIb2kRQcDrCD+uIWSYSVnYrsyBstbL80 Re93XcxK2jyvQKkQEVpr =ab3o -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 03/29/2015 12:31 PM, Uzair Shamim wrote:
Some more output: systemctl list-dependencies apparmor: - -------------------------------------- apparmor.service ● ├─system.slice ● └─basic.target ● ├─alsa-restore.service ● ├─alsa-state.service ● ├─paths.target ● ├─slices.target ● │ ├─-.slice ● │ └─system.slice ● ├─sockets.target ● │ ├─avahi-daemon.socket ● │ ├─cups.socket ● │ ├─dbus.socket ● │ ├─dm-event.socket ● │ ├─iscsid.socket ● │ ├─lvm2-lvmetad.socket ● │ ├─pcscd.socket ● │ ├─systemd-initctl.socket ● │ ├─systemd-journald-audit.socket ● │ ├─systemd-journald-dev-log.socket ● │ ├─systemd-journald.socket ● │ ├─systemd-shutdownd.socket ● │ ├─systemd-udevd-control.socket ● │ └─systemd-udevd-kernel.socket ● ├─sysinit.target │ │ └─... ● │ ├─cycle.service ● │ ├─dev-hugepages.mount ● │ ├─dev-mqueue.mount ● │ ├─dm-event.service ● │ ├─haveged.service ● │ ├─kmod-static-nodes.service ● │ ├─ldconfig.service ● │ ├─lvm2-lvmetad.service ● │ ├─plymouth-read-write.service ● │ ├─plymouth-start.service ● │ ├─proc-sys-fs-binfmt_misc.automount ● │ ├─sys-fs-fuse-connections.mount ● │ ├─sys-kernel-config.mount ● │ ├─sys-kernel-debug.mount ● │ ├─systemd-ask-password-console.path ● │ ├─systemd-binfmt.service ● │ ├─systemd-firstboot.service ● │ ├─systemd-hwdb-update.service ● │ ├─systemd-journal-catalog-update.service ● │ ├─systemd-journal-flush.service ● │ ├─systemd-journald.service ● │ ├─systemd-machine-id-commit.service ● │ ├─systemd-modules-load.service ● │ ├─systemd-random-seed.service ● │ ├─systemd-sysctl.service ● │ ├─systemd-sysusers.service ● │ ├─systemd-tmpfiles-setup-dev.service ● │ ├─systemd-tmpfiles-setup.service ● │ ├─systemd-udev-root-symlink.service ● │ ├─systemd-udev-trigger.service ● │ ├─systemd-udevd.service ● │ ├─systemd-update-done.service ● │ ├─systemd-update-utmp.service ● │ ├─systemd-vconsole-setup.service ● │ ├─cryptsetup.target ● │ │ ├─systemd-cryptsetup@cryptswap1.service ● │ │ └─systemd-cryptsetup@cryptswap2.service ● │ ├─local-fs.target ● │ │ ├─-.mount ● │ │ ├─\x2esnapshots.mount ● │ │ ├─boot-grub2-i386\x2dpc.mount ● │ │ ├─boot-grub2-x86_64\x2defi.mount ● │ │ ├─home.mount ● │ │ ├─lvm2-activation-early.service ● │ │ ├─lvm2-activation.service ● │ │ ├─mnt-storage.mount ● │ │ ├─opt.mount ● │ │ ├─srv.mount ● │ │ ├─systemd-remount-fs.service ● │ │ ├─tmp.mount ● │ │ ├─usr-local.mount ● │ │ ├─var-crash.mount ● │ │ ├─var-lib-mailman.mount ● │ │ ├─var-lib-named.mount ● │ │ ├─var-lib-pgsql.mount ● │ │ ├─var-lock.mount ● │ │ ├─var-log.mount ● │ │ ├─var-opt.mount ● │ │ ├─var-run.mount ● │ │ ├─var-spool.mount ● │ │ └─var-tmp.mount ● │ └─swap.target ● │ ├─dev-mapper-cryptswap1.swap ● │ └─dev-mapper-cryptswap2.swap ● └─timers.target ● ├─logrotate.timer ● └─systemd-tmpfiles-clean.timer - -------------------------------------- grep -ri apparmor /usr/lib/systemd/system/ /etc/systemd/ - -------------------------------------- /usr/lib/systemd/system/YaST2-Firstboot.service:After=apparmor.service local-fs.target YaST2-Second-Stage.service plymouth-start.service /usr/lib/systemd/system/YaST2-Second-Stage.service:After=apparmor.service local-fs.target plymouth-start.service /usr/lib/systemd/system/libvirtd.service:After=apparmor.service /usr/lib/systemd/system/smb.service:ExecStartPre=/usr/share/samba/update-apparmor-samba-profile - -------------------------------------- - -- Regards, Uzair Shamim - -- Regards, Uzair Shamim -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJVGDqwAAoJEM66EOTZRH6+EvoP/124UAnRhNi1uD6ftKJRYM7K upkt+H8KYW7uyURh2+o9Ad4jAWM8Q2glXaSacCz92TegPskMXJ59gv4/rvJzAogH TOiBZ0hNC1pX/ktQGlLHX/eu9imYutNHechs+PEeb8N2q99gk6FWNMghV659fFik Z3qnTRqydFLT9WxUmylXGvXjatjDutTl+gT3Zh68S3bHs+QvZT3aCG1LRMGIg6Qn FExFm5WqaM3UT0445tZOKKicxKZHb42z12P7378HTTiADVkQhKlCBnXpbw84v8BB PM9FPv9mWmQwH5JMkvZQliBsr+hzjy692zVZL2mjMwoCMITHI0Vl43U8K0Z0DPaR doP5gE4LSn/ZsZ+9AgPA9wLi4/Ew01Mrw71q8LFe/FeWdrU0oL/72lZR+jccq6RH F4YwZw1HmO/O66Qz0RHaqTvBwWYIXao+hHgyM5Jm+6aFM8CGKtNETubyHKwinV6F RoPCwsaTDpvLr5idLPm+8hJ4cApmdJXqUcTy9aAueCnMpQSa5yXqyrz/vjA+k6vX IwdluIgfODhTh1imEUPlfqEld7tjosMma9N8VBW4jNYOI9HhA9zXDCEDtVV8E9yy EhF8NCG6d8JXzSNxsKTjE2qFotLybV7SR+LNHIp4iwC+3UiDkF+lNkKWR5S/9foy UvcFhLDYnH2jHL0igIPN =yJto -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 В Sun, 29 Mar 2015 13:47:29 -0400 Uzair Shamim <usershaman@gmail.com> пишет:
Let me guess - DefaultDependencies=no is missing? Could you show systemctl show apparmor.service
systemctl list-dependencies apparmor:
This lists requires/wants and we are interested in After/Before; but it is already quite fishy, as boot.* are expected to run before sysinit.target.
-----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlUYR8cACgkQR6LMutpd94wEoQCglqptZ3jOxbQEpu1s0kFK9yKd yGcAnjq4UJP0/g8KU51KhtlEmmZCUa+2 =ATMb -----END PGP SIGNATURE----- N�����r��y隊Z)z{.���r�+�맲��r��z�^�ˬz��N�(�֜��^� ޭ隊Z)z{.���r�+��0�����Ǩ�
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 03/29/2015 02:43 PM, Andrei Borzenkov wrote:
grep "Default": DefaultDependencies=yes - ---------------- Type=forking Restart=no NotifyAccess=none RestartUSec=100ms TimeoutStartUSec=5min TimeoutStopUSec=5min WatchdogUSec=0 WatchdogTimestampMonotonic=0 StartLimitInterval=10000000 StartLimitBurst=5 StartLimitAction=none FailureAction=none PermissionsStartOnly=no RootDirectoryStartOnly=no RemainAfterExit=yes GuessMainPID=no MainPID=0 ControlPID=0 FileDescriptorStoreMax=0 StatusErrno=0 Result=success ExecMainStartTimestampMonotonic=0 ExecMainExitTimestampMonotonic=0 ExecMainPID=0 ExecMainCode=0 ExecMainStatus=0 ExecStart={ path=/etc/init.d/boot.apparmor ; argv[]=/etc/init.d/boot.apparmor start ; ignore_errors=no ; start_time=[Sun 2015-03-29 12:34:25 EDT] ; stop_time=[Sun 2015-03-29 12:34:26 EDT] ; pid=3876 ; code=exited ; status=0 } ExecReload={ path=/etc/init.d/boot.apparmor ; argv[]=/etc/init.d/boot.apparmor reload ; ignore_errors=no ; start_time=[n/a] ; stop_time=[n/a] ; pid=0 ; code=(null) ; status=0/0 } ExecStop={ path=/etc/init.d/boot.apparmor ; argv[]=/etc/init.d/boot.apparmor stop ; ignore_errors=no ; start_time=[Sun 2015-03-29 12:34:43 EDT] ; stop_time=[Sun 2015-03-29 12:34:43 EDT] ; pid=4084 ; code=exited ; status=0 } Slice=system.slice MemoryCurrent=18446744073709551615 Delegate=no CPUAccounting=no CPUShares=18446744073709551615 StartupCPUShares=18446744073709551615 CPUQuotaPerSecUSec=infinity BlockIOAccounting=no BlockIOWeight=18446744073709551615 StartupBlockIOWeight=18446744073709551615 MemoryAccounting=no MemoryLimit=18446744073709551615 DevicePolicy=auto UMask=0022 LimitCPU=18446744073709551615 LimitFSIZE=18446744073709551615 LimitDATA=18446744073709551615 LimitSTACK=18446744073709551615 LimitCORE=18446744073709551615 LimitRSS=18446744073709551615 LimitNOFILE=4096 LimitAS=18446744073709551615 LimitNPROC=31291 LimitMEMLOCK=65536 LimitLOCKS=18446744073709551615 LimitSIGPENDING=31291 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 MountFlags=0 PrivateTmp=no PrivateNetwork=no PrivateDevices=no ProtectHome=no ProtectSystem=no SameProcessGroup=no IgnoreSIGPIPE=no NoNewPrivileges=no SystemCallErrorNumber=0 RuntimeDirectoryMode=0755 KillMode=process KillSignal=15 SendSIGKILL=yes SendSIGHUP=no Id=apparmor.service Names=apparmor.service Requires=basic.target Wants=system.slice WantedBy=sysinit.target Conflicts=shutdown.target Before=shutdown.target libvirtd.service sysinit.target YaST2-Second-Stage.service YaST2-Firstboot.service After=cleanup.service basic.target system.slice systemd-journald.socket Documentation=man:systemd-sysv-generator(8) Description=LSB: AppArmor initialization LoadState=loaded ActiveState=inactive SubState=dead FragmentPath=/run/systemd/generator.late/apparmor.service SourcePath=/etc/init.d/boot.apparmor UnitFilePreset=disabled InactiveExitTimestamp=Sun 2015-03-29 12:34:25 EDT InactiveExitTimestampMonotonic=703223225 ActiveEnterTimestamp=Sun 2015-03-29 12:34:26 EDT ActiveEnterTimestampMonotonic=704613755 ActiveExitTimestamp=Sun 2015-03-29 12:34:43 EDT ActiveExitTimestampMonotonic=720971923 InactiveEnterTimestamp=Sun 2015-03-29 12:34:43 EDT InactiveEnterTimestampMonotonic=721002152 CanStart=yes CanStop=yes CanReload=yes CanIsolate=no StopWhenUnneeded=no RefuseManualStart=no RefuseManualStop=no AllowIsolate=no DefaultDependencies=yes OnFailureJobMode=replace IgnoreOnIsolate=no IgnoreOnSnapshot=no NeedDaemonReload=no JobTimeoutUSec=0 JobTimeoutAction=none ConditionResult=yes AssertResult=yes ConditionTimestamp=Sun 2015-03-29 12:34:25 EDT ConditionTimestampMonotonic=703221450 AssertTimestamp=Sun 2015-03-29 12:34:25 EDT AssertTimestampMonotonic=703221451 Transient=no - -- Regards, Uzair Shamim - -- Regards, Uzair Shamim -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJVGEh/AAoJEM66EOTZRH6+7dAP/3v5/xv13+N6RANpIWAQXo77 XLmjFnf6GMaWiRIaqfVhNkUe/8Om+U44ht/mVP3vnQH3od650TC7HnSxLKXZtPN2 v58Hm7/kQecZC94et7WyoLoqj0kW8NIblmyJQ+lbKL5iYghQ8i2kwfsNWoCDtKsv dEELzWzUkc/LOupy9BUZc8j4Wz3rMa2CGefQ8Klg9DQErO52RLnUoVVnNNgx4CpQ jz9/8Bt1BbNhgV3AaHYoevtoo3PH59SyDdEPDDpqnL2XUlv5hMKi8BDZQYxY4pCr EdH75FlwF99kaMTLTSIU1r63RlWkeH/wk0LaZt+UDGxYPR2uk8OJ4/ibqgy8XaJA vboGP0fXgKUvxv7sPkgyuLo7IWwo7WDdZlue9gQIKhChBVVmBv7ISaw1yCahGQUH tfxafKOS2Ty4gmoRzSPRPI8GRlT4LWtkFlQwzx6VWVTbNJot9AQ8B8Png+VXVt1d yxEHe4b/9zpq1E9EiFs8baMFTWPu5XMxXDyUZdX7fuzmL5qPFbUCVO9c2e01E126 7BoJEq7RvhQqwRicf0gMjfAgsrDJinBf1f6Y3pLvweuD8vKoHVZ+KdHOU+Oc35pm OWWzK683CofZf4GTYf3EzNMR77gIEkH8PvMUVoirpDGYdLdezZ08LkMWn0gNSK6x a+EDxLvD+Xg8kS1OihIW =flHU -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 В Sun, 29 Mar 2015 14:46:23 -0400 Uzair Shamim <usershaman@gmail.com> пишет:
That's obviously a problem. File bug report against systemd. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlUYTwgACgkQR6LMutpd94ws3gCgjjGhnUdK/KQ1yIMjoXuxCmuX GJ0AniyYfdhbEUbryjlRyYlzSf97NOcD =Ifpn -----END PGP SIGNATURE----- N�����r��y隊Z)z{.���r�+�맲��r��z�^�ˬz��N�(�֜��^� ޭ隊Z)z{.���r�+��0�����Ǩ�
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 03/29/2015 03:14 PM, Andrei Borzenkov wrote:
Submitted https://bugzilla.opensuse.org/show_bug.cgi?id=924830 :) - -- Regards, Uzair Shamim - -- Regards, Uzair Shamim -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJVGFDsAAoJEM66EOTZRH6+Nu4QAKeezNTjuIHa5TT7/p3Y2XSL /VwAbVZR3kuB5adf1A3Grj0WInowRJdKtNUvm1whly+9Qqe9+REL+P/dnKvnqTp3 IELurvzER1kH2goVe04QrbjZ3hBj0qH9FJP5N6uJZkLUyrCkX1ndU5144RZsfBcT gA327H1KExlDFuCU3dt0ViZ8lkNuUxNrF03AbbDy+ClhN7bShI6cdUYoCvkjH5Ob wEUtt24y1Bljn44PbBs+RjnULObPTElrWZRaQFArnWqeA9cMztrjVPxWywcc/WAk +3fXaRQ49QC91n54bbr9rGMCaRgZ/1Ilu1U6Lps5gBlg67YVwbk0SBL47fFfuY1f MFihdoizHp0m3O23GuOng9l1b9jJsDJoU2X3GSGCjfPDcFtyH46cAXZDWTrgym/k SVaxN/2n8zdFl4FVkZZNg7xzvNLCfTEKg3kGbcKRc3oEHpXaXSgvL3qbRw+jG/3R mvRPafBS0ujfuPuC0VK1FXZP22qdeNrzFX/hf1IDlfgi0HU4s97Iz/+jfVcs1Zmh yagCsrAHT1tezK9qz2N1HGQFlSKbYPt3N9+pOQ1oCMAVjAC37/tUtlrm6rrZqah/ nIuyjk4tDfVQnGZskIZUcjGiVKr+k7o9DadFfZkiHLPIdpes8nJNzb+kXusoOAel bLynXKROgHzl8RzUDUBK =Un3l -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sun, Mar 29, 2015 at 1:31 PM, Uzair Shamim <usershaman@gmail.com> wrote:
In the meanwhile, Use a native systemd unit, I use this one, since I do not run builds that have sysv compatibility enabled. [Unit] Description=AppArmor profiles DefaultDependencies=no Before=sysinit.target [Service] Type=oneshot ExecStart=/etc/init.d/boot.apparmor start ExecStop=/etc/init.d/boot.apparmor stop RemainAfterExit=yes [Install] WantedBy=multi-user.target At some point Canonical will have to fix/improve the way apparmor integrates with systemd. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 03/29/2015 03:42 PM, Cristian Rodríguez wrote:
I am reading https://wiki.archlinux.org/index.php/Systemd#Writing_unit_files and it seems to say I can take two approaches to this. Do I need to create a new unit file or just add a drop-in snippet? I dont see anything apparmor related in /usr/lib/systemd/system/. - -- Regards, Uzair Shamim -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJVGGXqAAoJEM66EOTZRH6+BqMP/Rk0OHpevCAynKR3WyfGH+8E 5mGKHESiLVNe4qhMZ2J2WyUkrmL1lHfLCdJjR494HP9aEDP23/iz4sU/H74bruOf 5Yt5ZeDZfSqEa8jxa6jhpYVRTbmuYHCOLO7dvS1le74mVDcGc+XMgvO+aR0EZUTa Cp6RZ5qT+iBsi0EW++zRVhm6BBmQB+YXe/Fi4MAVCVVx4QNhuQLr/3QMfA4uYiXY TRq1OI3jH1wVQchIdSIacwrAs32/6QFfHKA6YJzmIQ3LHiyFe9OjtkQiKcAaBy0r kqaNeH2b4sXxuLyQy7YUKeZxRtC0j72FPzBQXi/GwbUtTg7+A/wFyHkyygqyfffu P2CmmFXwzV+xZhO+gk8uVLoRJ5+CvKjKeLLcWvK7uOFCvSYBIwuw8HAxjPVR7+SV ht0GQs4vSQ0Gc0bMgQHVaVSp0oa3ZkTuZ4zGt9jg8cZOQj8mEAj7aoXKEO7EXTk0 rNfjW3s2ezrQeVMIVV52BQe8RhJLHDef65KTbVu32N/zJviChhiu95QGaknF1YdO OcuehRHeojHW0AKm5CoYrNFjC+9js+yRI3B4ar1MESO9+rxAR6fl9W1SdAxKWnHU 7sGCvHd1MghhpR4aRnTrVTzBfJBmLdQIs6bR5oJVeUhpXe1/3EqRYhR4OPGGSV+2 GsBLCYqQLPhLx4LK4xil =99yx -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
It's a sysvinit script, "systemctl cat apparmor.service" is your friend. 2015-03-29 23:52 GMT+03:00 Uzair Shamim <usershaman@gmail.com>:
-- Regards, Andrei Dziahel -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Andrei Dziahel wrote:
It's a sysvinit script, "systemctl cat apparmor.service" is your friend.
Is that a tumbleweed-only? - it does nothing on 13.2. -- Per Jessen, Zürich (12.6°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Interesting. It should say error message either if 'cat' is not supported (it should be though, I'm pretty sure 13.2 got systemd 210) or if there's no such service. 2015-03-30 10:10 GMT+03:00 Per Jessen <per@computer.org>:
-- Regards, Andrei Dziahel -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Andrei Dziahel wrote:
Yes, this system has systemd 210. I was also expecting some sort of error message - either "unknown command" or non-existent service. office34:~ # systemctl cat apparmor.service office34:~ # systemctl status apparmor.service apparmor.service - LSB: AppArmor initialization Loaded: loaded (/etc/init.d/boot.apparmor) Active: active (exited) since Tue 2015-03-17 13:16:03 CET; 1 weeks 5 days ago Mar 17 13:16:03 linux-8bgv boot.apparmor[738]: Starting AppArmor ..done Mar 17 13:16:03 linux-8bgv systemd[1]: Started LSB: AppArmor initialization. /Per -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Andrei Dziahel wrote:
Now that's officially weird. Can you file a bug?
What would you expect "systemctl cat apparmor.service" to say? apparmor is a sysvinit service - if I use systemctl cat on e.g. ntpd which is systemd native, I get proper output: office34:~ # systemctl cat ntpd.service # /usr/lib/systemd/system/ntpd.service [Unit] Description=NTP Server Daemon Documentation=man:ntpd(1) After=nss-lookup.target Conflicts=systemd-timesyncd.service Wants=network.target After=network.target [Service] Type=forking PIDFile=/var/run/ntp/ntpd.pid ExecStart=/usr/sbin/start-ntpd start RestartSec=11min Restart=always [Install] WantedBy=multi-user.target -- Per Jessen, Zürich (10.5°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Yeah, I've figured this out already. I thought sysv initscripts are handled by systemd-sysv-generator in 13.2 (as they are in recent Tumbleweed), but there's no such thing in systemd 210. 2015-03-30 14:32 GMT+03:00 Per Jessen <per@computer.org>:
-- Regards, Andrei Dziahel -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 03/29/2015 12:31 PM, Uzair Shamim wrote:
I was able to work around this by running the following (thanks Christian for the help): mkdir /etc/systemd/system/apparmor.service.d/ echo -e "[Unit]\nDefaultDependencies=no" > /etc/systemd/system/apparmor.service.d/apparmor.NoDefaultDeps.conf systemctl daemon-reload *reboot* systemctl enable apparmor *reboot* If I remove the drop in file, apparmor will not start on boot, but with it the process works fine. I also had to run enable because for some reason it was disabled even though I have never ran the command. The previous point is still true, even on reboot the service is not able to start on boot. - -- Regards, Uzair Shamim -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJVGy0qAAoJEM66EOTZRH6+ETUP/R6DuwDw+tZ+8/Yigon1F8/B nGh3lbmj7IwgEhRwyjcWe7dGW0bQUiu8VYLnSg9mhdsbcNeg/45WAq7bI1dHsJ1G bDbnPGyFcHlQcgvZXKc8xodmNCNLFmyMPoWZH66MuNfYNlZaXzhTdSv54IpXi/9k C+dMUh9TI6M/G7aTvyHP3EJEuajvs8oxNndNbg8xmreNzuTohzUm9QEdeE8yAMiq hoINSyHlQJ64SWK6n/aQIePtcKvIC0/d0r67sc2SjcLHnlYQrxoNSureCIItET54 fDcCLYJNVoaPBl1NgJKJAb1bhqT/VeOVYs5JOqE3suTHyoqaDlTjjSl8uERIJlcS t8pfXkn1TJyo3AqYna4OqOlIKg2Dh5fkez5XaG8dRHGZFCMSyEQCBmrNqCuUiRwm MubKfSjhylYE4rakvde/YVmOqSHqlXFfRhkoobZMK+tXyE0kodqqR3mThHRrq3NK U+g6eRXU0U8jC01SgJQeDOKKn78M7EhrdOMDPy4USWxjRCcNQ+EznFXnZ4Ol+xN8 WJGqQmPsRcVA+g/KQO6xNtfD6O68oABvOKmBK+1Bl6Ed/EC4hajoPkg2a5FkBGk/ ZKzH5gbYp4OWH4JMhTsyvKZlRRLQqJazEApQ8toWSG0kUgO73lKwLrSTSpGtsBPk JEWXEyv1R5sz1mXywdLb =GTjX -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 03/29/2015 12:31 PM, Uzair Shamim wrote:
I was able to work around this by running the following (thanks Christian for the help): mkdir /etc/systemd/system/apparmor.service.d/ echo -e "[Unit]\nDefaultDependencies=no" > /etc/systemd/system/apparmor.service.d/apparmor.NoDefaultDeps.conf systemctl daemon-reload *reboot* systemctl enable apparmor *reboot* If I remove the drop in file, apparmor will not start on boot, but with it the process works fine. I also had to run enable because for some reason it was disabled even though I have never ran the command. The previous point is still true, even on reboot the service is not able to start on boot. - -- Regards, Uzair Shamim -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJVGy5NAAoJEM66EOTZRH6+J18P/RIpPH2isHTf8MT+ibo43APC TluosW11CQx0n4RujDXat4XqUTUTsegETfK/Q4dRhzxZOd51jXkgt2SqGI8yGu2n wehC8GlpHK1T5s39huyot9v6WUJfAUu86UOQtE0UIERaWpZQnUqi+RVdhlpU+nqA sAnOjZ4rAKUqhaFGEh8eh8gOOCVz3z5u7ekiZXbV3l78sNdvJwgW1ugUO6Hn79gP Fh6z9v2BgNZiHNj3iWKhaMEPYU2Y4cVk0whIiDWrLcUCxBYQhsFHM23iXuTkjLIA gOIwNhvkBEXW5BXNypzCF1GLv7MQ0SyQgHfa7KvtzeBayA6vO6xOsRGvtixNt2kA WYBl/TROexQOjLqhy13TrqDt5jIY3x57xiWSM9UDEyQrVPgDCgEo8s07RWa7M+Cv aLL8wCiv2WiI+3dIKrfle2XmCvv+7EcyaJ+K+iQMEEc6LR9jPFpvUKJvAjHxZwI2 eUDPetL5hunH/+JF0tNIU98J3GhtSpTXNEjc4+CFqOnjc4Cei2zmdk7EdAqTDee9 ZVwkgOh9KpEl/ICmvW1INvHVEUc7P86zPuPWT+YfNB32T2GKpvUpXXTEJfpsDbTs kMzeJQ9CCVGZoGa/D+A0zOfXMbjmjaMTF66ZT6vhMleI+gvuXLwZvdL2zAH+XoPx h5mq55d3FEYwUuOAp6Dn =a9OL -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, Mar 31, 2015 at 8:31 PM, Uzair Shamim <usershaman@gmail.com> wrote:
I am currently working on a fix for apparmor and on removing the few remaning early boot sysvinit scripts..(this one is the only important left) fixing the systemd bug is on the shoulders of people that want this SUSE specific hack to live on and I will not waste my time with it ever again. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hello, Am Dienstag, 31. März 2015 schrieb Cristian Rodríguez:
After some delays (sorry!), I just requested your SR to security:apparmor an hour ago and added suse_version conditionals so that it only applies to Factory. Unfortunately, I found a problem when testing the packages: https://bugzilla.opensuse.org/show_bug.cgi?id=853019 is back :-( It seems the mapping of restart and try-restart to stop/start instead of passing it through to the initscript also applies to native *.service files. In other words: updating the apparmor-parser package removes the AppArmor protection from running processes :-( How can I fix this? - I'd love to simply add ExecRestart=/etc/apparmor.d/boot.apparmor reload but systemd tells me this option is unknown (would have been too easy) - I could replace the problematic %service_del_postun (which contains a "systemctl try-restart", which maps to stop/start) with a fixed version, even if I'm not too keen to carry another copy of a broken rpm macro - BTW: why doesn't %post not contain a systemctl command to restart the service? - even when the macros are fixed, this still doesn't fix manual calls of systemctl restart apparmor.service - that still removes AppArmor protection from running processes :-( Do you have an idea how I can solve this problem? I'm afraid I can't submit the package to Factory in the current state because it would remove AppArmor protection from running programs (until restarting them or rebooting), so any ideas how I can fix the above problems (ideally without adding another workaround in the package) is more than welcome!
<rant> Replacing it with core systemd bugs doesn't make it better :-( </rant> Regards, Christian Boltz -- Die SLES macht ja die gleichen Zicken, dafür kann man sich aber aufgrun der höheren Preises zumindest eines der armen Support-Würstchen greifen und erfahren: "ZEN bietet aber darüber hinaus viele Vorteile.". Grrrr. [Bernd Glueckert in suse-linux] -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hello, Am Sonntag, 12. April 2015 schrieb Cristian Rodríguez:
I'm afraid you mis-understood my mail :-( The apparmor.service you sent with your SR contains ExecReload=, and that works without problems. The problem is that "systemctl restart" and "systemctl try-restart" mean "stop, then start" - and that's a problem for AppArmor. (BTW: The boot.apparmor initscript maps restart and try-restart to reload. I need the same for systemd.) Exactly for that reason I'm asking for a way to override the behaviour of "restart". ExecRestart= would be an easy solution, but it's not (yet?) a valid option in service files. Feel free to consider this mail as feature request to implement ExecRestart= in systemd ;-) If there's a way to forbid usage of "restart" and "try-restart" (so that only "reload" is permitted), I'd accept it as workaround. Displaying an error message is still better than the current restart behaviour. Regards, Christian Boltz --
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sun, Apr 12, 2015 at 9:02 PM, Christian Boltz <opensuse@cboltz.de> wrote:
No, only RefuseManualStart= RefuseManualStop=.. however if you set any of those options, restart will be also refused (but the user will be unable to manually start or stop) This is the logic.. if ((type == JOB_START && u->refuse_manual_start) || (type == JOB_STOP && u->refuse_manual_stop) || ((type == JOB_RESTART || type == JOB_TRY_RESTART) && (u->refuse_manual_start || u->refuse_manual_stop))) return sd_bus_error_setf(error, BUS_ERROR_ONLY_BY_DEPENDENCY, "Operation refused, unit %s may be requested by dependency only.", u->id); -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hello, Am Sonntag, 12. April 2015 schrieb Cristian Rodríguez:
That doesn't sound like a solution we want to use. So we are back to "we need an ExecRestart= option". I'm sure you have good contacts with upstream systemd developers, so can you please push this upstream? (Feel free to CC me so that I can answer questions etc. directly.) Regards, Christian Boltz --
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, Apr 13, 2015 at 8:41 PM, Christian Boltz <opensuse@cboltz.de> wrote:
If you export YAST_IS_RUNNING=true export $DISABLE_RESTART_ON_UPDATE="yes" rpm scriptlets will not restart on update. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hello, Am Montag, 13. April 2015 schrieb Cristian Rodríguez:
That needs to be "export DISABLE..." without the $ sign ;-) (and the macro logic shows that the DISABLE_... is enough and I don't need to additionally export YAST_IS_RUNNING)
rpm scriptlets will not restart on update.
do that before %service_del_postun
Thanks! SR 297856 sent (which also includes updated samba profiles) Regards, Christian Boltz -- ... wenn man schon Spams und Viren nur unvollkommen filtern, wie will man dann die Windoof Experten fo^Hiltern? ;-) [Paul Foerster in suse-laptop] -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, Apr 17, 2015 at 4:44 PM, Christian Boltz <opensuse@cboltz.de> wrote:
Also needs ConditionCapability=CAP_MAC_ADMIN as an extra condtion after ConditionSecurity=apparmor Otherwise apparmor is started in containers that lack permissions to load the profiles.. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hello, Am Freitag, 17. April 2015 schrieb Cristian Rodríguez:
While I understand your goal, I'm not sure what is better: a) adding ConditionCapability which means systemd silently(?) ignores apparmor.service if CAP_MAC_ADMIN is not available b) don't do that and let apparmor.service fail I tend to b) because the admin might get a false sense of security with a) ("AppArmor is enabled, and systemctl --failed is empty, so everything works") - but if you have good arguments for a), I'll consider them ;-) Regards, Christian Boltz --
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, Apr 17, 2015 at 5:05 PM, Christian Boltz <opensuse@cboltz.de> wrote:
No, it is not silently ignored, the service is clearly marked in the status report as having a failed condition systemctl status apparmor.service ● apparmor.service - AppArmor profiles Loaded: loaded (/etc/systemd/system/apparmor.service; enabled; vendor preset: enabled) Active: inactive (dead) Condition: start condition failed at Fri 2015-04-17 17:09:54 CLST; 22s ago ConditionCapability=CAP_MAC_ADMIN was not met
b) don't do that and let apparmor.service fail
I disagree, the service is not failing.. the service *cannot work* in the target environment. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
В Mon, 13 Apr 2015 00:55:38 +0200 Christian Boltz <opensuse@cboltz.de> пишет:
How did it work before? I.e. /etc/rc.status should redirect "/etc/init.d/boot.apparmor try-restart" to systemctl anyway? So what made it different now? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hello, Am Montag, 13. April 2015 schrieb Andrei Borzenkov:
The difference is: For the initscript, apparmor.spec contains for %post: #restart_on_update boot.apparmor - but non-broken (bnc#853019) Basically I copied the %restart_on_update macro code and replaced try-restart with status && reload. I can of course do the same for %service_del_postun, but I had hoped that I don't need to mess around with standard rpm macros again. Oh, and this still doesn't help if someone manually calls systemctl restart apparmor :-( (always use "reload"!) Regards, Christian Boltz --
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (6)
-
Andrei Borzenkov
-
Andrei Dziahel
-
Christian Boltz
-
Cristian Rodríguez
-
Per Jessen
-
Uzair Shamim