* [Buildroot] systemd: write-up and packaging questions
@ 2014-10-12 17:59 André Erdmann
2014-10-12 19:12 ` Maxime Hadjinlian
2014-10-15 18:24 ` Arnout Vandecappelle
0 siblings, 2 replies; 9+ messages in thread
From: André Erdmann @ 2014-10-12 17:59 UTC (permalink / raw)
To: buildroot
Hi,
Some of the issues pointed out below may be already known, but I couldn't
find any report on this, so I'd like to share my experience with setting up a
systemd-based system that does a little bit more than bringing up a console ;)
Use case was tvheadend with avahi and nfs (+ dropbear etc.), running on a
DreamPlug. Overall it works great, but requires some post-build actions:
* installation of additional service files
(I'll propose patches for them sooner or later)
* changes to the default rootfs skeleton
* optional: removal of /etc/init.d etc.
Filesystem Layout
=================
There are some issues with the default rootfs skeleton.
For example, systemd-hostnamed fails to start with the error message
"file exists", likely related to symlinks pointing to /tmp (/run, /var/...).
After some trial-and-error I've figured out that both /run and /var/tmp
symlinks must be replaced with real directories, and that it needs to be done
before booting systemd (at build/image creation time or in initramfs/initrd).
So, the minimum amount of necessary changes seems to be:
* create /run as directory
and make /var/run->../run, /var/lock->run/lock link to it;
/run gets automatically mounted on boot
* create /var/tmp as directory;
needs manual mount setup (fstab or .mount unit)
* /var/lib/dbus is then a dead link pointing to /tmp/dbus,
not sure if /run/dbus would be the correct link dest
Unit Files
==========
This section is mostly about packaging guidelines,
the manual doesn't answer the questions below.
Installation
------------
systemd's libdir is /lib/system.
Most unit files (.service et al) are installed to /etc/systemd/system,
systemd's own unit files are installed to /lib/systemd/system and some
packages(*) install their files to /usr/lib/systemd/system, which is rather
confusing. Either dir works (search order is /etc > /lib > /usr/lib),
but what's the recommended location?
I'd prefer to have them installed in one dir (systemd's libdir).
(*) grepping yields nginx and connman
Auto-Enabling
-------------
Most packages enable their unit files by default(*), others don't.
Example: lighttpd gets enabled, nginx does not.
Is there any policy for when [not] to enable services?
(*) "ln -s <unit> /etc/systemd/system/<target>.target.wants/<unit>"
Maybe it'd make sense to introduce some SYSTEMD_ variables so that
packages don't have to hardcode/guess systemd file paths, for example:
* SYSTEMD_LIBDIR (= /lib/systemd)
* SYSTEMD_UNITDIR (= $(SYSTEMD_LIBDIR)/system)
* SYSTEMD_CONFDIR (= /etc/systemd)
* SYSTEMD_UNITCONFDIR (= $(SYSTEMD_CONFDIR)/system)
* relpath from <confdir> to <libdir> (= ../..$(SYSTEMD_LIBDIR))
* relpath from <confdir>/system to <libdir>/system (= ../../$(SYSTEMD_UNITDIR))
Bonus: export these variables to post-build scripts
--
Andr?
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Buildroot] systemd: write-up and packaging questions
2014-10-12 17:59 [Buildroot] systemd: write-up and packaging questions André Erdmann
@ 2014-10-12 19:12 ` Maxime Hadjinlian
2014-10-17 8:21 ` Paassen, Hiram van
2014-10-15 18:24 ` Arnout Vandecappelle
1 sibling, 1 reply; 9+ messages in thread
From: Maxime Hadjinlian @ 2014-10-12 19:12 UTC (permalink / raw)
To: buildroot
Hi Andr?, All
On Sun, Oct 12, 2014 at 7:59 PM, Andr? Erdmann <dywi@mailerd.de> wrote:
> Hi,
>
> Some of the issues pointed out below may be already known, but I couldn't
> find any report on this, so I'd like to share my experience with setting up a
> systemd-based system that does a little bit more than bringing up a console ;)
> Use case was tvheadend with avahi and nfs (+ dropbear etc.), running on a
> DreamPlug. Overall it works great, but requires some post-build actions:
>
> * installation of additional service files
> (I'll propose patches for them sooner or later)
> * changes to the default rootfs skeleton
> * optional: removal of /etc/init.d etc.
I have a patch that I need to send that does just that.
>
>
> Filesystem Layout
> =================
>
> There are some issues with the default rootfs skeleton.
> For example, systemd-hostnamed fails to start with the error message
> "file exists", likely related to symlinks pointing to /tmp (/run, /var/...).
> After some trial-and-error I've figured out that both /run and /var/tmp
> symlinks must be replaced with real directories, and that it needs to be done
> before booting systemd (at build/image creation time or in initramfs/initrd).
>
> So, the minimum amount of necessary changes seems to be:
> * create /run as directory
> and make /var/run->../run, /var/lock->run/lock link to it;
> /run gets automatically mounted on boot
> * create /var/tmp as directory;
> needs manual mount setup (fstab or .mount unit)
> * /var/lib/dbus is then a dead link pointing to /tmp/dbus,
> not sure if /run/dbus would be the correct link dest
>
>
> Unit Files
> ==========
>
> This section is mostly about packaging guidelines,
> the manual doesn't answer the questions below.
You're right, the manual is really in need of update on that subject.
But there are some pending changes for which I already have patch that
I am currently finishing.
>
> Installation
> ------------
>
> systemd's libdir is /lib/system.
> Most unit files (.service et al) are installed to /etc/systemd/system,
> systemd's own unit files are installed to /lib/systemd/system and some
> packages(*) install their files to /usr/lib/systemd/system, which is rather
> confusing. Either dir works (search order is /etc > /lib > /usr/lib),
> but what's the recommended location?
If I'm reading the FHS correctly, /usr/lib/systemd/ would the the
targets and what nots for systemd itself, and so everything in /etc is
hosts specific so I would keep everything installed by our packages in
/etc/systemd/system.
> I'd prefer to have them installed in one dir (systemd's libdir).
>
> (*) grepping yields nginx and connman
>
>
> Auto-Enabling
> -------------
>
> Most packages enable their unit files by default(*), others don't.
> Example: lighttpd gets enabled, nginx does not.
> Is there any policy for when [not] to enable services?
>
> (*) "ln -s <unit> /etc/systemd/system/<target>.target.wants/<unit>"
IMHO, we should enable by default for the moment. The users can
disable everything through a post-build script.
A better way to handle that, would be, as Samuel Martin said on IRC,
to have some infra like the users table to handle what you want to be
enabled or not.
But that may needs an RFC so we could start discussing this.
>
>
> Maybe it'd make sense to introduce some SYSTEMD_ variables so that
> packages don't have to hardcode/guess systemd file paths, for example:
> * SYSTEMD_LIBDIR (= /lib/systemd)
> * SYSTEMD_UNITDIR (= $(SYSTEMD_LIBDIR)/system)
> * SYSTEMD_CONFDIR (= /etc/systemd)
> * SYSTEMD_UNITCONFDIR (= $(SYSTEMD_CONFDIR)/system)
> * relpath from <confdir> to <libdir> (= ../..$(SYSTEMD_LIBDIR))
> * relpath from <confdir>/system to <libdir>/system (= ../../$(SYSTEMD_UNITDIR))
>
> Bonus: export these variables to post-build scripts
Yes, it would be really nice.
>
>
> --
> Andr?
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Buildroot] systemd: write-up and packaging questions
2014-10-12 17:59 [Buildroot] systemd: write-up and packaging questions André Erdmann
2014-10-12 19:12 ` Maxime Hadjinlian
@ 2014-10-15 18:24 ` Arnout Vandecappelle
2014-10-17 6:32 ` André Erdmann
1 sibling, 1 reply; 9+ messages in thread
From: Arnout Vandecappelle @ 2014-10-15 18:24 UTC (permalink / raw)
To: buildroot
On 12/10/14 19:59, Andr? Erdmann wrote:
> Hi,
>
> Some of the issues pointed out below may be already known, but I couldn't
> find any report on this, so I'd like to share my experience with setting up a
> systemd-based system that does a little bit more than bringing up a console ;)
> Use case was tvheadend with avahi and nfs (+ dropbear etc.), running on a
> DreamPlug. Overall it works great, but requires some post-build actions:
>
> * installation of additional service files
> (I'll propose patches for them sooner or later)
Sooner would be good, because we've had several other reports of systemd not
working.
> * changes to the default rootfs skeleton
Actually this is the one that should be done soon.
> * optional: removal of /etc/init.d etc.
Someone is working on that.
>
>
> Filesystem Layout
> =================
>
> There are some issues with the default rootfs skeleton.
> For example, systemd-hostnamed fails to start with the error message
> "file exists", likely related to symlinks pointing to /tmp (/run, /var/...).
> After some trial-and-error I've figured out that both /run and /var/tmp
> symlinks must be replaced with real directories, and that it needs to be done
> before booting systemd (at build/image creation time or in initramfs/initrd).
>
> So, the minimum amount of necessary changes seems to be:
> * create /run as directory
> and make /var/run->../run, /var/lock->run/lock link to it;
> /run gets automatically mounted on boot
This is something that we can easily do. Except, we should then also mount a
tmpfs on /run in the non-systemd case.
> * create /var/tmp as directory;
> needs manual mount setup (fstab or .mount unit)
This also needs to be a tmpfs by the way. Very annoying to have all these tmpfses.
> * /var/lib/dbus is then a dead link pointing to /tmp/dbus,
> not sure if /run/dbus would be the correct link dest
Can't we just make /var/lib/dbus/machine-id a symlink to /tmp/machine-id? Or
does that not work?
[snip] Maxime already commented on the rest.
Regards,
Arnout
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286500
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Buildroot] systemd: write-up and packaging questions
2014-10-15 18:24 ` Arnout Vandecappelle
@ 2014-10-17 6:32 ` André Erdmann
0 siblings, 0 replies; 9+ messages in thread
From: André Erdmann @ 2014-10-17 6:32 UTC (permalink / raw)
To: buildroot
Hi,
2014-10-15 20:24 GMT+02:00 Arnout Vandecappelle <arnout@mind.be>:
> On 12/10/14 19:59, Andr? Erdmann wrote:
>> Hi,
>>
>> Some of the issues pointed out below may be already known, but I couldn't
>> find any report on this, so I'd like to share my experience with setting up a
>> systemd-based system that does a little bit more than bringing up a console ;)
>> Use case was tvheadend with avahi and nfs (+ dropbear etc.), running on a
>> DreamPlug. Overall it works great, but requires some post-build actions:
>>
>> * installation of additional service files
>> (I'll propose patches for them sooner or later)
>
> Sooner would be good, because we've had several other reports of systemd not
> working.
>
I'm on it ;) But it won't be that many files (nfs/rpcbind, tvheadend
and mongoose); In most cases I just adapted (copy&edit) files from
Gentoo, Arch or the upstream repo
>> * changes to the default rootfs skeleton
>
> Actually this is the one that should be done soon.
>
>> * optional: removal of /etc/init.d etc.
>
> Someone is working on that.
>
>>
>>
>> Filesystem Layout
>> =================
>>
>> There are some issues with the default rootfs skeleton.
>> For example, systemd-hostnamed fails to start with the error message
>> "file exists", likely related to symlinks pointing to /tmp (/run, /var/...).
>> After some trial-and-error I've figured out that both /run and /var/tmp
>> symlinks must be replaced with real directories, and that it needs to be done
>> before booting systemd (at build/image creation time or in initramfs/initrd).
>>
>> So, the minimum amount of necessary changes seems to be:
>> * create /run as directory
>> and make /var/run->../run, /var/lock->run/lock link to it;
>> /run gets automatically mounted on boot
>
> This is something that we can easily do. Except, we should then also mount a
> tmpfs on /run in the non-systemd case.
>
Is replacing /run,/var/run,/var/lock and editing /etc/fstab in
system/skeleton sufficient? I'm aware that the fstab entry is not
required for systemd, but it doesn't hurt either.
>> * create /var/tmp as directory;
>> needs manual mount setup (fstab or .mount unit)
>
> This also needs to be a tmpfs by the way. Very annoying to have all these tmpfses.
>
Could also be bind-mounted from /tmp. Still another mountpoint that
needs to be taken care of, but maybe more backwards-compatible and
would share its mount options (e.g. size limit) with /tmp.
>> * /var/lib/dbus is then a dead link pointing to /tmp/dbus,
>> not sure if /run/dbus would be the correct link dest
>
> Can't we just make /var/lib/dbus/machine-id a symlink to /tmp/machine-id? Or
> does that not work?
>
I don't know. /tmp/((dbus/)?)machine-id exists on
sysvinit/busybox-init systems only where /etc/init.d/S30dbus creates
it.
On a systemd-booted machine, /var/lib/dbus is empty (when created as
dir) and there's only /etc/machine-id, which gets created as an empty
file by the systemd package; systemd then generates an ID during
bootup and writes it to /etc/machine-id if possible, else it gets
written to /run/machine-id and bind-mounted.
Symlinking /etc/machine-id to /tmp/machine-id is not an option (I
tried it). systemd then believes to boot a stateless system ("empty
/etc"), services fail to start, e.g. systemd-tmpfiles, and the journal
is empty. It can be worked around by mounting /tmp and creating an
empty /tmp/machine-id before exec-ing systemd's init, but that's far
from being practical.
What about symlinking /var/lib/dbus/machine-id to /etc/machine-id for
systemd-based systems and keeping /var/lib/dbus as-is (symlink)
otherwise (non-systemd)? If that violates the readonly rootfs
scenario, we'd need another solution.
> [snip] Maxime already commented on the rest.
>
>
> Regards,
> Arnout
>
> --
> Arnout Vandecappelle arnout at mind be
> Senior Embedded Software Architect +32-16-286500
> Essensium/Mind http://www.mind.be
> G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
> LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
> GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Buildroot] systemd: write-up and packaging questions
2014-10-12 19:12 ` Maxime Hadjinlian
@ 2014-10-17 8:21 ` Paassen, Hiram van
2014-10-17 9:15 ` André Erdmann
2014-10-17 10:07 ` Maxime Hadjinlian
0 siblings, 2 replies; 9+ messages in thread
From: Paassen, Hiram van @ 2014-10-17 8:21 UTC (permalink / raw)
To: buildroot
On zo, 2014-10-12 at 21:12 +0200, Maxime Hadjinlian wrote:
> Hi Andr?, All
>
> On Sun, Oct 12, 2014 at 7:59 PM, Andr? Erdmann <dywi@mailerd.de> wrote:
> > Hi,
> >
> > Some of the issues pointed out below may be already known, but I couldn't
> > find any report on this, so I'd like to share my experience with setting up a
> > systemd-based system that does a little bit more than bringing up a console ;)
> > Use case was tvheadend with avahi and nfs (+ dropbear etc.), running on a
> > DreamPlug. Overall it works great, but requires some post-build actions:
> >
> > * installation of additional service files
> > (I'll propose patches for them sooner or later)
> > * changes to the default rootfs skeleton
> > * optional: removal of /etc/init.d etc.
> I have a patch that I need to send that does just that.
> >
> >
> > Filesystem Layout
> > =================
> >
> > There are some issues with the default rootfs skeleton.
> > For example, systemd-hostnamed fails to start with the error message
> > "file exists", likely related to symlinks pointing to /tmp (/run, /var/...).
> > After some trial-and-error I've figured out that both /run and /var/tmp
> > symlinks must be replaced with real directories, and that it needs to be done
> > before booting systemd (at build/image creation time or in initramfs/initrd).
> >
> > So, the minimum amount of necessary changes seems to be:
> > * create /run as directory
> > and make /var/run->../run, /var/lock->run/lock link to it;
> > /run gets automatically mounted on boot
> > * create /var/tmp as directory;
> > needs manual mount setup (fstab or .mount unit)
> > * /var/lib/dbus is then a dead link pointing to /tmp/dbus,
> > not sure if /run/dbus would be the correct link dest
We use buildroot with read-only root and we get the following messages
from systemd-tmpfiles just after boot:
Jan 01 00:00:18 iris systemd-tmpfiles[70]: chmod(/var) failed: Read-only
file system
Jan 01 00:00:18 iris systemd-tmpfiles[70]:
symlink(../usr/share/zoneinfo/UTC, /etc/localtime) failed: Read-only
file system
Jan 01 00:00:18 iris systemd-tmpfiles[70]:
symlink(../proc/self/mounts, /etc/mtab) failed: Read-only file system
Jan 01 00:00:18 iris systemd-tmpfiles[70]: chmod(/var/lib) failed:
Read-only file system
Jan 01 00:00:18 iris systemd-tmpfiles[70]: chmod(/var/lib/systemd)
failed: Read-only file system
Jan 01 00:00:18 iris systemd-tmpfiles[70]:
chmod(/var/lib/systemd/coredump) failed: Read-only file system
I suspect some of them stem from an unexpected filesystem layout in
combination with not being able to change things
Also service with PrivateTmp=true won't work because the need
the /tmp /var/tmp split
See systemd-journal-gatewayd as an example of a systemd service that
cannot be started in the default configuration
> >
> >
> > Unit Files
> > ==========
> >
> > This section is mostly about packaging guidelines,
> > the manual doesn't answer the questions below.
> You're right, the manual is really in need of update on that subject.
> But there are some pending changes for which I already have patch that
> I am currently finishing.
> >
> > Installation
> > ------------
> >
> > systemd's libdir is /lib/system.
> > Most unit files (.service et al) are installed to /etc/systemd/system,
> > systemd's own unit files are installed to /lib/systemd/system and some
> > packages(*) install their files to /usr/lib/systemd/system, which is rather
> > confusing. Either dir works (search order is /etc > /lib > /usr/lib),
> > but what's the recommended location?
> If I'm reading the FHS correctly, /usr/lib/systemd/ would the the
> targets and what nots for systemd itself, and so everything in /etc is
> hosts specific so I would keep everything installed by our packages in
> /etc/systemd/system.
I think this depends on your viewpoint:
/usr/lib is for "distros" since you might say that buildroot is
generating a custom distro I would say that one might want to
use /usr/lib
This keeps /etc/ for making persistent changes based on individual
systems and /run/ for making non persistent changes
systemd itself mostly uses /lib
Also:
See my other mail about systemctl for an hour ago (was unaware of this
discussion) The script I'm referring to, taken from open-embedded
uses /etc to install symlinks to.
So open-embedded seems to have chosen /etc for enable-symlinks
independent of where the original unit files are installed (as per
systemctl behavior I suppose)
> > I'd prefer to have them installed in one dir (systemd's libdir).
> >
> > (*) grepping yields nginx and connman
> >
> >
> > Auto-Enabling
> > -------------
> >
> > Most packages enable their unit files by default(*), others don't.
> > Example: lighttpd gets enabled, nginx does not.
> > Is there any policy for when [not] to enable services?
> >
> > (*) "ln -s <unit> /etc/systemd/system/<target>.target.wants/<unit>"
> IMHO, we should enable by default for the moment. The users can
> disable everything through a post-build script.
> A better way to handle that, would be, as Samuel Martin said on IRC,
> to have some infra like the users table to handle what you want to be
> enabled or not.
> But that may needs an RFC so we could start discussing this.
I don't think you want to enable by default since systemd already
provides a lot of units not enabled by default (journal-gatewayd for
example)
See my other mail "systemctl enable" for a suggestion how to handle
enabling
> >
> >
> > Maybe it'd make sense to introduce some SYSTEMD_ variables so that
> > packages don't have to hardcode/guess systemd file paths, for example:
> > * SYSTEMD_LIBDIR (= /lib/systemd)
> > * SYSTEMD_UNITDIR (= $(SYSTEMD_LIBDIR)/system)
> > * SYSTEMD_CONFDIR (= /etc/systemd)
> > * SYSTEMD_UNITCONFDIR (= $(SYSTEMD_CONFDIR)/system)
> > * relpath from <confdir> to <libdir> (= ../..$(SYSTEMD_LIBDIR))
> > * relpath from <confdir>/system to <libdir>/system (= ../../$(SYSTEMD_UNITDIR))
> >
> > Bonus: export these variables to post-build scripts
> Yes, it would be really nice.
> >
> >
> > --
> > Andr?
> > _______________________________________________
> > buildroot mailing list
> > buildroot at busybox.net
> > http://lists.busybox.net/mailman/listinfo/buildroot
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
________________________________
Power Products, LLC Email Notice
This message is intended only for the use of the Addressee and may contain information that is PRIVILEGED and/or CONFIDENTIAL.
This email is intended only for the personal and confidential use of the recipient(s) named above. If the reader of this email is not an intended recipient, you have received this email in error and any review, dissemination, distribution or copying is strictly prohibited.
If you have received this email in error, please notify the sender immediately by return mail and permanently delete the copy you received.
Thank you.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Buildroot] systemd: write-up and packaging questions
2014-10-17 8:21 ` Paassen, Hiram van
@ 2014-10-17 9:15 ` André Erdmann
2014-10-17 10:07 ` Maxime Hadjinlian
1 sibling, 0 replies; 9+ messages in thread
From: André Erdmann @ 2014-10-17 9:15 UTC (permalink / raw)
To: buildroot
[Resend / log-copy&paste tricked my mail program into sending it out too early]
2014/10/17 Hiram Van Paassen <Hiram.van.Paassen@mastervolt.com>:
> On zo, 2014-10-12 at 21:12 +0200, Maxime Hadjinlian wrote:
>> Hi Andr?, All
>>
>> On Sun, Oct 12, 2014 at 7:59 PM, Andr? Erdmann <dywi@mailerd.de> wrote:
>>> Hi,
>>>
>>> Some of the issues pointed out below may be already known, but I couldn't
>>> find any report on this, so I'd like to share my experience with setting up a
>>> systemd-based system that does a little bit more than bringing up a console ;)
>>> Use case was tvheadend with avahi and nfs (+ dropbear etc.), running on a
>>> DreamPlug. Overall it works great, but requires some post-build actions:
>>>
>>> * installation of additional service files
>>> (I'll propose patches for them sooner or later)
>>> * changes to the default rootfs skeleton
>>> * optional: removal of /etc/init.d etc.
>> I have a patch that I need to send that does just that.
>>>
>>>
>>> Filesystem Layout
>>> =================
>>>
>>> There are some issues with the default rootfs skeleton.
>>> For example, systemd-hostnamed fails to start with the error message
>>> "file exists", likely related to symlinks pointing to /tmp (/run, /var/...).
>>> After some trial-and-error I've figured out that both /run and /var/tmp
>>> symlinks must be replaced with real directories, and that it needs to be done
>>> before booting systemd (at build/image creation time or in initramfs/initrd).
>>>
>>> So, the minimum amount of necessary changes seems to be:
>>> * create /run as directory
>>> and make /var/run->../run, /var/lock->run/lock link to it;
>>> /run gets automatically mounted on boot
>>> * create /var/tmp as directory;
>>> needs manual mount setup (fstab or .mount unit)
>>> * /var/lib/dbus is then a dead link pointing to /tmp/dbus,
>>> not sure if /run/dbus would be the correct link dest
> We use buildroot with read-only root and we get the following messages
> from systemd-tmpfiles just after boot:
>
> Jan 01 00:00:18 iris systemd-tmpfiles[70]: chmod(/var) failed: Read-only
> file system
> Jan 01 00:00:18 iris systemd-tmpfiles[70]:
> symlink(../usr/share/zoneinfo/UTC, /etc/localtime) failed: Read-only
> file system
> Jan 01 00:00:18 iris systemd-tmpfiles[70]:
> symlink(../proc/self/mounts, /etc/mtab) failed: Read-only file system
> Jan 01 00:00:18 iris systemd-tmpfiles[70]: chmod(/var/lib) failed:
> Read-only file system
> Jan 01 00:00:18 iris systemd-tmpfiles[70]: chmod(/var/lib/systemd)
> failed: Read-only file system
> Jan 01 00:00:18 iris systemd-tmpfiles[70]:
> chmod(/var/lib/systemd/coredump) failed: Read-only file system
>
> I suspect some of them stem from an unexpected filesystem layout in
> combination with not being able to change things
>
Just commenting on this particular issue:
If you don't change the default filesystem layout, then things fail dramatically,
especially when /etc is readonly. That's my experience with systemd+buildroot so far.
I use an aufs squashfs+memory as rootfs, which allows me to track fs changes quite
easily. I've attached some logs below so you can make up your mind on what needs to
be writable. I haven't rebooted the machine since a while and did some
changes in between (e.g. /etc/systemd/system), which can be ignored.
$ grep -v /home /proc/self/mounts
rootfs / rootfs rw,size=254908k,nr_inodes=63727 0 0
proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0
mdev /dev devtmpfs rw,nosuid,relatime,size=10240k,nr_inodes=64012,mode=755 0 0
/dev/zram1 /.rootfs_union_root/mem ext4 rw,noatime,discard,nobarrier,commit=240 0 0
sfs_container /.rootfs_union_root/container tmpfs ro,relatime,size=22528k,mode=711 0 0
/dev/loop0 /.rootfs_union_root/loop/rootfs squashfs ro,relatime 0 0
/dev/loop1 /.rootfs_union_root/loop/overlay squashfs ro,relatime 0 0
aufs_rootfs / aufs rw,relatime,si=39d8f4dc,dio,dirperm1 0 0
/dev/zram2 /rw ext4 rw,nodev,noatime,discard,nobarrier,commit=240 0 0
/dev/zram3 /run ext4 rw,nosuid,nodev,noatime,discard,nobarrier,commit=240 0 0
/dev/zram2 /etc/udev ext4 rw,nodev,noatime,discard,nobarrier,commit=240 0 0
/dev/zram2 /status ext4 rw,nodev,noatime,discard,nobarrier,commit=240 0 0
/dev/zram2 /tmp ext4 rw,nodev,noatime,discard,nobarrier,commit=240 0 0
/dev/zram2 /var/log ext4 rw,nodev,noatime,discard,nobarrier,commit=240 0 0
/dev/zram2 /var/www ext4 rw,nodev,noatime,discard,nobarrier,commit=240 0 0
/dev/zram2 /var/tmp ext4 rw,nodev,noatime,discard,nobarrier,commit=240 0 0
/dev/zram2 /var/lib/systemd ext4 rw,nodev,noatime,discard,nobarrier,commit=240 0 0
/dev/zram2 /lib/modules ext4 ro,nodev,noatime,discard,nobarrier,commit=240 0 0
mntfs /.mntfs tmpfs rw,nosuid,nodev,noexec,relatime,size=1024k,mode=775,gid=6 0 0
mntfs /mnt tmpfs rw,nosuid,nodev,noexec,relatime,size=1024k,mode=775,gid=6 0 0
mntfs /media tmpfs rw,nosuid,nodev,noexec,relatime,size=1024k,mode=775,gid=6 0 0
mntfs /data tmpfs rw,nosuid,nodev,noexec,relatime,size=1024k,mode=775,gid=6 0 0
tmpfs /dev/shm tmpfs rw,nodev,noexec,size=4096k 0 0
devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
tmpfs /sys/fs/cgroup tmpfs ro,nosuid,nodev,noexec,mode=755 0 0
cgroup /sys/fs/cgroup/systemd cgroup rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/lib/systemd/systemd-cgroups-agent,name=syst$
cgroup /sys/fs/cgroup/cpuset cgroup rw,nosuid,nodev,noexec,relatime,cpuset 0 0
cgroup /sys/fs/cgroup/cpu,cpuacct cgroup rw,nosuid,nodev,noexec,relatime,cpu,cpuacct 0 0
cgroup /sys/fs/cgroup/memory cgroup rw,nosuid,nodev,noexec,relatime,memory 0 0
cgroup /sys/fs/cgroup/devices cgroup rw,nosuid,nodev,noexec,relatime,devices 0 0
cgroup /sys/fs/cgroup/freezer cgroup rw,nosuid,nodev,noexec,relatime,freezer 0 0
cgroup /sys/fs/cgroup/net_cls,net_prio cgroup rw,nosuid,nodev,noexec,relatime,net_cls,net_prio 0 0
cgroup /sys/fs/cgroup/blkio cgroup rw,nosuid,nodev,noexec,relatime,blkio 0 0
systemd-1 /proc/sys/fs/binfmt_misc autofs rw,relatime,fd=22,pgrp=1,timeout=300,minproto=5,maxproto=5,direct 0 0
debugfs /sys/kernel/debug debugfs rw,relatime 0 0
mqueue /dev/mqueue mqueue rw,relatime 0 0
fusectl /sys/fs/fuse/connections fusectl rw,relatime 0 0
nfsd /proc/fs/nfsd nfsd rw,relatime 0 0
binfmt_misc /proc/sys/fs/binfmt_misc binfmt_misc rw,relatime 0 0
(EOF)
$ find /.rootfs_union_root/mem/
/.rootfs_union_root/mem/
/.rootfs_union_root/mem/.wh..wh.aufs
/.rootfs_union_root/mem/lost+found
/.rootfs_union_root/mem/dev
/.rootfs_union_root/mem/dev/.keep
/.rootfs_union_root/mem/dev/shm
/.rootfs_union_root/mem/dev/shm/.keep
/.rootfs_union_root/mem/.keep
/.rootfs_union_root/mem/mnt
/.rootfs_union_root/mem/mnt/.wh..wh..opq
/.rootfs_union_root/mem/etc
/.rootfs_union_root/mem/etc/resolv.conf
/.rootfs_union_root/mem/etc/systemd
/.rootfs_union_root/mem/etc/systemd/system
/.rootfs_union_root/mem/etc/systemd/system/.wh.home-tvheadend.automount
/.rootfs_union_root/mem/etc/systemd/system/tvheadend-backup.timer
/.rootfs_union_root/mem/etc/systemd/system/mongoose at .service
/.rootfs_union_root/mem/etc/systemd/system/multi-user.target.wants
/.rootfs_union_root/mem/etc/systemd/system/multi-user.target.wants/home-tvheadend-nfs.mount
/.rootfs_union_root/mem/etc/systemd/system/tvheadend-backup.service
/.rootfs_union_root/mem/etc/systemd/system/home-tvheadend-nfs.mount
/.rootfs_union_root/mem/etc/systemd/system/home-tvheadend.mount
/.rootfs_union_root/mem/etc/systemd/system/tvheadend.service.d
/.rootfs_union_root/mem/etc/systemd/system/tvheadend.service.d/10-remotefs.conf
/.rootfs_union_root/mem/etc/systemd/system/tvheadend.service.d/09-disk.conf
/.rootfs_union_root/mem/etc/systemd/system/home-tvheadend-nfs.automount
/.rootfs_union_root/mem/etc/group
/.rootfs_union_root/mem/etc/mactab
/.rootfs_union_root/mem/etc/group-
/.rootfs_union_root/mem/etc/machine-id
/.rootfs_union_root/mem/etc/mtab
/.rootfs_union_root/mem/etc/udev
/.rootfs_union_root/mem/etc/udev/.wh..wh..opq
/.rootfs_union_root/mem/etc/.updated
/.rootfs_union_root/mem/etc/gshadow
/.rootfs_union_root/mem/etc/.pwd.lock
/.rootfs_union_root/mem/var
/.rootfs_union_root/mem/var/log
/.rootfs_union_root/mem/var/log/.wh..wh..opq
/.rootfs_union_root/mem/var/www
/.rootfs_union_root/mem/var/www/.wh..wh..opq
/.rootfs_union_root/mem/var/lib
/.rootfs_union_root/mem/var/lib/systemd
/.rootfs_union_root/mem/var/lib/systemd/.wh..wh..opq
/.rootfs_union_root/mem/var/lib/nfs
/.rootfs_union_root/mem/var/lib/nfs/state
/.rootfs_union_root/mem/var/lib/nfs/export-lock
/.rootfs_union_root/mem/var/lib/nfs/.etab.lock
/.rootfs_union_root/mem/var/lib/nfs/.xtab.lock
/.rootfs_union_root/mem/var/.updated
/.rootfs_union_root/mem/var/tmp
/.rootfs_union_root/mem/var/tmp/.wh..wh..opq
/.rootfs_union_root/mem/.wh..wh.plnk
/.rootfs_union_root/mem/.mntfs
/.rootfs_union_root/mem/lib
/.rootfs_union_root/mem/lib/modules
/.rootfs_union_root/mem/data
/.rootfs_union_root/mem/proc
/.rootfs_union_root/mem/proc/.keep
/.rootfs_union_root/mem/status
/.rootfs_union_root/mem/LIRAM_ENV
/.rootfs_union_root/mem/media
/.rootfs_union_root/mem/media/.wh..wh..opq
/.rootfs_union_root/mem/root
/.rootfs_union_root/mem/root/.config
/.rootfs_union_root/mem/root/.config/htop
/.rootfs_union_root/mem/root/.config/htop/htoprc
/.rootfs_union_root/mem/root/.ash_history
/.rootfs_union_root/mem/.keep_zram
/.rootfs_union_root/mem/.wh..wh.orph
/.rootfs_union_root/mem/.rootfs_union_root
/.rootfs_union_root/mem/.rootfs_union_root/container
/.rootfs_union_root/mem/.rootfs_union_root/mem
/.rootfs_union_root/mem/.rootfs_union_root/loop
/.rootfs_union_root/mem/.rootfs_union_root/loop/overlay
/.rootfs_union_root/mem/.rootfs_union_root/loop/rootfs
/.rootfs_union_root/mem/tmp
/.rootfs_union_root/mem/tmp/.wh..wh..opq
/.rootfs_union_root/mem/rw
(EOF)
$ find /rw/
/rw/
/rw/tmp
/rw/tmp/.font-unix
/rw/tmp/mongoose at .service
/rw/tmp/OX
/rw/tmp/.X11-unix
/rw/tmp/.XIM-unix
/rw/tmp/systemd-private-9e485374aa2047b2b83f0565a6f63976-systemd-timesyncd.service-C7UvPb
/rw/tmp/systemd-private-9e485374aa2047b2b83f0565a6f63976-systemd-timesyncd.service-C7UvPb/tmp
/rw/tmp/systemd-private-9e485374aa2047b2b83f0565a6f63976-tvheadend.service-AKkFFI
/rw/tmp/systemd-private-9e485374aa2047b2b83f0565a6f63976-tvheadend.service-AKkFFI/tmp
/rw/tmp/avahi-autopid
/rw/tmp/.Test-unix
/rw/tmp/systemd-private-9e485374aa2047b2b83f0565a6f63976-mongoose at default.service-uNa44A
/rw/tmp/systemd-private-9e485374aa2047b2b83f0565a6f63976-mongoose at default.service-uNa44A/tmp
/rw/tmp/.ICE-unix
/rw/.keep_zram
/rw/etc
/rw/etc/udev
/rw/etc/udev/hwdb.d
/rw/etc/udev/rules.d
/rw/etc/udev/udev.conf
/rw/etc/udev/hwdb.bin
/rw/lost+found
/rw/var
/rw/var/tmp
/rw/var/tmp/.keep
/rw/var/tmp/systemd-private-9e485374aa2047b2b83f0565a6f63976-systemd-timesyncd.service-cLHa5c
/rw/var/tmp/systemd-private-9e485374aa2047b2b83f0565a6f63976-systemd-timesyncd.service-cLHa5c/tmp
/rw/var/tmp/systemd-private-9e485374aa2047b2b83f0565a6f63976-tvheadend.service-5Mbirx
/rw/var/tmp/systemd-private-9e485374aa2047b2b83f0565a6f63976-tvheadend.service-5Mbirx/tmp
/rw/var/tmp/systemd-private-9e485374aa2047b2b83f0565a6f63976-mongoose at default.service-nzzCYB
/rw/var/tmp/systemd-private-9e485374aa2047b2b83f0565a6f63976-mongoose at default.service-nzzCYB/tmp
/rw/var/log
/rw/var/log/btmp
/rw/var/log/wtmp
/rw/var/log/lastlog
/rw/var/log/journal
/rw/var/log/journal/remote
/rw/var/log/journal/.keep
/rw/var/lib
/rw/var/lib/systemd
/rw/var/lib/systemd/clock
/rw/var/lib/systemd/random-seed
/rw/var/lib/systemd/coredump
/rw/var/lib/systemd/timers
/rw/var/lib/systemd/timers/stamp-tvheadend-backup.timer
/rw/var/lib/systemd/catalog
/rw/var/lib/systemd/catalog/database
/rw/var/www
/rw/var/www/htdocs
/rw/var/www/htdocs/sys
/rw/var/www/htdocs/index.html
/rw/zdisk
/rw/zdisk/rw
/rw/zdisk/run
/rw/.keep
/rw/status
/rw/status/system
/rw/status/system/.keep
/rw/status/system/boot-blame.txt
/rw/status/system/boot-time.txt
/rw/status/system/boot-plot.svg
/rw/status/initramfs.log
/rw/lib
/rw/lib/modules
/rw/lib/modules/....
(EOF)
$ systemctl list-units --no-pager
UNIT LOAD ACTIVE SUB DESCRIPTION
proc-sys-fs-binfmt_misc.automount loaded active running Arbitrary Executable File Formats File System Automount Point
sys-devices-ocp\x40f1000000-f1012000.serial-tty-ttyS0.device loaded active plugged /sys/devices/ocp at f1000000/f1012000.serial/tty/ttyS0
sys-devices-ocp\x40f1000000-f1050000.ehci-usb1-1\x2d1-1\x2d1.1-1\x2d1.1:1.0-host1-target1:0:0-1:0:0:0-block-sda.device loaded active plugged STORAGE_DEVICE
sys-devices-ocp\x40f1000000-f1050000.ehci-usb1-1\x2d1-1\x2d1.1-1\x2d1.1:1.0-host1-target1:0:0-1:0:0:1-block-sdb-sdb1.device loaded active plugged STORAGE_DEVICE dp_tv
sys-devices-ocp\x40f1000000-f1050000.ehci-usb1-1\x2d1-1\x2d1.1-1\x2d1.1:1.0-host1-target1:0:0-1:0:0:1-block-sdb.device loaded active plugged STORAGE_DEVICE
sys-devices-ocp\x40f1000000-f1050000.ehci-usb1-1\x2d1-1\x2d1.4-1\x2d1.4:1.0-sound-card0.device loaded active plugged Audio Adapter
sys-devices-platform-mv643xx_eth_port.0-net-eth0.device loaded active plugged /sys/devices/platform/mv643xx_eth_port.0/net/eth0
sys-devices-platform-mv643xx_eth_port.1-net-eth1.device loaded active plugged /sys/devices/platform/mv643xx_eth_port.1/net/eth1
sys-devices-platform-serial8250-tty-ttyS1.device loaded active plugged /sys/devices/platform/serial8250/tty/ttyS1
sys-devices-virtual-block-loop0.device loaded active plugged /sys/devices/virtual/block/loop0
sys-devices-virtual-block-loop1.device loaded active plugged /sys/devices/virtual/block/loop1
sys-devices-virtual-block-zram0.device loaded active plugged /sys/devices/virtual/block/zram0
sys-devices-virtual-block-zram1.device loaded active plugged /sys/devices/virtual/block/zram1
sys-devices-virtual-block-zram2.device loaded active plugged /sys/devices/virtual/block/zram2
sys-devices-virtual-block-zram3.device loaded active plugged /sys/devices/virtual/block/zram3
sys-devices-virtual-block-zram4.device loaded active plugged /sys/devices/virtual/block/zram4
sys-devices-virtual-block-zram5.device loaded active plugged /sys/devices/virtual/block/zram5
sys-devices-virtual-block-zram6.device loaded active plugged /sys/devices/virtual/block/zram6
sys-devices-virtual-block-zram7.device loaded active plugged /sys/devices/virtual/block/zram7
sys-devices-virtual-net-lan0.device loaded active plugged /sys/devices/virtual/net/lan0
sys-devices-virtual-net-sit0.device loaded active plugged /sys/devices/virtual/net/sit0
sys-devices-virtual-tty-ttyprintk.device loaded active plugged /sys/devices/virtual/tty/ttyprintk
sys-module-fuse.device loaded active plugged /sys/module/fuse
sys-subsystem-net-devices-eth0.device loaded active plugged /sys/subsystem/net/devices/eth0
sys-subsystem-net-devices-eth1.device loaded active plugged /sys/subsystem/net/devices/eth1
sys-subsystem-net-devices-lan0.device loaded active plugged /sys/subsystem/net/devices/lan0
sys-subsystem-net-devices-sit0.device loaded active plugged /sys/subsystem/net/devices/sit0
-.mount loaded active mounted /
\x2emntfs.mount loaded active mounted /.mntfs
\x2erootfs_union_root-container.mount loaded active mounted /.rootfs_union_root/container
\x2erootfs_union_root-loop-overlay.mount loaded active mounted /.rootfs_union_root/loop/overlay
\x2erootfs_union_root-loop-rootfs.mount loaded active mounted /.rootfs_union_root/loop/rootfs
\x2erootfs_union_root-mem.mount loaded active mounted /.rootfs_union_root/mem
data.mount loaded active mounted /data
dev-mqueue.mount loaded active mounted POSIX Message Queue File System
etc-udev.mount loaded active mounted /etc/udev
home-tvheadend-nfs.mount loaded active mounted tv recording dir
home-tvheadend.mount loaded active mounted tv home dir
lib-modules.mount loaded active mounted /lib/modules
media.mount loaded active mounted /media
mnt.mount loaded active mounted /mnt
proc-fs-nfsd.mount loaded active mounted NFS Configuration File System
proc-sys-fs-binfmt_misc.mount loaded active mounted Arbitrary Executable File Formats File System
rw.mount loaded active mounted /rw
status.mount loaded active mounted /status
sys-fs-fuse-connections.mount loaded active mounted FUSE Control File System
sys-kernel-debug.mount loaded active mounted Debug File System
tmp.mount loaded active mounted /tmp
var-lib-systemd.mount loaded active mounted /var/lib/systemd
var-log.mount loaded active mounted /var/log
var-tmp.mount loaded active mounted /var/tmp
var-www.mount loaded active mounted /var/www
systemd-ask-password-console.path loaded active waiting Dispatch Password Requests to Console Directory Watch
systemd-ask-password-wall.path loaded active waiting Forward Password Requests to Wall Directory Watch
avahi-daemon.service loaded active running Avahi mDNS/DNS-SD Stack
dbus.service loaded active running D-Bus System Message Bus
dropbear.service loaded active running Dropbear SSH daemon
kmod-static-nodes.service loaded active exited Create list of required static device nodes for the current kernel
mongoose at default.service loaded active running Mongoose HTTP Daemon
nfsd.service loaded active exited NFS server
rc-local.service loaded active exited Runs /etc/rc.local on startup
rpc-mountd.service loaded active running NFS Mount Daemon
rpc-statd.service loaded active running NFSv2/3 Network Status Monitor Daemon
rpcbind.service loaded active running RPC Bind
serial-getty at ttyS0.service loaded active running Serial Getty on ttyS0
systemd-journal-catalog-update.service loaded active exited Rebuild Journal Catalog
systemd-journald.service loaded active running Journal Service
systemd-logind.service loaded active running Login Service
systemd-networkd-wait-online.service loaded active exited Wait for Network to be Configured
systemd-networkd.service loaded active running Network Service
systemd-random-seed.service loaded active exited Load/Save Random Seed
systemd-remount-fs.service loaded active exited Remount Root and Kernel File Systems
systemd-resolved.service loaded active running Network Name Resolution
systemd-sysctl.service loaded active exited Apply Kernel Variables
systemd-sysusers.service loaded active exited Create System Users
systemd-timesyncd.service loaded active running Network Time Synchronization
systemd-tmpfiles-setup-dev.service loaded active exited Create Static Device Nodes in /dev
systemd-tmpfiles-setup.service loaded active exited Create Volatile Files and Directories
systemd-udev-hwdb-update.service loaded active exited Rebuild Hardware Database
systemd-udev-trigger.service loaded active exited udev Coldplug all Devices
systemd-udevd.service loaded active running udev Kernel Device Manager
systemd-update-done.service loaded active exited Update is Completed
systemd-update-utmp.service loaded active exited Update UTMP about System Boot/Shutdown
systemd-user-sessions.service loaded active exited Permit User Sessions
tvheadend.service loaded active running tvheadend
-.slice loaded active active Root Slice
system-mongoose.slice loaded active active system-mongoose.slice
system-serial\x2dgetty.slice loaded active active system-serial\x2dgetty.slice
system.slice loaded active active System Slice
user.slice loaded active active User and Session Slice
avahi-daemon.socket loaded active running Avahi mDNS/DNS-SD Stack Activation Socket
dbus.socket loaded active running D-Bus System Message Bus Socket
systemd-initctl.socket loaded active listening /dev/initctl Compatibility Named Pipe
systemd-journald-dev-log.socket loaded active running Journal Socket (/dev/log)
systemd-journald.socket loaded active running Journal Socket
systemd-shutdownd.socket loaded active listening Delayed Shutdown Socket
systemd-udevd-control.socket loaded active running udev Control Socket
systemd-udevd-kernel.socket loaded active running udev Kernel Socket
dev-zram0.swap loaded active active /dev/zram0
basic.target loaded active active Basic System
getty.target loaded active active Login Prompts
local-fs-pre.target loaded active active Local File Systems (Pre)
local-fs.target loaded active active Local File Systems
multi-user.target loaded active active Multi-User System
network-online.target loaded active active Network is Online
network.target loaded active active Network
paths.target loaded active active Paths
remote-fs-pre.target loaded active active Remote File Systems (Pre)
remote-fs.target loaded active active Remote File Systems
rpcbind.target loaded active active RPC Port Mapper
slices.target loaded active active Slices
sockets.target loaded active active Sockets
sound.target loaded active active Sound Card
swap.target loaded active active Swap
sysinit.target loaded active active System Initialization
time-sync.target loaded active active System Time Synchronized
timers.target loaded active active Timers
statusfs-bootstat.timer loaded active elapsed Exports bootup stats via /status
systemd-tmpfiles-clean.timer loaded active waiting Daily Cleanup of Temporary Directories
tvheadend-backup.timer loaded active waiting weekly tvheadend config backup
LOAD = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB = The low-level unit activation state, values depend on unit type.
120 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.
(EOF)
> Also service with PrivateTmp=true won't work because the need
> the /tmp /var/tmp split
>
> See systemd-journal-gatewayd as an example of a systemd service that
> cannot be started in the default configuration
>
>>>
>>>
>>> Unit Files
>>> ==========
>>>
>>> This section is mostly about packaging guidelines,
>>> the manual doesn't answer the questions below.
>> You're right, the manual is really in need of update on that subject.
>> But there are some pending changes for which I already have patch that
>> I am currently finishing.
>>>
>>> Installation
>>> ------------
>>>
>>> systemd's libdir is /lib/system.
>>> Most unit files (.service et al) are installed to /etc/systemd/system,
>>> systemd's own unit files are installed to /lib/systemd/system and some
>>> packages(*) install their files to /usr/lib/systemd/system, which is rather
>>> confusing. Either dir works (search order is /etc > /lib > /usr/lib),
>>> but what's the recommended location?
>> If I'm reading the FHS correctly, /usr/lib/systemd/ would the the
>> targets and what nots for systemd itself, and so everything in /etc is
>> hosts specific so I would keep everything installed by our packages in
>> /etc/systemd/system.
> I think this depends on your viewpoint:
> /usr/lib is for "distros" since you might say that buildroot is
> generating a custom distro I would say that one might want to
> use /usr/lib
>
> This keeps /etc/ for making persistent changes based on individual
> systems and /run/ for making non persistent changes
>
> systemd itself mostly uses /lib
>
> Also:
> See my other mail about systemctl for an hour ago (was unaware of this
> discussion) The script I'm referring to, taken from open-embedded
> uses /etc to install symlinks to.
> So open-embedded seems to have chosen /etc for enable-symlinks
> independent of where the original unit files are installed (as per
> systemctl behavior I suppose)
>
>>> I'd prefer to have them installed in one dir (systemd's libdir).
>>>
>>> (*) grepping yields nginx and connman
>>>
>>>
>>> Auto-Enabling
>>> -------------
>>>
>>> Most packages enable their unit files by default(*), others don't.
>>> Example: lighttpd gets enabled, nginx does not.
>>> Is there any policy for when [not] to enable services?
>>>
>>> (*) "ln -s <unit> /etc/systemd/system/<target>.target.wants/<unit>"
>> IMHO, we should enable by default for the moment. The users can
>> disable everything through a post-build script.
>> A better way to handle that, would be, as Samuel Martin said on IRC,
>> to have some infra like the users table to handle what you want to be
>> enabled or not.
>> But that may needs an RFC so we could start discussing this.
> I don't think you want to enable by default since systemd already
> provides a lot of units not enabled by default (journal-gatewayd for
> example)
>
> See my other mail "systemctl enable" for a suggestion how to handle
> enabling
>>>
>>>
>>> Maybe it'd make sense to introduce some SYSTEMD_ variables so that
>>> packages don't have to hardcode/guess systemd file paths, for example:
>>> * SYSTEMD_LIBDIR (= /lib/systemd)
>>> * SYSTEMD_UNITDIR (= $(SYSTEMD_LIBDIR)/system)
>>> * SYSTEMD_CONFDIR (= /etc/systemd)
>>> * SYSTEMD_UNITCONFDIR (= $(SYSTEMD_CONFDIR)/system)
>>> * relpath from <confdir> to <libdir> (= ../..$(SYSTEMD_LIBDIR))
>>> * relpath from <confdir>/system to <libdir>/system (= ../../$(SYSTEMD_UNITDIR))
>>>
>>> Bonus: export these variables to post-build scripts
>> Yes, it would be really nice.
>>>
>>>
>>> --
>>> Andr?
>>> _______________________________________________
>>> buildroot mailing list
>>> buildroot at busybox.net
>>> http://lists.busybox.net/mailman/listinfo/buildroot
>> _______________________________________________
>> buildroot mailing list
>> buildroot at busybox.net
>> http://lists.busybox.net/mailman/listinfo/buildroot
>
>
> ________________________________
>
> Power Products, LLC Email Notice
>
> This message is intended only for the use of the Addressee and may contain information that is PRIVILEGED and/or CONFIDENTIAL.
> This email is intended only for the personal and confidential use of the recipient(s) named above. If the reader of this email is not an intended recipient, you have received this email in error and any review, dissemination, distribution or copying is strictly prohibited.
> If you have received this email in error, please notify the sender immediately by return mail and permanently delete the copy you received.
>
> Thank you.
>
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Buildroot] systemd: write-up and packaging questions
2014-10-17 8:21 ` Paassen, Hiram van
2014-10-17 9:15 ` André Erdmann
@ 2014-10-17 10:07 ` Maxime Hadjinlian
2014-10-21 18:41 ` Arnout Vandecappelle
1 sibling, 1 reply; 9+ messages in thread
From: Maxime Hadjinlian @ 2014-10-17 10:07 UTC (permalink / raw)
To: buildroot
Hello Hiram, all
On Fri, Oct 17, 2014 at 10:21 AM, Paassen, Hiram van
<Hiram.van.Paassen@mastervolt.com> wrote:
> On zo, 2014-10-12 at 21:12 +0200, Maxime Hadjinlian wrote:
>> Hi Andr?, All
>>
>> On Sun, Oct 12, 2014 at 7:59 PM, Andr? Erdmann <dywi@mailerd.de> wrote:
>> > Hi,
>> >
>> > Some of the issues pointed out below may be already known, but I couldn't
>> > find any report on this, so I'd like to share my experience with setting up a
>> > systemd-based system that does a little bit more than bringing up a console ;)
>> > Use case was tvheadend with avahi and nfs (+ dropbear etc.), running on a
>> > DreamPlug. Overall it works great, but requires some post-build actions:
>> >
>> > * installation of additional service files
>> > (I'll propose patches for them sooner or later)
>> > * changes to the default rootfs skeleton
>> > * optional: removal of /etc/init.d etc.
>> I have a patch that I need to send that does just that.
>> >
>> >
>> > Filesystem Layout
>> > =================
>> >
>> > There are some issues with the default rootfs skeleton.
>> > For example, systemd-hostnamed fails to start with the error message
>> > "file exists", likely related to symlinks pointing to /tmp (/run, /var/...).
>> > After some trial-and-error I've figured out that both /run and /var/tmp
>> > symlinks must be replaced with real directories, and that it needs to be done
>> > before booting systemd (at build/image creation time or in initramfs/initrd).
>> >
>> > So, the minimum amount of necessary changes seems to be:
>> > * create /run as directory
>> > and make /var/run->../run, /var/lock->run/lock link to it;
>> > /run gets automatically mounted on boot
>> > * create /var/tmp as directory;
>> > needs manual mount setup (fstab or .mount unit)
>> > * /var/lib/dbus is then a dead link pointing to /tmp/dbus,
>> > not sure if /run/dbus would be the correct link dest
> We use buildroot with read-only root and we get the following messages
> from systemd-tmpfiles just after boot:
>
> Jan 01 00:00:18 iris systemd-tmpfiles[70]: chmod(/var) failed: Read-only
> file system
> Jan 01 00:00:18 iris systemd-tmpfiles[70]:
> symlink(../usr/share/zoneinfo/UTC, /etc/localtime) failed: Read-only
> file system
> Jan 01 00:00:18 iris systemd-tmpfiles[70]:
> symlink(../proc/self/mounts, /etc/mtab) failed: Read-only file system
> Jan 01 00:00:18 iris systemd-tmpfiles[70]: chmod(/var/lib) failed:
> Read-only file system
> Jan 01 00:00:18 iris systemd-tmpfiles[70]: chmod(/var/lib/systemd)
> failed: Read-only file system
> Jan 01 00:00:18 iris systemd-tmpfiles[70]:
> chmod(/var/lib/systemd/coredump) failed: Read-only file system
>
> I suspect some of them stem from an unexpected filesystem layout in
> combination with not being able to change things
>
> Also service with PrivateTmp=true won't work because the need
> the /tmp /var/tmp split
>
> See systemd-journal-gatewayd as an example of a systemd service that
> cannot be started in the default configuration
>
>> >
>> >
>> > Unit Files
>> > ==========
>> >
>> > This section is mostly about packaging guidelines,
>> > the manual doesn't answer the questions below.
>> You're right, the manual is really in need of update on that subject.
>> But there are some pending changes for which I already have patch that
>> I am currently finishing.
>> >
>> > Installation
>> > ------------
>> >
>> > systemd's libdir is /lib/system.
>> > Most unit files (.service et al) are installed to /etc/systemd/system,
>> > systemd's own unit files are installed to /lib/systemd/system and some
>> > packages(*) install their files to /usr/lib/systemd/system, which is rather
>> > confusing. Either dir works (search order is /etc > /lib > /usr/lib),
>> > but what's the recommended location?
>> If I'm reading the FHS correctly, /usr/lib/systemd/ would the the
>> targets and what nots for systemd itself, and so everything in /etc is
>> hosts specific so I would keep everything installed by our packages in
>> /etc/systemd/system.
> I think this depends on your viewpoint:
> /usr/lib is for "distros" since you might say that buildroot is
> generating a custom distro I would say that one might want to
> use /usr/lib
>
> This keeps /etc/ for making persistent changes based on individual
> systems and /run/ for making non persistent changes
>
> systemd itself mostly uses /lib
>
> Also:
> See my other mail about systemctl for an hour ago (was unaware of this
> discussion) The script I'm referring to, taken from open-embedded
> uses /etc to install symlinks to.
> So open-embedded seems to have chosen /etc for enable-symlinks
> independent of where the original unit files are installed (as per
> systemctl behavior I suppose)
It usually what is done, yes. You get the symlinks in /etc and you
install your unit files and targets, where you feel they should be.
Debian has the symlinks in /etc and the files in /lib/systemd/system/
I would say that we should follow what the major distribution are
doing. I assume they already had discussion on how to organize theses
files.
>
>> > I'd prefer to have them installed in one dir (systemd's libdir).
>> >
>> > (*) grepping yields nginx and connman
>> >
>> >
>> > Auto-Enabling
>> > -------------
>> >
>> > Most packages enable their unit files by default(*), others don't.
>> > Example: lighttpd gets enabled, nginx does not.
>> > Is there any policy for when [not] to enable services?
>> >
>> > (*) "ln -s <unit> /etc/systemd/system/<target>.target.wants/<unit>"
>> IMHO, we should enable by default for the moment. The users can
>> disable everything through a post-build script.
>> A better way to handle that, would be, as Samuel Martin said on IRC,
>> to have some infra like the users table to handle what you want to be
>> enabled or not.
>> But that may needs an RFC so we could start discussing this.
> I don't think you want to enable by default since systemd already
> provides a lot of units not enabled by default (journal-gatewayd for
> example)
Ah yes, my bad, I was only talking about specific packages, not for
every units provided by systemd.
>
> See my other mail "systemctl enable" for a suggestion how to handle
> enabling
I'll look at it.
>> >
>> >
>> > Maybe it'd make sense to introduce some SYSTEMD_ variables so that
>> > packages don't have to hardcode/guess systemd file paths, for example:
>> > * SYSTEMD_LIBDIR (= /lib/systemd)
>> > * SYSTEMD_UNITDIR (= $(SYSTEMD_LIBDIR)/system)
>> > * SYSTEMD_CONFDIR (= /etc/systemd)
>> > * SYSTEMD_UNITCONFDIR (= $(SYSTEMD_CONFDIR)/system)
>> > * relpath from <confdir> to <libdir> (= ../..$(SYSTEMD_LIBDIR))
>> > * relpath from <confdir>/system to <libdir>/system (= ../../$(SYSTEMD_UNITDIR))
>> >
>> > Bonus: export these variables to post-build scripts
>> Yes, it would be really nice.
>> >
>> >
>> > --
>> > Andr?
>> > _______________________________________________
>> > buildroot mailing list
>> > buildroot at busybox.net
>> > http://lists.busybox.net/mailman/listinfo/buildroot
>> _______________________________________________
>> buildroot mailing list
>> buildroot at busybox.net
>> http://lists.busybox.net/mailman/listinfo/buildroot
>
>
> ________________________________
>
> Power Products, LLC Email Notice
>
> This message is intended only for the use of the Addressee and may contain information that is PRIVILEGED and/or CONFIDENTIAL.
> This email is intended only for the personal and confidential use of the recipient(s) named above. If the reader of this email is not an intended recipient, you have received this email in error and any review, dissemination, distribution or copying is strictly prohibited.
> If you have received this email in error, please notify the sender immediately by return mail and permanently delete the copy you received.
>
> Thank you.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Buildroot] systemd: write-up and packaging questions
2014-10-17 10:07 ` Maxime Hadjinlian
@ 2014-10-21 18:41 ` Arnout Vandecappelle
2014-10-21 18:45 ` Maxime Hadjinlian
0 siblings, 1 reply; 9+ messages in thread
From: Arnout Vandecappelle @ 2014-10-21 18:41 UTC (permalink / raw)
To: buildroot
On 17/10/14 12:07, Maxime Hadjinlian wrote:
> Hello Hiram, all
>
> On Fri, Oct 17, 2014 at 10:21 AM, Paassen, Hiram van
> <Hiram.van.Paassen@mastervolt.com> wrote:
>> On zo, 2014-10-12 at 21:12 +0200, Maxime Hadjinlian wrote:
>>> Hi Andr?, All
>>>
>>> On Sun, Oct 12, 2014 at 7:59 PM, Andr? Erdmann <dywi@mailerd.de> wrote:
[snip]
>>>> Installation
>>>> ------------
>>>>
>>>> systemd's libdir is /lib/system.
>>>> Most unit files (.service et al) are installed to /etc/systemd/system,
>>>> systemd's own unit files are installed to /lib/systemd/system and some
>>>> packages(*) install their files to /usr/lib/systemd/system, which is rather
>>>> confusing. Either dir works (search order is /etc > /lib > /usr/lib),
>>>> but what's the recommended location?
>>> If I'm reading the FHS correctly, /usr/lib/systemd/ would the the
>>> targets and what nots for systemd itself, and so everything in /etc is
>>> hosts specific so I would keep everything installed by our packages in
>>> /etc/systemd/system.
>> I think this depends on your viewpoint:
>> /usr/lib is for "distros" since you might say that buildroot is
>> generating a custom distro I would say that one might want to
>> use /usr/lib
>>
>> This keeps /etc/ for making persistent changes based on individual
>> systems and /run/ for making non persistent changes
>>
>> systemd itself mostly uses /lib
>>
>> Also:
>> See my other mail about systemctl for an hour ago (was unaware of this
>> discussion) The script I'm referring to, taken from open-embedded
>> uses /etc to install symlinks to.
>> So open-embedded seems to have chosen /etc for enable-symlinks
>> independent of where the original unit files are installed (as per
>> systemctl behavior I suppose)
> It usually what is done, yes. You get the symlinks in /etc and you
> install your unit files and targets, where you feel they should be.
> Debian has the symlinks in /etc and the files in /lib/systemd/system/
> I would say that we should follow what the major distribution are
> doing. I assume they already had discussion on how to organize theses
> files.
FYI, what I learned at ELC-E is that systemd is moving towards being able to
boot with a completely empty /etc. This will allow /etc to be a tmpfs in itself,
or if some configuration needs to be persistent it can be a writable fs and you
can do a factory reset by wiping it. There is some support in the latest systemd
to copy in a skeleton /etc when /etc is empty.
So with this in mind, a systemd setup would put as little as possible in /etc.
Regards,
Arnout
[snip]
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286500
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Buildroot] systemd: write-up and packaging questions
2014-10-21 18:41 ` Arnout Vandecappelle
@ 2014-10-21 18:45 ` Maxime Hadjinlian
0 siblings, 0 replies; 9+ messages in thread
From: Maxime Hadjinlian @ 2014-10-21 18:45 UTC (permalink / raw)
To: buildroot
On Oct 21, 2014 8:41 PM, "Arnout Vandecappelle" <arnout@mind.be> wrote:
>
> On 17/10/14 12:07, Maxime Hadjinlian wrote:
> > Hello Hiram, all
> >
> > On Fri, Oct 17, 2014 at 10:21 AM, Paassen, Hiram van
> > <Hiram.van.Paassen@mastervolt.com> wrote:
> >> On zo, 2014-10-12 at 21:12 +0200, Maxime Hadjinlian wrote:
> >>> Hi Andr?, All
> >>>
> >>> On Sun, Oct 12, 2014 at 7:59 PM, Andr? Erdmann <dywi@mailerd.de>
wrote:
> [snip]
> >>>> Installation
> >>>> ------------
> >>>>
> >>>> systemd's libdir is /lib/system.
> >>>> Most unit files (.service et al) are installed to
/etc/systemd/system,
> >>>> systemd's own unit files are installed to /lib/systemd/system and
some
> >>>> packages(*) install their files to /usr/lib/systemd/system, which is
rather
> >>>> confusing. Either dir works (search order is /etc > /lib > /usr/lib),
> >>>> but what's the recommended location?
> >>> If I'm reading the FHS correctly, /usr/lib/systemd/ would the the
> >>> targets and what nots for systemd itself, and so everything in /etc is
> >>> hosts specific so I would keep everything installed by our packages in
> >>> /etc/systemd/system.
> >> I think this depends on your viewpoint:
> >> /usr/lib is for "distros" since you might say that buildroot is
> >> generating a custom distro I would say that one might want to
> >> use /usr/lib
> >>
> >> This keeps /etc/ for making persistent changes based on individual
> >> systems and /run/ for making non persistent changes
> >>
> >> systemd itself mostly uses /lib
> >>
> >> Also:
> >> See my other mail about systemctl for an hour ago (was unaware of this
> >> discussion) The script I'm referring to, taken from open-embedded
> >> uses /etc to install symlinks to.
> >> So open-embedded seems to have chosen /etc for enable-symlinks
> >> independent of where the original unit files are installed (as per
> >> systemctl behavior I suppose)
> > It usually what is done, yes. You get the symlinks in /etc and you
> > install your unit files and targets, where you feel they should be.
> > Debian has the symlinks in /etc and the files in /lib/systemd/system/
> > I would say that we should follow what the major distribution are
> > doing. I assume they already had discussion on how to organize theses
> > files.
>
> FYI, what I learned at ELC-E is that systemd is moving towards being
able to
> boot with a completely empty /etc. This will allow /etc to be a tmpfs in
itself,
> or if some configuration needs to be persistent it can be a writable fs
and you
> can do a factory reset by wiping it. There is some support in the latest
systemd
> to copy in a skeleton /etc when /etc is empty.
>
> So with this in mind, a systemd setup would put as little as possible in
/etc.
>
In the v2 of my series to include the install of the services to
pkg-generic.mk I changed the install path to /lib/systems/system/
That would already be a step in, if not the right, at least a direction.
>
> Regards,
> Arnout
>
>
> [snip]
>
>
> --
> Arnout Vandecappelle arnout at mind be
> Senior Embedded Software Architect +32-16-286500
> Essensium/Mind http://www.mind.be
> G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
> LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
> GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20141021/0bf21ff3/attachment.html>
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2014-10-21 18:45 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-10-12 17:59 [Buildroot] systemd: write-up and packaging questions André Erdmann
2014-10-12 19:12 ` Maxime Hadjinlian
2014-10-17 8:21 ` Paassen, Hiram van
2014-10-17 9:15 ` André Erdmann
2014-10-17 10:07 ` Maxime Hadjinlian
2014-10-21 18:41 ` Arnout Vandecappelle
2014-10-21 18:45 ` Maxime Hadjinlian
2014-10-15 18:24 ` Arnout Vandecappelle
2014-10-17 6:32 ` André Erdmann
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.