Re: [systemd-devel] How do I find out why a service was started? (systemd-tmpfiles-setup failed in container)

2015-07-14 Thread Johannes Ernst
 On Jul 3, 2015, at 4:01, Lennart Poettering lenn...@poettering.net wrote:
 
 On Wed, 01.07.15 13:50, Johannes Ernst (johannes.er...@gmail.com 
 mailto:johannes.er...@gmail.com) wrote:
 
 My container is degraded because systemd-tmpfiles-setup.service
 failed. My understanding is that it should not run in the container
 anyway. (Right?)
 
 It should run in a container; its purpose is both necessary, and I
 don't see why a container would have any difficulty with it. It runs
 just fine in both system and even unprivileged user containers here.
 
 Here is what fails:
 
 # /usr/bin/systemd-tmpfiles --create --remove --boot --exclude-prefix=/dev
 Failed to create file /sys/devices/system/cpu/microcode/reload: Read-only 
 file system
 
 We should probably handle this case in a nicer way, and downgrade
 EROFS error for cases like this.

Should I file this as an issue, so it won’t get lost, or do you keep track of 
this kind of thing somewhere else? 

Cheers,


Johannes.


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] How do I find out why a service was started? (systemd-tmpfiles-setup failed in container)

2015-07-06 Thread Johannes Ernst

 On Jul 3, 2015, at 4:01, Lennart Poettering lenn...@poettering.net wrote:
 
 On Wed, 01.07.15 13:50, Johannes Ernst (johannes.er...@gmail.com 
 mailto:johannes.er...@gmail.com) wrote:
 
 Hey Martin,
 
 thanks, but:
 
 My container is degraded because systemd-tmpfiles-setup.service
 failed. My understanding is that it should not run in the container
 anyway. (Right?)
 
 It should run in a container; its purpose is both necessary, and I
 don't see why a container would have any difficulty with it. It runs
 just fine in both system and even unprivileged user containers here.
 
 Here is what fails:
 
 # /usr/bin/systemd-tmpfiles --create --remove --boot --exclude-prefix=/dev
 Failed to create file /sys/devices/system/cpu/microcode/reload: Read-only 
 file system
 
 We should probably handle this case in a nicer way, and downgrade
 EROFS error for cases like this.
 
 Can you let me know which tmpfiles snippet actually adds this line,
 and what precisely it contains? i.e. look in /usr/lib/tmpfiles.d/ for
 the file that mentions /sys/devices/system/cpu/microcode/reload, and
 figure out the package name it is shipped with, and paste the contents
 of the file here.

/usr/lib/tmpfiles.d/linux-firmware.conf is owned by linux-firmware 
20150527.3161bfa-1

Content:

w /sys/devices/system/cpu/microcode/reload - - - - 1


 
 Thanks,
 
 Lennart
 
 -- 
 Lennart Poettering, Red Hat

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] How do I find out why a service was started? (systemd-tmpfiles-setup failed in container)

2015-07-03 Thread Lennart Poettering
On Wed, 01.07.15 13:50, Johannes Ernst (johannes.er...@gmail.com) wrote:

 Hey Martin,
 
 thanks, but:
 
  My container is degraded because systemd-tmpfiles-setup.service
  failed. My understanding is that it should not run in the container
  anyway. (Right?)
  
  It should run in a container; its purpose is both necessary, and I
  don't see why a container would have any difficulty with it. It runs
  just fine in both system and even unprivileged user containers here.
 
 Here is what fails:
 
 # /usr/bin/systemd-tmpfiles --create --remove --boot --exclude-prefix=/dev
 Failed to create file /sys/devices/system/cpu/microcode/reload: Read-only 
 file system

We should probably handle this case in a nicer way, and downgrade
EROFS error for cases like this.

Can you let me know which tmpfiles snippet actually adds this line,
and what precisely it contains? i.e. look in /usr/lib/tmpfiles.d/ for
the file that mentions /sys/devices/system/cpu/microcode/reload, and
figure out the package name it is shipped with, and paste the contents
of the file here.

Thanks,

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] How do I find out why a service was started? (systemd-tmpfiles-setup failed in container)

2015-07-02 Thread Colin Guthrie
Johannes Ernst wrote on 02/07/15 00:20:
 
 On Jul 1, 2015, at 14:59, Michael Biebl mbi...@gmail.com
 mailto:mbi...@gmail.com wrote:

 2015-07-01 22:50 GMT+02:00 Johannes Ernst johannes.er...@gmail.com
 mailto:johannes.er...@gmail.com:
 Hey Martin,

 thanks, but:

 My container is degraded because systemd-tmpfiles-setup.service
 failed. My understanding is that it should not run in the container
 anyway. (Right?)

 It should run in a container; its purpose is both necessary, and I
 don't see why a container would have any difficulty with it. It runs
 just fine in both system and even unprivileged user containers here.

 Here is what fails:

 # /usr/bin/systemd-tmpfiles --create --remove --boot
 --exclude-prefix=/dev
 Failed to create file /sys/devices/system/cpu/microcode/reload:
 Read-only file system

 Which packages ships that tmpfiles snippet? This is not coming from
 systemd itself.
 
 https://github.com/systemd/systemd/blob/master/units/systemd-tmpfiles-setup.service.in
 

