Re: [systemd-devel] minimal required units
В Fri, 13 Mar 2015 08:31:44 -0700 aaron_wri...@selinc.com пишет: > > > > I'm concerned because I left out local-fs.target to begin with, as I > don't > > > need systemd to mount anything, but that seemed to cause systemd to > > > unmount everything other than / and the kernel file systems. > > > > Sorry, that does not fit. Either you "do not need to mount anything" or > > "systemd unmount everything". What was there to unmount if you did not > > mount anything in the first place? > > I mount / and /var in initrd, and then switch to the new root. systemd > then proceeded to unmount /var, but it didn't really tell me why. After I > included the local-fs.target on the box, that strange behavior stopped, > and /var remains mounted. I can't really explain that one. > The unmounting after initrd should have been fixed in commit I mentioned. As to why it did not happen with local-fs.target is impossible to answer without seeing logs. But I suspect it simply changed relative timings on startup, so it was just by accident. Could upload logs with systemd.log-level=debug with and without local-fs.target somewhere? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Possible systemd segfault switching from 216 to 219 in fedora upgrade
В Fri, 13 Mar 2015 16:38:33 -0600 Chris Murphy пишет: > On Fri, Mar 13, 2015 at 3:59 PM, Will Woods wrote: > > I don't really like the new->old->new switchroot stuff, but I haven't > > got a better solution at the moment. > > > > But: if we could use something like "systemd-nspawn" to: > > > > 1) start your old system in a container, > > 2) let it mount its disks, > > 3) copy/bind/move those mounts back out to the host somehow > > Quite a while ago I suggested to Richard Hughes the idea of using > systemd-nspawn and snapshots to get fully atomic updates when on LVM > thinp volumes or Btrfs. It can work for major upgrades also. > > First snapshot existing trees, start a container, mount the snapshots, > update/upgrade them. If it fails, destroy the snapshots. If it > succeeds, update bootloader config to boot the snapshots, and notify > user for reboot. > You do not really need snapshots for this. You just need extra space to copy current boot environment. Using snapshots just allows to do it with less space needed. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] journald on embedded systems
Getting inspiration from what you are proposing, you can already forward messages to a datagram socket (syslog). You could implement a program to empty out the datagram socket and only write the messages you want. Syslog format doesnt know anything about FIELD though. One down side of this implementation is that your program will be woken up for every message causing extra context switch. Regardless off this, it is interesting to hear out the thoughts about filtering. There have been discussions about per service filtering too. Umut On Friday, March 13, 2015, Chris Morgan wrote: > Hello. > > I posted this, > http://lists.freedesktop.org/archives/systemd-devel/2013-July/011926.html, > some time ago about tiered logging for embedded systems. > > The goal is to guarantee that the flash memory will last the duration > of the product by carefully controlling who writes to it. > > I'm back looking at the issue and wanted to re-open the discussion. > > One approach that came up would be to set "Storage=volatile", a limit > of say "10MB" for the journal size, and then write a separate program > that would filter out the journal entries and write them to a file on > a physical disk. The filtering portion is required as we are using the > journal to persist some important information that we'd like to log. > We'd also like to preserve high priority messages but don't mind if we > lose low priority ones across reboots. > > An upside of the external program is that we can filter on both high > priority messages as well as those with specific "FIELD=value" > entries. Downside is a custom format file and can't use journalctl to > search through it, no log rotation, no size limits etc. > > At the time there was some thought of putting this into journald > itself. I'm wondering how that would fit given the desire to use more > complicated matching to decide which entries were put into the > persisted journal. > > If it would fit inside of journald I'd be willing to implement it but > we would need to come up with a way to configure the filtering, where > the files are persisted etc. The filtering is a new requirement since > the last time this was discussed. > > Chris > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/systemd-devel > ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] selinux: fix SEGV during switch-root if SELinux policy loaded
On Fri, Mar 13, 2015 at 05:24:46PM -0400, Will Woods wrote:
> If you've got SELinux policy loaded, label_hnd is your labeling handle.
> When systemd is shutting down, we free that handle via mac_selinux_finish().
>
> But: switch_root() calls mkdir_p_label(), which tries to look up a label
> using that freed handle, and so we get a bunch of garbage and eventually
> SEGV in libselinux.
>
> (This doesn't happen in the switch-root from initramfs to real root because
> there's no SELinux policy loaded in initramfs, so label_hnd is NULL and we
> never attempt any lookups.)
>
> So: make sure that mac_selinux_finish() actually sets label_hnd to NULL, so
> nobody tries to use it after it becomes invalid.
>
> Resolves: RHBZ#1185604
> ---
> src/shared/selinux-util.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/src/shared/selinux-util.c b/src/shared/selinux-util.c
> index a8d5fc4..7c58985 100644
> --- a/src/shared/selinux-util.c
> +++ b/src/shared/selinux-util.c
> @@ -116,6 +116,7 @@ void mac_selinux_finish(void) {
> return;
>
> selabel_close(label_hnd);
> +label_hnd = NULL;
> #endif
Thanks for finding this. Patch applied.
Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] journald on embedded systems
On Fri, Mar 13, 2015 at 06:35:38PM -0400, Chris Morgan wrote: > Hello. > > I posted this, > http://lists.freedesktop.org/archives/systemd-devel/2013-July/011926.html, > some time ago about tiered logging for embedded systems. > > The goal is to guarantee that the flash memory will last the duration > of the product by carefully controlling who writes to it. > > I'm back looking at the issue and wanted to re-open the discussion. > > One approach that came up would be to set "Storage=volatile", a limit > of say "10MB" for the journal size, and then write a separate program > that would filter out the journal entries and write them to a file on > a physical disk. You should be able to do something like this right now with journal-remote: journalctl --directory /run/log/ -o export | \ systemd-journal-remote -o /var/log// - This is a bit too hacky to put into production, and it would be better to have a single binary which does this. But all the parts are there: - following the journal and filtering, - opening of specific directory as input, - saving of state (i.e. the last cursor written), - writing to a directory and rotating files the same as journald does. So adding a new binary (or extending one of the existing ones) supporting your use case would be a matter of hooking stuff together. > The filtering portion is required as we are using the > journal to persist some important information that we'd like to log. > We'd also like to preserve high priority messages but don't mind if we > lose low priority ones across reboots. > > An upside of the external program is that we can filter on both high > priority messages as well as those with specific "FIELD=value" > entries. Downside is a custom format file and can't use journalctl to > search through it, no log rotation, no size limits etc. > > At the time there was some thought of putting this into journald > itself. I'm wondering how that would fit given the desire to use more > complicated matching to decide which entries were put into the > persisted journal. Adding filtering and splitting functionality to journald is another story of course. It probably would work better: more efficent, and journal entries would not be duplicated at all. > If it would fit inside of journald I'd be willing to implement it but > we would need to come up with a way to configure the filtering, where > the files are persisted etc. The filtering is a new requirement since > the last time this was discussed. I think that supporting a set of similar filters to journalctl would be a good start. Options which limit the number of messages or filter based on time would not make sense for journald, but most other probably would. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] sd_event_run
On Fri, Mar 13, 2015 at 06:10:17PM +0100, Tom Gundersen wrote:
> On Fri, Mar 13, 2015 at 4:35 PM, Zbigniew Jędrzejewski-Szmek
> wrote:
> > you added sd_event_run a while ago:
> >
> > commit c45a5a74465a39280b855f9d720b2ab4779a47fa
> > Author: Tom Gundersen
> > Date: Fri Aug 15 18:49:29 2014 +0200
> >
> > sd-event: split run into prepare/wait/dispatch
> >
> > This will allow sd-event to be integrated into an external event loop,
> > which
> > in turn will allow (say) glib-based applications to use our various
> > libraries,
> > without manually integrating each of them (bus, rtnl, dhcp, ...).
> >
> > The external event-loop should integrate sd-event int he following way:
> >
> > Every iteration must start with a call to sd_event_prepare(), which will
> > return 0 if no event sources are ready to be processed, a positive
> > value if
> > they are and a negative value on error. sd_event_prepare() may only be
> > called
> > following sd_event_dispatch(); a call to sd_event_wait() indicating
> > that no
> > sources are ready to be dispatched; or a failed call to
> > sd_event_dispatch() or
> > sd_event_wait().
> >
> > A successful call to sd_event_prepare() indicating that no event
> > sources are
> > ready to be dispatched must be followed by a call to sd_event_wait(),
> > which will return 0 if it timed out without event sources being ready to
> > be processed, a negative value on error and a positive value otherwise.
> > sd_event_wait() may only be called following a successful call to
> > sd_event_prepare() indicating that no event sources are ready to be
> > dispatched.
> >
> > If sd_event_wait() indicates that some events sources are ready to be
> > dispatched, it must be followed by a call to sd_event_dispatch(). This
> > is the only time sd_event_dispatch() may be called.
> >
> > +_public_ int sd_event_run(sd_event *e, uint64_t timeout) {
> > +int r;
> > +
> > +assert_return(e, -EINVAL);
> > +assert_return(!event_pid_changed(e), -ECHILD);
> > +assert_return(e->state != SD_EVENT_FINISHED, -ESTALE);
> > +assert_return(e->state == SD_EVENT_PASSIVE, -EBUSY);
> > +
> > +r = sd_event_prepare(e);
> > +if (r > 0)
> > +return sd_event_dispatch(e);
> > +else if (r < 0)
> > +return r;
> > +
> > +r = sd_event_wait(e, timeout);
> > +if (r > 0)
> > +return sd_event_dispatch(e);
> > +else
> > +return r;
> > +}
> >
> > Your commit description is almost ready to be turned into a man page, but
> > there
> > a hiccup. According to the last paragraph of the commit message,
> > sd_event_dispatch may
> > only be called after sd_event_wait(). This contradict the code in
> > sd_event_run().
> > (sd_event_dispatch calls sd_event_wait internally, but the user does not
> > know
> > this). Can you clarify the intended rules?
>
> Indeed. Perhaps the best way to explain it is to look at the states:
>
> SD_EVENT_PASSIVE,
> SD_EVENT_PREPARED,
> SD_EVENT_PENDING,
> SD_EVENT_FINISHED,
There's also SD_EVENT_RUNNING. It probably should be documented too,
but I didn't include it in the description of
sd_event_{run,wait,prepare,dispatch,loop}.
A draft is attached, please have a look. After writing it I had some thoughts:
1. shouldn't SD_EVENT_PASSIVE become SD_EVENT_INITIAL? "passive" seems strange
in this context.
Similarly, SD_EVENT_ARMED seems more self-explanatory than PREPARED.
(I don't like PREPARED because it is not obvious whether sources are
prepared to wait on, or events are prepared to be reaped.)
2. shouldn't sd_event_dispatch also return 0/1 to signify e.g.
loop-continues / loop-finished. Right now other functions return
the state as return value, but sd_event_dispatch requires querying
the event object for state.
Zbyszek
>From e480acbe4e78f0ca504751b948b66d6adbfbfc67 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Zbigniew=20J=C4=99drzejewski-Szmek?=
Date: Fri, 13 Mar 2015 21:35:32 -0400
Subject: [PATCH] man: add sd_event_{run,wait,prepare,dispatch,loop}
---
Makefile-man.am | 19 +
man/sd_event_run.xml | 179
man/sd_event_wait.xml | 203 ++
3 files changed, 401 insertions(+)
create mode 100644 man/sd_event_run.xml
create mode 100644 man/sd_event_wait.xml
diff --git a/Makefile-man.am b/Makefile-man.am
index 7a9612e311..ab1db33c01 100644
--- a/Makefile-man.am
+++ b/Makefile-man.am
@@ -810,7 +810,9 @@ MANPAGES += \
man/sd_event_add_time.3 \
man/sd_event_get_fd.3 \
man/sd_event_new.3 \
+ man/sd_event_run.3 \
man/sd_event_set_name.3 \
+ man/sd_event_wait.3 \
man/systemd-bus-proxyd.8 \
man/systemd-bus-proxyd@.service.8
MANPAGES_ALIAS += \
@@ -871,7 +873,10 @@ MANPAGES_ALIAS += \
man/sd_event_add_exit.3 \
man/sd_eve
Re: [systemd-devel] After=foo.busname oderings although kdbus is disabled
On Sat, Mar 14, 2015 at 01:41:16AM +0100, Michael Biebl wrote: > Hi, > > in Debian/Ubuntu, kdbus support is disabled. > With version 219 I see the following e.g. for avahi-daemon.service > > After=basic.target org.freedesktop.Avahi.busname avahi-daemon.socket > systemd-journald.socket system.slice > > > Why is there an After=org.freedesktop.Avahi.busname ordering? Bug? Yep. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] After=foo.busname oderings although kdbus is disabled
Hi, in Debian/Ubuntu, kdbus support is disabled. With version 219 I see the following e.g. for avahi-daemon.service After=basic.target org.freedesktop.Avahi.busname avahi-daemon.socket systemd-journald.socket system.slice Why is there an After=org.freedesktop.Avahi.busname ordering? Bug? Michael -- 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] Possible systemd segfault switching from 216 to 219 in fedora upgrade
On Fri, Mar 13, 2015 at 3:59 PM, Will Woods wrote: > I don't really like the new->old->new switchroot stuff, but I haven't > got a better solution at the moment. > > But: if we could use something like "systemd-nspawn" to: > > 1) start your old system in a container, > 2) let it mount its disks, > 3) copy/bind/move those mounts back out to the host somehow Quite a while ago I suggested to Richard Hughes the idea of using systemd-nspawn and snapshots to get fully atomic updates when on LVM thinp volumes or Btrfs. It can work for major upgrades also. First snapshot existing trees, start a container, mount the snapshots, update/upgrade them. If it fails, destroy the snapshots. If it succeeds, update bootloader config to boot the snapshots, and notify user for reboot. A further refinement could even be a systemd-nspawn "reboot" of the upgraded snapshots as a test. If that fails, log some details of the failure, destroy the bad snapshots. If it succeeds, update bootloader config. In any case, the existing fs trees are untouched. So it also eliminates the multiple reboots requirement, and even eliminate the necessary timely reboot. The user can continue to fully use the existing tree indefinitely. It's similar to OSTree/Project Atomic in concept. This is actually my usual update procedure, except I've only done it old school style with chroot so far. Container would be a more deterministic environment and thus more reliable I think. Both Btrfs and LVM thinp snapshots are completely independent fs trees, so there's no parent-child distinction, which is what makes this upgrade process viable. -- Chris Murphy ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] journald on embedded systems
Hello. I posted this, http://lists.freedesktop.org/archives/systemd-devel/2013-July/011926.html, some time ago about tiered logging for embedded systems. The goal is to guarantee that the flash memory will last the duration of the product by carefully controlling who writes to it. I'm back looking at the issue and wanted to re-open the discussion. One approach that came up would be to set "Storage=volatile", a limit of say "10MB" for the journal size, and then write a separate program that would filter out the journal entries and write them to a file on a physical disk. The filtering portion is required as we are using the journal to persist some important information that we'd like to log. We'd also like to preserve high priority messages but don't mind if we lose low priority ones across reboots. An upside of the external program is that we can filter on both high priority messages as well as those with specific "FIELD=value" entries. Downside is a custom format file and can't use journalctl to search through it, no log rotation, no size limits etc. At the time there was some thought of putting this into journald itself. I'm wondering how that would fit given the desire to use more complicated matching to decide which entries were put into the persisted journal. If it would fit inside of journald I'd be willing to implement it but we would need to come up with a way to configure the filtering, where the files are persisted etc. The filtering is a new requirement since the last time this was discussed. Chris ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Possible systemd segfault switching from 216 to 219 in fedora upgrade
On Tue, 2015-03-10 at 17:21 +0100, Lennart Poettering wrote: > My recommendation would be to use the offline updates logic we have in > systemd already: > > http://www.freedesktop.org/wiki/Software/systemd/SystemUpdates/ > > systemd has been implementing this for quite a while, at least for all > systems fedup should care for. In this scheme you mark the system for > upgrades, you reboot using the old kernel/initrd. This will now enter > the special upgrade mode, where you make your changes, and then you > reboot again with the new kernel. Yeah, I really wanted that to work, but... when you're replacing literally the entire system *while* part of it is running, stuff gets a little weird. All my efforts to make major-version upgrades work from the system-updates hook ended in weird crashes due to libraries being replaced out from under running binaries, etc. At this point people usually say: "Hmm, maybe you need a minimal system you can chroot into and run the upgrade from?" ..and that's exactly what the upgrade.img initramfs is! We just need to be able to switch-root from your running system into an upgrade image.. *WITH* your disks mounted in it. I don't really like the new->old->new switchroot stuff, but I haven't got a better solution at the moment. But: if we could use something like "systemd-nspawn" to: 1) start your old system in a container, 2) let it mount its disks, 3) copy/bind/move those mounts back out to the host somehow Then we wouldn't need to do the double-switchroot. I couldn't find a way to make that work a couple of years ago, but maybe it's something that we could figure out now? > > Analysis of that makes it clear it's the mkdir_p_label function that > > causes libselinux.so to do a type lookup on the path to segfault (at a > > strcmp in selinux_sub) which then bubbles back up as an underlying > > issue in this case. > > Do you have a full backtrace for this? > > Which mkdir_p_label() invocation is this? It's the mkdir_p_label() in switch_root(). It happens after mac_selinux_finish(), but mac_selinux_finish() doesn't set label_hnd=NULL, so it crashes due to use-after-free. This only happens if you're doing switch-root *from* a system with SELinux policy loaded, which explains why nobody else saw it. (See https://bugzilla.redhat.com/show_bug.cgi?id=1185604 for the backtrace or my other mail for a patch.) -w ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] selinux: fix SEGV during switch-root if SELinux policy loaded
If you've got SELinux policy loaded, label_hnd is your labeling handle.
When systemd is shutting down, we free that handle via mac_selinux_finish().
But: switch_root() calls mkdir_p_label(), which tries to look up a label
using that freed handle, and so we get a bunch of garbage and eventually
SEGV in libselinux.
(This doesn't happen in the switch-root from initramfs to real root because
there's no SELinux policy loaded in initramfs, so label_hnd is NULL and we
never attempt any lookups.)
So: make sure that mac_selinux_finish() actually sets label_hnd to NULL, so
nobody tries to use it after it becomes invalid.
Resolves: RHBZ#1185604
---
src/shared/selinux-util.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/shared/selinux-util.c b/src/shared/selinux-util.c
index a8d5fc4..7c58985 100644
--- a/src/shared/selinux-util.c
+++ b/src/shared/selinux-util.c
@@ -116,6 +116,7 @@ void mac_selinux_finish(void) {
return;
selabel_close(label_hnd);
+label_hnd = NULL;
#endif
}
--
2.1.0
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Enabling timesyncd in virtual machines
Greetings, Currently systemd-timesyncd.service includes ConditionVirtualization=no, disabling it in both containers and virtual machines. Each VM platform tends to deal with or ignore the time problem in their own special ways, KVM/QEMU has the kernel time source kvm-clock, Xen has had different schemes over the years, VMware expects a userspace daemon sync the clock, and other platforms are content to drift with the wind as far as I can tell. I don't know of a robust way to know if a platform needs a little extra help from userspace to keep the clock sane or not but it seems generally safer to try than to risk drifting. Does anyone know of a reason to leave timesyncd off by default? Otherwise switching to ConditionVirtualization=!container should be reasonable. Thanks, Mike ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] network: add UseNTP DHCP option
Despite having the internal logic in place to enable/disable using NTP servers provided by DHCP the network config didn't expose the option. --- man/systemd.network.xml | 8 src/network/networkd-network-gperf.gperf | 1 + 2 files changed, 9 insertions(+) diff --git a/man/systemd.network.xml b/man/systemd.network.xml index 5d7518b..95be132 100644 --- a/man/systemd.network.xml +++ b/man/systemd.network.xml @@ -515,6 +515,14 @@ + UseNTP= + +When true (the default), the NTP servers received +from the DHCP server will be used by systemd-timesyncd +and take precedence over any statically configured ones. + + + UseMTU= When true, the interface maximum transmission unit diff --git a/src/network/networkd-network-gperf.gperf b/src/network/networkd-network-gperf.gperf index 93df83a..8abf5bc 100644 --- a/src/network/networkd-network-gperf.gperf +++ b/src/network/networkd-network-gperf.gperf @@ -60,6 +60,7 @@ Route.Metric,config_parse_route_priority, 0, Route.Scope, config_parse_route_scope, 0, 0 DHCP.ClientIdentifier, config_parse_dhcp_client_identifier,0, offsetof(Network, dhcp_client_identifier) DHCP.UseDNS, config_parse_bool, 0, offsetof(Network, dhcp_dns) +DHCP.UseNTP, config_parse_bool, 0, offsetof(Network, dhcp_ntp) DHCP.UseMTU, config_parse_bool, 0, offsetof(Network, dhcp_mtu) DHCP.UseHostname,config_parse_bool, 0, offsetof(Network, dhcp_hostname) DHCP.UseDomains, config_parse_bool, 0, offsetof(Network, dhcp_domains) -- 2.0.5 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] vconsole-setup: check error of child process
From: Lucas De Marchi
If we don't check the error of the child process, systemd-vconsole-setup
would exit with 0 even if it could not really setup the console.
For a simple test, move loadkeys elsewhere and execute
systemd-vconsole-setup:
[root@localhost ~]# strace -f -e execve
/usr/lib/systemd/systemd-vconsole-setup
execve("/usr/lib/systemd/systemd-vconsole-setup",
["/usr/lib/systemd/systemd-vconsol"...], [/* 15 vars */]) = 0
Process 171 attached
[pid 171] execve("/usr/bin/loadkeys", ["/usr/bin/loadkeys", "-q",
"-C", "/dev/tty0", "br-abnt2"], [/* 15 vars */]) = -1 ENOENT (No such file or
directory)
[pid 171] +++ exited with 1 +++
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=171,
si_uid=0, si_status=1, si_utime=0, si_stime=0} ---
+++ exited with 0 +++
Note that loadkeys returned 1 while systemd-vconsole-setup return 0.
Since the font and keyboard setup are already serialized, refactor the
code a little bit so the functions do the wait by themselves. One change
in behavior in this patch is that we don't return early, but we do try
to setup the keyboard even if the font load failed.
---
src/vconsole/vconsole-setup.c | 68 +++
1 file changed, 24 insertions(+), 44 deletions(-)
diff --git a/src/vconsole/vconsole-setup.c b/src/vconsole/vconsole-setup.c
index bf681d9..fe8573f 100644
--- a/src/vconsole/vconsole-setup.c
+++ b/src/vconsole/vconsole-setup.c
@@ -96,16 +96,14 @@ static int enable_utf8(int fd) {
return r;
}
-static int keymap_load(const char *vc, const char *map, const char
*map_toggle, bool utf8, pid_t *_pid) {
+static bool keyboard_load_and_wait(const char *vc, const char *map, const char
*map_toggle, bool utf8) {
const char *args[8];
int i = 0;
pid_t pid;
-if (isempty(map)) {
-/* An empty map means kernel map */
-*_pid = 0;
-return 0;
-}
+/* An empty map means kernel map */
+if (isempty(map))
+return true;
args[i++] = KBD_LOADKEYS;
args[i++] = "-q";
@@ -119,27 +117,25 @@ static int keymap_load(const char *vc, const char *map,
const char *map_toggle,
args[i++] = NULL;
pid = fork();
-if (pid < 0)
-return log_error_errno(errno, "Failed to fork: %m");
-else if (pid == 0) {
+if (pid < 0) {
+log_error_errno(errno, "Failed to fork: %m");
+return false;
+} else if (pid == 0) {
execv(args[0], (char **) args);
_exit(EXIT_FAILURE);
}
-*_pid = pid;
-return 0;
+return wait_for_terminate_and_warn(KBD_LOADKEYS, pid, true) == 0;
}
-static int font_load(const char *vc, const char *font, const char *map, const
char *unimap, pid_t *_pid) {
+static bool font_load_and_wait(const char *vc, const char *font, const char
*map, const char *unimap) {
const char *args[9];
int i = 0;
pid_t pid;
-if (isempty(font)) {
-/* An empty font means kernel font */
-*_pid = 0;
-return 0;
-}
+/* An empty font means kernel font */
+if (isempty(font))
+return true;
args[i++] = KBD_SETFONT;
args[i++] = "-C";
@@ -156,15 +152,15 @@ static int font_load(const char *vc, const char *font,
const char *map, const ch
args[i++] = NULL;
pid = fork();
-if (pid < 0)
-return log_error_errno(errno, "Failed to fork: %m");
-else if (pid == 0) {
+if (pid < 0) {
+log_error_errno(errno, "Failed to fork: %m");
+return false;
+} else if (pid == 0) {
execv(args[0], (char **) args);
_exit(EXIT_FAILURE);
}
-*_pid = pid;
-return 0;
+return wait_for_terminate_and_warn(KBD_SETFONT, pid, true) == 0;
}
/*
@@ -238,8 +234,7 @@ int main(int argc, char **argv) {
*vc_font = NULL, *vc_font_map = NULL, *vc_font_unimap = NULL;
_cleanup_close_ int fd = -1;
bool utf8;
-pid_t font_pid = 0, keymap_pid = 0;
-bool font_copy = false;
+bool font_copy = false, font_ok, keyboard_ok;
int r = EXIT_FAILURE;
log_set_target(LOG_TARGET_AUTO);
@@ -298,27 +293,12 @@ int main(int argc, char **argv) {
else
disable_utf8(fd);
-r = font_load(vc, vc_font, vc_font_map, vc_font_unimap, &font_pid);
-if (r < 0) {
-log_error_errno(r, "Failed to start " KBD_SETFONT ": %m");
-return EXIT_FAILURE;
-}
-
-if (font_pid > 0)
-wait_for_terminate_and_warn(KBD_SETFONT, font_pid, true);
-
-r = keymap_load(vc, vc_keymap, vc_keymap_toggle, utf8, &keymap_pid);
-
[systemd-devel] [PATCH] journal: Introduce journal-network
This tiny daemon enables to pull journal entries and push to a UDP multicast address in syslog RFC 5424 format. journal-syslog-network runs with own user systemd-journal-push. It starts running after the network is up. --- Makefile-man.am| 8 + Makefile.am| 40 ++ man/systemd-journal-network.service.xml| 84 + man/systemd-journal-network.xml| 115 ++ src/journal-remote/journal-network-conf.c | 61 src/journal-remote/journal-network-conf.h | 32 ++ src/journal-remote/journal-network-gperf.gperf | 18 + src/journal-remote/journal-network-manager.c | 481 + src/journal-remote/journal-network-manager.h | 70 src/journal-remote/journal-network-proto.c | 218 +++ src/journal-remote/journal-network.c | 218 +++ src/journal-remote/journal-network.conf.in | 2 + units/systemd-journal-network.service.in | 19 + 13 files changed, 1366 insertions(+) create mode 100644 man/systemd-journal-network.service.xml create mode 100644 man/systemd-journal-network.xml create mode 100644 src/journal-remote/journal-network-conf.c create mode 100644 src/journal-remote/journal-network-conf.h create mode 100644 src/journal-remote/journal-network-gperf.gperf create mode 100644 src/journal-remote/journal-network-manager.c create mode 100644 src/journal-remote/journal-network-manager.h create mode 100644 src/journal-remote/journal-network-proto.c create mode 100644 src/journal-remote/journal-network.c create mode 100644 src/journal-remote/journal-network.conf.in create mode 100644 units/systemd-journal-network.service.in diff --git a/Makefile-man.am b/Makefile-man.am index 7a9612e..efd0cbc 100644 --- a/Makefile-man.am +++ b/Makefile-man.am @@ -1357,6 +1357,14 @@ man/systemd-journal-gatewayd.socket.html: man/systemd-journal-gatewayd.service.h endif +MANPAGES += \ +man/systemd-journal-network.service.8 \ +man/systemd-journal-network.8 +MANPAGES_ALIAS += \ +man/systemd-journal-network.8 +man/systemd-journal-network.8: man/systemd-journal-network.service.8 +man/systemd-journal-network.html: man/systemd-journal-network.service.html + if HAVE_MYHOSTNAME MANPAGES += \ man/nss-myhostname.8 diff --git a/Makefile.am b/Makefile.am index 856accb..ad1dff5 100644 --- a/Makefile.am +++ b/Makefile.am @@ -4336,6 +4336,46 @@ EXTRA_DIST += \ src/journal-remote/journal-upload.conf.in endif +rootlibexec_PROGRAMS += \ + systemd-journal-network + +systemd_journal_network_SOURCES = \ + src/journal-remote/journal-network-manager.h \ + src/journal-remote/journal-network-manager.c \ + src/journal-remote/journal-network-conf.h \ + src/journal-remote/journal-network-conf.c \ + src/journal-remote/journal-network-proto.c \ + src/journal-remote/journal-network.c + +nodist_systemd_journal_network_SOURCES = \ + src/journal-remote/journal-network-gperf.c + +EXTRA_DIST += \ +src/journal-remote/journal-network-gperf.gperf + +CLEANFILES += \ +src/journal-remote/journal-network-gperf.c + +systemd_journal_network_LDADD = \ + libsystemd-internal.la \ + libsystemd-journal-internal.la \ + libsystemd-shared.la + +nodist_systemunit_DATA += \ + units/systemd-journal-network.service + +EXTRA_DIST += \ + units/systemd-journal-network.service.in + +nodist_pkgsysconf_DATA += \ + src/journal-remote/journal-network.conf + +EXTRA_DIST += \ + src/journal-remote/journal-network.conf.in + +CLEANFILES += \ + src/journal-remote/journal-network.conf + # using _CFLAGS = in the conditional below would suppress AM_CFLAGS journalctl_CFLAGS = \ $(AM_CFLAGS) diff --git a/man/systemd-journal-network.service.xml b/man/systemd-journal-network.service.xml new file mode 100644 index 000..47a5b3e --- /dev/null +++ b/man/systemd-journal-network.service.xml @@ -0,0 +1,84 @@ + +http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd";> + + + +http://www.w3.org/2001/XInclude";> + + +systemd-journal-network.service +systemd + + + +Developer +Susant +Sahani +ssah...@gmail.com + + + + + +systemd-journal-network.service +8 + + + +systemd-journal-network.service +systemd-journal-network +Syslog Client for journal events + + + +systemd-journal-network.service + + /usr/lib/systemd/systemd-journal-network + OPTIONS + + + + +Description + +systemd-journal-network serves journal +events over the network. It multicasts journal event to Syslog RFC 5424 format. + + +The program is started by + systemd1 + . Use +systemctl start systemd-journal-network.service to start +the service, and systemctl enable systemd-journal-network.service +to have it started on boot. + + + +See
Re: [systemd-devel] sd_event_run
On Fri, Mar 13, 2015 at 4:35 PM, Zbigniew Jędrzejewski-Szmek
wrote:
> you added sd_event_run a while ago:
>
> commit c45a5a74465a39280b855f9d720b2ab4779a47fa
> Author: Tom Gundersen
> Date: Fri Aug 15 18:49:29 2014 +0200
>
> sd-event: split run into prepare/wait/dispatch
>
> This will allow sd-event to be integrated into an external event loop,
> which
> in turn will allow (say) glib-based applications to use our various
> libraries,
> without manually integrating each of them (bus, rtnl, dhcp, ...).
>
> The external event-loop should integrate sd-event int he following way:
>
> Every iteration must start with a call to sd_event_prepare(), which will
> return 0 if no event sources are ready to be processed, a positive value
> if
> they are and a negative value on error. sd_event_prepare() may only be
> called
> following sd_event_dispatch(); a call to sd_event_wait() indicating that
> no
> sources are ready to be dispatched; or a failed call to
> sd_event_dispatch() or
> sd_event_wait().
>
> A successful call to sd_event_prepare() indicating that no event sources
> are
> ready to be dispatched must be followed by a call to sd_event_wait(),
> which will return 0 if it timed out without event sources being ready to
> be processed, a negative value on error and a positive value otherwise.
> sd_event_wait() may only be called following a successful call to
> sd_event_prepare() indicating that no event sources are ready to be
> dispatched.
>
> If sd_event_wait() indicates that some events sources are ready to be
> dispatched, it must be followed by a call to sd_event_dispatch(). This
> is the only time sd_event_dispatch() may be called.
>
> +_public_ int sd_event_run(sd_event *e, uint64_t timeout) {
> +int r;
> +
> +assert_return(e, -EINVAL);
> +assert_return(!event_pid_changed(e), -ECHILD);
> +assert_return(e->state != SD_EVENT_FINISHED, -ESTALE);
> +assert_return(e->state == SD_EVENT_PASSIVE, -EBUSY);
> +
> +r = sd_event_prepare(e);
> +if (r > 0)
> +return sd_event_dispatch(e);
> +else if (r < 0)
> +return r;
> +
> +r = sd_event_wait(e, timeout);
> +if (r > 0)
> +return sd_event_dispatch(e);
> +else
> +return r;
> +}
>
> Your commit description is almost ready to be turned into a man page, but
> there
> a hiccup. According to the last paragraph of the commit message,
> sd_event_dispatch may
> only be called after sd_event_wait(). This contradict the code in
> sd_event_run().
> (sd_event_dispatch calls sd_event_wait internally, but the user does not know
> this). Can you clarify the intended rules?
Indeed. Perhaps the best way to explain it is to look at the states:
SD_EVENT_PASSIVE,
SD_EVENT_PREPARED,
SD_EVENT_PENDING,
SD_EVENT_FINISHED,
*) sd_event starts off in SD_EVENT_PASSIVE
*) sd_event_prepare() may only be called from SD_EVENT_PASSIVE. If a
failure occurs a negative value is returned and the state remains
SD_EVENT_PASSIVE. If there are pending events a positive value is
returned and the state changes to SD_EVENT_PENDING. Otherwise, 0 is
returned and the state changes to SD_EVENT_PREPARED.
*) sd_event_wait() may only be called from SD_EVENT_PREPARED. If there
are pending events it returns a positive value and enters
SD_EVENT_PENDING. Otherwise, the state is is changed back to
SD_EVENT_PASSIVE and 0 is returned if there are no pending events and
a negative value is returned on error.
*) sd_event_dispatch() may only be called from SD_EVENT_PENDING. When
it returns the state has changed to SD_EVENT_PASSIVE or
SD_EVENT_FINISHED.
Does that make sense?
Cheers,
Tom
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] minimal required units
...snip... > > If I include at least all of the units leading up to basic.target, would > > that cover the units required by systemd? > > systemd does not really require anything. Really. *You* (or your > system) require something to be started during boot and only you know > what should be started. You can use single service that calls /etc/rc > as starting point and split it up step by step. > > Units shipped with systemd help to organize system startup in logical > steps and provide common hooks to plug your own extensions into. > Removing common hooks won't buy you anything but will make system less > flexible and harder to troubleshoot. Yes, I think I'm changing my point of view a bit. I'm coming from a busybox inittab world, where I only included just what I needed, and anything extra was doing something bad. You and Alison Chaiken have explained the systemd philosophy to me, so that I think I understand it much more. Thanks for taking the time. In order to get the proper configuration I want, I'm doing my own packaging for systemd. After the build, I cherry pick what I want installed on the box. It sounds like I need to stop cherry picking so much, and just install whole folders; such as: usr/lib/systemd/system/ etc/systemd/ And even though, that'll get me lots of units I'll never use, it'll be the safest bet for a smooth running systemd. Correct? ...snip... > > I'm concerned because I left out local-fs.target to begin with, as I don't > > need systemd to mount anything, but that seemed to cause systemd to > > unmount everything other than / and the kernel file systems. > > Sorry, that does not fit. Either you "do not need to mount anything" or > "systemd unmount everything". What was there to unmount if you did not > mount anything in the first place? I mount / and /var in initrd, and then switch to the new root. systemd then proceeded to unmount /var, but it didn't really tell me why. After I included the local-fs.target on the box, that strange behavior stopped, and /var remains mounted. I can't really explain that one. ...snip...___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] sd_event_run
Hi,
you added sd_event_run a while ago:
commit c45a5a74465a39280b855f9d720b2ab4779a47fa
Author: Tom Gundersen
Date: Fri Aug 15 18:49:29 2014 +0200
sd-event: split run into prepare/wait/dispatch
This will allow sd-event to be integrated into an external event loop, which
in turn will allow (say) glib-based applications to use our various
libraries,
without manually integrating each of them (bus, rtnl, dhcp, ...).
The external event-loop should integrate sd-event int he following way:
Every iteration must start with a call to sd_event_prepare(), which will
return 0 if no event sources are ready to be processed, a positive value if
they are and a negative value on error. sd_event_prepare() may only be
called
following sd_event_dispatch(); a call to sd_event_wait() indicating that no
sources are ready to be dispatched; or a failed call to sd_event_dispatch()
or
sd_event_wait().
A successful call to sd_event_prepare() indicating that no event sources are
ready to be dispatched must be followed by a call to sd_event_wait(),
which will return 0 if it timed out without event sources being ready to
be processed, a negative value on error and a positive value otherwise.
sd_event_wait() may only be called following a successful call to
sd_event_prepare() indicating that no event sources are ready to be
dispatched.
If sd_event_wait() indicates that some events sources are ready to be
dispatched, it must be followed by a call to sd_event_dispatch(). This
is the only time sd_event_dispatch() may be called.
+_public_ int sd_event_run(sd_event *e, uint64_t timeout) {
+int r;
+
+assert_return(e, -EINVAL);
+assert_return(!event_pid_changed(e), -ECHILD);
+assert_return(e->state != SD_EVENT_FINISHED, -ESTALE);
+assert_return(e->state == SD_EVENT_PASSIVE, -EBUSY);
+
+r = sd_event_prepare(e);
+if (r > 0)
+return sd_event_dispatch(e);
+else if (r < 0)
+return r;
+
+r = sd_event_wait(e, timeout);
+if (r > 0)
+return sd_event_dispatch(e);
+else
+return r;
+}
Your commit description is almost ready to be turned into a man page, but there
a hiccup. According to the last paragraph of the commit message,
sd_event_dispatch may
only be called after sd_event_wait(). This contradict the code in
sd_event_run().
(sd_event_dispatch calls sd_event_wait internally, but the user does not know
this). Can you clarify the intended rules?
Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Needs help for on charging activation
Hi Lennart,
Any comments?
We hope to assign our work with systemd one.
Thank you,
Kyungmin Park
On Monday, March 9, 2015, WaLyong Cho wrote:
> Hi,
>
> I want to find best solution on our case. Our product is mobile device.
> But I don't think that is only problem of mobile device. That also can
> be problem of laptop. So, please comment to me.
>
> We have some of services are always running after system is started up
> as default. They don't need to be running always. They are just needed
> only charger is plugged in.
> So I thought lets only active them when only charger is plugged in.
>
> I thought two methods.
>
> method 1:
> Charger also can be detected by udev. So udev hardware activation can be
> used.
> I wrote below udev rules.
>
> SUBSYSTEM=="power_supply", ENV{POWER_SUPPLY_CHARGE_NOW}=="1",
> TAG+="systemd", ENV{SYSTEMD_WANTS}+="foo.service"
>
> It looked working well. foo.service is only activated when charger was
> plugged in.
> But I have some of problems with hardware activation.
> I want to be stopped foo.service when the charger is plugged out. As I
> know, this is impossible with udev hardware activation.
> To do this, foo.service have to determine the charger state itself and
> if the charger is plugged out, it have to stop itself.
> And it is working only at the first time.
> After foo.service was activated, I stopped foo.service by "systemctl
> stop foo.service". And plug out and plug in the charger again. Then
> foo.service was not activated. (Is it normal? I did not try to find the
> reason. If you say it's a problem, then I will try to find.)
>
>
> method 2:
> We have another device daemon. Let's call that as deviced and its
> service name is deviced.service. deviced know about plug in/out of the
> charger.
> So, I made a new charging.target. foo.service have Wants= dependency for
> charging.target. (Installed on charging.target.wants.) And I added
> "BindsTo=charging.target" to foo.service.
> Then foo.service is activated well when the charging.target is entered
> to active state. And also deactivated when charging.target was deactivated.
>
> In this method, there are limitations what some of other daemon is
> needed and new charging.target is needed.
>
>
> Is there any more good way for this?
> I want to find best appropriate way.
>
> Thank you in advance for comment.
>
> WaLyong
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to factory reset?
On Fri, Mar 13, 2015 at 02:20:04PM +0100, Tobias Hunger wrote: > Hi Zbyszek, > > I would expect the machine-id to be written before mount units are > processed, so for that to work I would need to mount /var in the > initrd, wouldn't I? (Without looking at the code again) I don't think so. machine-id-setup is performed by PID1 itself, and I think it does it quite early. > Currently I am trying to just write the machine-id to /etc in the > initrd. This makes systemd loose the understanding that /etc is empty > though, which might have some side-effects that I am not yet > anticipating. Yeah, that does not seem like the right approach. > Isn't systemd started from inside the initrd once the new root has > been set up? Maybe I could set $container_uuid and feed the machine-id > to systemd that way? I am afraid that this will lead to some other > side-effects, because systemd might assume to be running inside a > container. Looks like I will have to do some testing over the > weekend:-) > > Maybe I am lucky and /sys/class/dmi/id/product_uuid is set. > > Best Regards, > Tobias Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to factory reset?
Hi Zbyszek, I would expect the machine-id to be written before mount units are processed, so for that to work I would need to mount /var in the initrd, wouldn't I? Currently I am trying to just write the machine-id to /etc in the initrd. This makes systemd loose the understanding that /etc is empty though, which might have some side-effects that I am not yet anticipating. Isn't systemd started from inside the initrd once the new root has been set up? Maybe I could set $container_uuid and feed the machine-id to systemd that way? I am afraid that this will lead to some other side-effects, because systemd might assume to be running inside a container. Looks like I will have to do some testing over the weekend:-) Maybe I am lucky and /sys/class/dmi/id/product_uuid is set. Best Regards, Tobias On Fri, Mar 13, 2015 at 1:16 AM, Zbigniew Jędrzejewski-Szmek wrote: > On Tue, Mar 10, 2015 at 10:23:23PM +0100, Tobias Hunger wrote: >> On Tue, Mar 10, 2015 at 9:33 PM, Tobias Hunger >> wrote: >> >> presets and machined ID are applied by PID 1, before it begins with >> >> starting any units, hence *really* early on. Note though that actually >> >> /etc/machine-id is used as flag for "is /etc empty". If the file >> >> exists it is assumed that /etc is provisioned properly. If it is >> >> missing PID 1 will generate the machiend id and apply presets. >> > >> > An OS installer could put the machine-id into /usr just fine (and so >> > can I) and systemd could just get it from there if available before >> > generating a new one. >> > >> > It would be nice if the machine-id did not change during to a factory >> > reset: It is used in the logs and changing it will basically make >> > historical log data much harder to analyze. IIRC networkd also uses it >> > to generate persistent MAC addresses for containers and such. >> > >> > So far this seems to be the only critical piece of information that >> > can not get restored via tmpfiles.d. >> >> Thinking about this a bit longer: /usr does not seem like a good idea. >> The machine-id is supposed to be unique and usr-images are meant to be >> reused. >> >> Maybe provide a kernel command line option to force the machine-id if >> none is set yet? > I think this could be an option. We currently check > /var/lib/dbus/machine-id, $container_uuid, and /sys/class/dmi/id/product_uuid. > I think that the first should work for your use case, since you keep /var. > But we also check some commandline option, this seems useful for some > use cases. > > Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] 7 commits - man/systemd.network.xml po/es.po po/LINGUAS src/journal-remote src/libsystemd src/libsystemd-network
Hi
On Fri, Mar 13, 2015 at 1:45 PM, Zbigniew Jędrzejewski-Szmek
wrote:
> On Fri, Mar 13, 2015 at 01:38:23PM +0100, David Herrmann wrote:
>> Hi
>>
>> On Fri, Mar 13, 2015 at 5:27 AM, Zbigniew Jędrzejewski-Szmek
>> wrote:
>> > commit f53f7c8fc43df4e38655f2a1f5c5934fee06
>> > Author: Zbigniew Jędrzejewski-Szmek
>> > Date: Thu Mar 12 21:54:14 2015 -0400
>> >
>> > journal-remote: check also for EWOULDBLOCK
>> >
>> > This matches similar code elsewhere.
>> >
>> > diff --git a/src/journal-remote/journal-remote.c
>> > b/src/journal-remote/journal-remote.c
>> > index 01cfef5..e6aa072 100644
>> > --- a/src/journal-remote/journal-remote.c
>> > +++ b/src/journal-remote/journal-remote.c
>> > @@ -1022,7 +1022,7 @@ static int dispatch_raw_source_event(sd_event_source
>> > *event,
>> > } else if (r == -E2BIG) {
>> > log_notice_errno(E2BIG, "Entry too big, skipped");
>> > return 1;
>> > -} else if (r == -EAGAIN) {
>> > +} else if (r == -EAGAIN || r == -EWOULDBLOCK) {
>> > return 0;
>> > } else if (r < 0) {
>> > log_debug_errno(r, "Closing connection: %m");
>>
>> What's the reason for this? EWOULDBLOCK is the same as EAGAIN on
>> linux. Why don't we get rid of all those EWOULDBLOCK checks in
>> systemd? The only other offender I see is udevd, but that can be
>> easily changed to EAGAIN.
> Sure, if it's guaranteed to be the same, we can get rid of all of them.
> I don't care either way, and did this only for consitency with the
> inner function, which checks both.
I just checked all of ./linux/arch/* and EWOULDBLOCK is always
equivalent to EAGAIN. I will drop the relevant parts.
Thanks
David
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] 7 commits - man/systemd.network.xml po/es.po po/LINGUAS src/journal-remote src/libsystemd src/libsystemd-network
On Fri, Mar 13, 2015 at 01:38:23PM +0100, David Herrmann wrote:
> Hi
>
> On Fri, Mar 13, 2015 at 5:27 AM, Zbigniew Jędrzejewski-Szmek
> wrote:
> > commit f53f7c8fc43df4e38655f2a1f5c5934fee06
> > Author: Zbigniew Jędrzejewski-Szmek
> > Date: Thu Mar 12 21:54:14 2015 -0400
> >
> > journal-remote: check also for EWOULDBLOCK
> >
> > This matches similar code elsewhere.
> >
> > diff --git a/src/journal-remote/journal-remote.c
> > b/src/journal-remote/journal-remote.c
> > index 01cfef5..e6aa072 100644
> > --- a/src/journal-remote/journal-remote.c
> > +++ b/src/journal-remote/journal-remote.c
> > @@ -1022,7 +1022,7 @@ static int dispatch_raw_source_event(sd_event_source
> > *event,
> > } else if (r == -E2BIG) {
> > log_notice_errno(E2BIG, "Entry too big, skipped");
> > return 1;
> > -} else if (r == -EAGAIN) {
> > +} else if (r == -EAGAIN || r == -EWOULDBLOCK) {
> > return 0;
> > } else if (r < 0) {
> > log_debug_errno(r, "Closing connection: %m");
>
> What's the reason for this? EWOULDBLOCK is the same as EAGAIN on
> linux. Why don't we get rid of all those EWOULDBLOCK checks in
> systemd? The only other offender I see is udevd, but that can be
> easily changed to EAGAIN.
Sure, if it's guaranteed to be the same, we can get rid of all of them.
I don't care either way, and did this only for consitency with the
inner function, which checks both.
Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] 7 commits - man/systemd.network.xml po/es.po po/LINGUAS src/journal-remote src/libsystemd src/libsystemd-network
Hi
On Fri, Mar 13, 2015 at 5:27 AM, Zbigniew Jędrzejewski-Szmek
wrote:
> commit f53f7c8fc43df4e38655f2a1f5c5934fee06
> Author: Zbigniew Jędrzejewski-Szmek
> Date: Thu Mar 12 21:54:14 2015 -0400
>
> journal-remote: check also for EWOULDBLOCK
>
> This matches similar code elsewhere.
>
> diff --git a/src/journal-remote/journal-remote.c
> b/src/journal-remote/journal-remote.c
> index 01cfef5..e6aa072 100644
> --- a/src/journal-remote/journal-remote.c
> +++ b/src/journal-remote/journal-remote.c
> @@ -1022,7 +1022,7 @@ static int dispatch_raw_source_event(sd_event_source
> *event,
> } else if (r == -E2BIG) {
> log_notice_errno(E2BIG, "Entry too big, skipped");
> return 1;
> -} else if (r == -EAGAIN) {
> +} else if (r == -EAGAIN || r == -EWOULDBLOCK) {
> return 0;
> } else if (r < 0) {
> log_debug_errno(r, "Closing connection: %m");
What's the reason for this? EWOULDBLOCK is the same as EAGAIN on
linux. Why don't we get rid of all those EWOULDBLOCK checks in
systemd? The only other offender I see is udevd, but that can be
easily changed to EAGAIN.
Thanks
David
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] console-getty.service: don't start when /dev/console is missing
From: Jan Pazdziora Create minimal image which runs systemd FROM rhel7.1 RUN yum install -y /usr/bin/ps ENV container docker CMD [ "/usr/sbin/init" ] When you run the container without -t, the process /sbin/agetty --noclear --keep-baud console 115200 38400 9600 is not happy and checking the journal in the container, there is a stream of Mar 13 04:50:15 11bf07f59fff agetty[66]: /dev/console: No such file or directory Mar 13 04:50:25 11bf07f59fff systemd[1]: console-getty.service holdoff time over, scheduling restart. Mar 13 04:50:25 11bf07f59fff systemd[1]: Stopping Console Getty... Mar 13 04:50:25 11bf07f59fff systemd[1]: Starting Console Getty... Mar 13 04:50:25 11bf07f59fff systemd[1]: Started Console Getty. Mar 13 04:50:25 11bf07f59fff agetty[67]: /dev/console: No such file or directory Mar 13 04:50:35 11bf07f59fff systemd[1]: console-getty.service holdoff time over, scheduling restart. Mar 13 04:50:35 11bf07f59fff systemd[1]: Stopping Console Getty... Mar 13 04:50:35 11bf07f59fff systemd[1]: Starting Console Getty... Mar 13 04:50:35 11bf07f59fff systemd[1]: Started Console Getty. Mar 13 04:50:35 11bf07f59fff agetty[74]: /dev/console: No such file or directory Mar 13 04:50:45 11bf07f59fff systemd[1]: console-getty.service holdoff time over, scheduling restart. Mar 13 04:50:45 11bf07f59fff systemd[1]: Stopping Console Getty... Mar 13 04:50:45 11bf07f59fff systemd[1]: Starting Console Getty... --- units/console-getty.service.m4.in | 1 + 1 file changed, 1 insertion(+) diff --git a/units/console-getty.service.m4.in b/units/console-getty.service.m4.in index 8ac51a4..413d940 100644 --- a/units/console-getty.service.m4.in +++ b/units/console-getty.service.m4.in @@ -9,6 +9,7 @@ Description=Console Getty Documentation=man:agetty(8) After=systemd-user-sessions.service plymouth-quit-wait.service +ConditionPathExists=/dev/console m4_ifdef(`HAVE_SYSV_COMPAT', After=rc-local.service )m4_dnl -- 1.8.3.1 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] networkd: Begin with serial number 1 for netlink requests
On Thu, Mar 12, 2015 at 06:14:58PM +, Richard Maw wrote:
> diff --git a/src/libsystemd/sd-rtnl/sd-rtnl.c
> b/src/libsystemd/sd-rtnl/sd-rtnl.c
> index ae49c77..5f54acd 100644
> --- a/src/libsystemd/sd-rtnl/sd-rtnl.c
> +++ b/src/libsystemd/sd-rtnl/sd-rtnl.c
> @@ -61,6 +61,11 @@ static int sd_rtnl_new(sd_rtnl **ret) {
> sizeof(struct nlmsghdr), sizeof(uint8_t)))
> return -ENOMEM;
>
> +/* Change notification responses have sequence 0, so we must
> + * start our request sequence numbers at 1, or we may confuse our
> + * responses with notifications from the kernel */
> +rtnl->sequence = 1;
Whoops, sorry about the transcription error there. Thanks for fixing it
up Tom Gundersen.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] build: generate pkg-config files during configure
On 12 March 2015 at 23:13, Jeff Waugh wrote: > On Fri, Mar 13, 2015 at 10:07 AM, Michael Biebl wrote: >>> Those are the as-installed versions (they're not manipulated again during >>> make). >> >> And how does that improve cross-compilation? > > It allows you to successfully build other software that uses the > library. A minor detail. :-) > I don't buy this. When cross-compiling with pkg-config, you do need to ship the pkg-config files in a different place, in the same location one sets prefix to. and then use e.g. /usr/bin/arm-linux-gnueabihf-pkg-config (via wrapper) or simply set PKG_CONFIG_PATH correctly. Having done a few cross-bootstraps from scratch I don't recall any bugs/problems with crossbuilding systemd itself, or things that depend on libsystemd & friends. Can you start from beginning as to how you are cross compiling things on the OpenWRT and why it is failing for you? What is your host? What is your cross-chroot? What are your PKG_CONFIG_PATH? What's the contents of the generated .pc file? Where do you install it, and how does it fail for you? -- Regards, Dimitri. Open Source Technology Center Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] core: don't change removed devices to state "tentative" [was: Re: [PATCH] unit: When stopping due to BindsTo=, log which unit caused it]
Martin Pitt [2015-03-13 8:30 +0100]:
> removal from udev we definitively know that it's gond, so change the device
Yeah, we need more gond devices!
*blush*, same patch with that typo fixed.
Martin
--
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
From baebf50cd43a049ebd38bfd31210c7f3189522f3 Mon Sep 17 00:00:00 2001
From: Martin Pitt
Date: Fri, 13 Mar 2015 08:23:02 +0100
Subject: [PATCH] core: don't change removed devices to state "tentative"
Commit 628c89c introduced the "tentative" device state, which caused devices to
go from "plugged" to "tentative" on a remove uevent. This breaks the cleanup
of stale mounts (see commit 3b48ce4), as that only applies to "dead" devices.
The "tentative" state only really makes sense on adding a device when we don't
know where it was coming from (i. e. not from udev). But when we get a device
removal from udev we definitively know that it's gone, so change the device
state back to "dead" as before 628c89c.
---
src/core/device.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/core/device.c b/src/core/device.c
index 6b489a4..098a000 100644
--- a/src/core/device.c
+++ b/src/core/device.c
@@ -419,7 +419,7 @@ static void device_update_found_one(Device *d, bool add, DeviceFound found, bool
if (now) {
if (d->found & DEVICE_FOUND_UDEV)
device_set_state(d, DEVICE_PLUGGED);
-else if (d->found != DEVICE_NOT_FOUND)
+else if (add && d->found != DEVICE_NOT_FOUND)
device_set_state(d, DEVICE_TENTATIVE);
else
device_set_state(d, DEVICE_DEAD);
--
2.1.4
signature.asc
Description: Digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] core: don't change removed devices to state "tentative" [was: Re: [PATCH] unit: When stopping due to BindsTo=, log which unit caused it]
Hello all,
Martin Pitt [2015-03-01 12:43 +0100]:
> Lennart Poettering [2015-02-28 17:40 +0100]:
> > This is implemented now. Please check if this fixes this issue for
> > you.
>
> This fixes the bad unmounts at boot, but also breaks the automatic cleanup of
> stale mounts after CD ejection.
> [...]
> but after ejecting the mount still stays around. The device unit does
> to activating/tentative, and the .mount unit is unchanged from the above.
> Supposedly this line is the interesting one:
>
> systemd[1]: dev-sr1.device changed plugged -> tentative
>
> which in this case really should become "dead". The full debug journal
> is at http://people.canonical.com/~pitti/tmp/journal-cd-eject.txt
The attached patch fixes that. I tested CD ejection, the cleanup
unmount works properly again. I also verified that mounts done in the
initramfs (i. e. "tentative" device state) are still kept around
without unmounting them.
Thanks,
Martin
--
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
From 05ffa415fa4f75f2e71830d47179b6f4a67c7215 Mon Sep 17 00:00:00 2001
From: Martin Pitt
Date: Fri, 13 Mar 2015 08:23:02 +0100
Subject: [PATCH] core: don't change removed devices to state "tentative"
Commit 628c89c introduced the "tentative" device state, which caused devices to
go from "plugged" to "tentative" on a remove uevent. This breaks the cleanup
of stale mounts (see commit 3b48ce4), as that only applies to "dead" devices.
The "tentative" state only really makes sense on adding a device when we don't
know where it was coming from (i. e. not from udev). But when we get a device
removal from udev we definitively know that it's gond, so change the device
state back to "dead" as before 628c89c.
---
src/core/device.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/core/device.c b/src/core/device.c
index 6b489a4..098a000 100644
--- a/src/core/device.c
+++ b/src/core/device.c
@@ -419,7 +419,7 @@ static void device_update_found_one(Device *d, bool add, DeviceFound found, bool
if (now) {
if (d->found & DEVICE_FOUND_UDEV)
device_set_state(d, DEVICE_PLUGGED);
-else if (d->found != DEVICE_NOT_FOUND)
+else if (add && d->found != DEVICE_NOT_FOUND)
device_set_state(d, DEVICE_TENTATIVE);
else
device_set_state(d, DEVICE_DEAD);
--
2.1.4
signature.asc
Description: Digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
