-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 03/29/2015 02:43 PM, Andrei Borzenkov wrote:

В Sun, 29 Mar 2015 13:47:29 -0400 Uzair Shamim пишет:

...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256

...

On 03/29/2015 12:31 PM, Uzair Shamim wrote:

...

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

Let me guess - DefaultDependencies=no is missing? Could you show

systemctl show apparmor.service

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: SHA256 On 03/29/2015 03:14 PM, Andrei Borzenkov wrote:

В Sun, 29 Mar 2015 14:46:23 -0400 Uzair Shamim пишет:

...

...

...

...

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

Let me guess - DefaultDependencies=no is missing? Could you show

systemctl show apparmor.service

...

grep "Default": DefaultDependencies=yes

...

- ----------------

...

Before=sysinit.target After=basic.target

That's obviously a problem. File bug report against systemd. N�����r��y隊Z)z{.���r�+�맲��r��z�^�ˬz��N�(�֜��^� ޭ隊 Z)z{.���r�+��0�����Ǩrg==

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

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 03/29/2015 03:42 PM, Cristian Rodríguez wrote:

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?

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.

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

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

Andrei Dziahel wrote:

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.

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 :

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

-- Regards, Andrei Dziahel -- 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:

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)

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!

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.

<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:

On Sun, Apr 12, 2015 at 7:55 PM, Christian Boltz wrote:

...

How can I fix this? - I'd love to simply add

ExecRestart=/etc/apparmor.d/boot.apparmor reload

Ooops.. I made a thinko.. it is ExecReload= that will do what you want.

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 --

which camera is this? Marcus, this is my bug :) [Marcus Meissner and Stephan Kulow in https://bugzilla.novell.com/show_bug.cgi?id=217731]

-- 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:

...

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. No, only RefuseManualStart= RefuseManualStop=.. however if you set any of

On Sun, Apr 12, 2015 at 9:02 PM, Christian Boltz wrote: those options, restart will be also refused (but the user will be unable to manually start or stop) This is the logic..

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 --

How deep can subprojects be nested? I think we have no limit of deepness, at least no one reached it until now ;) [> Paul Elliott and Adrian Schröter in opensuse-buildservice]

-- 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 9:02 PM, Cristian Rodríguez wrote:

If you export YAST_IS_RUNNING=true export $DISABLE_RESTART_ON_UPDATE="yes"

rpm scriptlets will not restart on update.

do that before %service_del_postun -- 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 wrote:

Hello,

Am Montag, 13. April 2015 schrieb Cristian Rodríguez:

...

On Mon, Apr 13, 2015 at 9:02 PM, Cristian Rodríguez wrote:

...

If you export YAST_IS_RUNNING=true export $DISABLE_RESTART_ON_UPDATE="yes"

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)

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

On Fri, Apr 17, 2015 at 5:05 PM, Christian Boltz wrote:

Hello,

Am Freitag, 17. April 2015 schrieb Cristian Rodríguez:

...

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..

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

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

Hello, Am Montag, 13. April 2015 schrieb Andrei Borzenkov:

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?

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 --

Gibt es eine CPU Beschränkung bei der Prof. Version? Die gibt es tatsaechlich, hat aber nichts mit der Professional Version zu tun, sondern mit dem Linux-Kernel selbst. Das Limit liegt aber weit jenseits von dem, was für Dich vermutlich relevant und bezahlbar ist ;-) [> Robert und Thomas Hertweck in suse-linux]

-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org