Michael meant which snippet file (/{usr/lib,etc}/tmpfiles.d/*) defines
the /sys/devices/system/cpu/microcode/reload file and which package
ships it, not the actual .service file itself.


Col


-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] How do I find out why a service was started? (systemd-tmpfiles-setup failed in container)

2015-07-01 Thread Johannes Ernst
My container is degraded because systemd-tmpfiles-setup.service failed. My 
understanding is that it should not run in the container anyway. (Right?)

How do I find out why it was started?

This is probably a noob question.

Thanks,



Johannes.

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] How do I find out why a service was started? (systemd-tmpfiles-setup failed in container)

2015-07-01 Thread Johannes Ernst
Hey Martin,

thanks, but:

 My container is degraded because systemd-tmpfiles-setup.service
 failed. My understanding is that it should not run in the container
 anyway. (Right?)
 
 It should run in a container; its purpose is both necessary, and I
 don't see why a container would have any difficulty with it. It runs
 just fine in both system and even unprivileged user containers here.

Here is what fails:

# /usr/bin/systemd-tmpfiles --create --remove --boot --exclude-prefix=/dev
Failed to create file /sys/devices/system/cpu/microcode/reload: Read-only file 
system

This is systemd 221 on Arch in a container straight from the man page, just in 
case I screwed up my own, but the behavior is the same.

# pacstrap -c -d $(pwd)/arch-tree base
# systemd-nspawn -bD $(pwd)/arch-tree/

 How do I find out why it was started?
 
 $ systemctl list-dependencies --reverse systemd-tmpfiles-setup.service
 systemd-tmpfiles-setup.service
 ● └─sysinit.target

This analyzes the static dependencies (and does indeed solve my problem here, 
thanks! I had missed the —reverse flag),
but I was wondering whether there was something more dynamic that could tell me 
something like:

a.service started, because b.service required it
b.service started because user foobar started it

 
 systemctl status systemd-tmpfiles-setup.service will say that it's
 statically enabled, and the list-dependencies says where. I. e. you
 should have a symlink
 /usr/lib/systemd/system/sysinit.target.wants/systemd-tmpfiles-setup.service
 
 (could also be in /lib/systemd/, depending on your distro)
 
 Martin
 
 -- 
 Martin Pitt| http://www.piware.de
 Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] How do I find out why a service was started? (systemd-tmpfiles-setup failed in container)

2015-07-01 Thread Martin Pitt
Hey Johannes,

Johannes Ernst [2015-07-01 11:02 -0700]:
 My container is degraded because systemd-tmpfiles-setup.service
 failed. My understanding is that it should not run in the container
 anyway. (Right?)

It should run in a container; its purpose is both necessary, and I
don't see why a container would have any difficulty with it. It runs
just fine in both system and even unprivileged user containers here.

 How do I find out why it was started?

$ systemctl list-dependencies --reverse systemd-tmpfiles-setup.service
systemd-tmpfiles-setup.service
● └─sysinit.target

systemctl status systemd-tmpfiles-setup.service will say that it's
statically enabled, and the list-dependencies says where. I. e. you
should have a symlink
/usr/lib/systemd/system/sysinit.target.wants/systemd-tmpfiles-setup.service

(could also be in /lib/systemd/, depending on your distro)

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] How do I find out why a service was started? (systemd-tmpfiles-setup failed in container)

2015-07-01 Thread Michael Biebl
2015-07-01 22:50 GMT+02:00 Johannes Ernst johannes.er...@gmail.com:
 Hey Martin,

 thanks, but:

 My container is degraded because systemd-tmpfiles-setup.service
 failed. My understanding is that it should not run in the container
 anyway. (Right?)

 It should run in a container; its purpose is both necessary, and I
 don't see why a container would have any difficulty with it. It runs
 just fine in both system and even unprivileged user containers here.

 Here is what fails:

 # /usr/bin/systemd-tmpfiles --create --remove --boot --exclude-prefix=/dev
 Failed to create file /sys/devices/system/cpu/microcode/reload: Read-only 
 file system

Which packages ships that tmpfiles snippet? This is not coming from
systemd itself.

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] How do I find out why a service was started? (systemd-tmpfiles-setup failed in container)

2015-07-01 Thread Johannes Ernst

 On Jul 1, 2015, at 14:59, Michael Biebl mbi...@gmail.com wrote:
 
 2015-07-01 22:50 GMT+02:00 Johannes Ernst johannes.er...@gmail.com 
 mailto:johannes.er...@gmail.com:
 Hey Martin,
 
 thanks, but:
 
 My container is degraded because systemd-tmpfiles-setup.service
 failed. My understanding is that it should not run in the container
 anyway. (Right?)
 
 It should run in a container; its purpose is both necessary, and I
 don't see why a container would have any difficulty with it. It runs
 just fine in both system and even unprivileged user containers here.
 
 Here is what fails:
 
 # /usr/bin/systemd-tmpfiles --create --remove --boot --exclude-prefix=/dev
 Failed to create file /sys/devices/system/cpu/microcode/reload: Read-only 
 file system
 
 Which packages ships that tmpfiles snippet? This is not coming from
 systemd itself.

https://github.com/systemd/systemd/blob/master/units/systemd-tmpfiles-setup.service.in
 
https://github.com/systemd/systemd/blob/master/units/systemd-tmpfiles-setup.service.in


 
 -- 
 Why is it that all of the instruments seeking intelligent life in the
 universe are pointed away from Earth?

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel