Re: [systemd-devel] fstrim "cron" job
On Sat, Dec 21, 2013 at 7:11 PM, Chris Murphy wrote: > > On Dec 21, 2013, at 6:44 AM, Kay Sievers wrote: > >> Trimming should be the job of the filesystem, not for a nasty cron >> job. We do not want to support legacy filesystems with upstream >> shipped systemd units. >> >> Also, util-linux must not ship such policy, it's a collection of >> tools, not a system policy carry-out. > > Well it's the job of the file system, the device mapper, the block layer, the > ATA driver, the controller and then the drive. And at the bottom of this > stack, the drive specification, is flawed. We're not going to see the file > systems doing this in ideal fashion, none of them set discard by default, > until everything below is properly enabling asynchronous queued TRIM. > > So the question is whether it makes sense to design a work around for what > amount to legacy devices (even though they are still being bought and sold > today), or entirely ignore this (automatic) optimization for the life of the > devices and leave it up to the user to set such things. > >> We need to support fsck because it's needed for integrity and using >> filesystems that need, but running trim is just an optimization. We do >> not want the bugs for these filesystems triggered by the systemd >> package. > > It seems systemd now parses fstab and can second guess its contents, e.g. it > will ignore fs_passno for Btrfs, so even if it's a non-zero value, systemd > doesn't cause fsck to go looking for an fsck.btrfs. > > But it does for xfs, which likewise doesn't need fsck at all. We don't actually check for btrfs, but simply skip any checking when /sbin/fsck. does not exist. > I don't know if these optimizations really belong in systemd or rather in a > smarter fsck to keep a list of file systems that do and don't need fsck > performed on them prior to remount as rw. I'd argue that the systemd behavior of ignoring missing helpers should just be moved to fsck... -t ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 00/11] Finalize initial DHCP support
On Fri, Dec 20, 2013 at 6:47 PM, Marcel Holtmann wrote: > Hi Tom, > The first seven patches fix a few issues with the current code. Patch 09 adds DHCP lease renewing support when timer T1 triggers. Using the UDP socket sending implementation in patch 08, the DHCP lease renewal is unicasted to the DHCP server. This means that systemd-network should have applied the acquired IP address and default route to the proper interface before timer T1 triggers. >>> >>> this could become racy and we might end up in funny cases if the lease is >>> really small. I think networkd and the DHCP need some way of communicating >>> a) I set the IP you told me and/or b) we have T1 triggering, have you set >>> the address or should I just redo the DHCP process. >> >> Makes sense to me for networkd to call (something like) >> sd_dhcp_client_address_configured(client, true) whenever it has >> successfully set the addresses/routes. I.e., I'd go with option (a). >> Or is there a reason to go with (b) that I'm not seeing? > > the case I see is that T1 is triggered, but the IP address is not set. Then > of course we should not be setting it anymore since it might not stay valid. > > However this could be done by DHCP itself just deciding that if > client_address_configured is not called by the the time T1 expired, let the > DHCP code redo the DHCP discovery. Yeah, that makes sense. > For good measure we should have warnings in the code for these unlikely race > scenarios and see if someone is actually able to trigger them. With ConnMan, > I do not recall we had bug reports of this. However we do not know what funny > cases happen with virtualization and containers. Agreed. -t ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 02/11] libsystemd-dhcp: Return proper error if bind fails
On Fri, Dec 20, 2013 at 10:23 PM, Lennart Poettering
wrote:
> On Fri, 20.12.13 16:35, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
>
>> On Fri, Dec 20, 2013 at 05:16:11PM +0200, Patrik Flykt wrote:
>> > This also fixes a minor indentation damage.
>> > ---
>> > src/libsystemd-dhcp/dhcp-network.c |7 ---
>> > 1 file changed, 4 insertions(+), 3 deletions(-)
>> >
>> > diff --git a/src/libsystemd-dhcp/dhcp-network.c
>> > b/src/libsystemd-dhcp/dhcp-network.c
>> > index 83a3084..3ff2d0b 100644
>> > --- a/src/libsystemd-dhcp/dhcp-network.c
>> > +++ b/src/libsystemd-dhcp/dhcp-network.c
>> > @@ -31,8 +31,8 @@
>> > #include "dhcp-internal.h"
>> >
>> > int dhcp_network_bind_raw_socket(int index, union sockaddr_union *link)
>> > - {
>> > -int s;
>> > +{
>> > +int s, err;
>> >
>> > s = socket(AF_PACKET, SOCK_DGRAM | SOCK_CLOEXEC | SOCK_NONBLOCK,
>> > htons(ETH_P_IP));
>> > @@ -46,8 +46,9 @@ int dhcp_network_bind_raw_socket(int index, union
>> > sockaddr_union *link)
>> > memset(link->ll.sll_addr, 0xff, ETH_ALEN);
>> >
>> > if (bind(s, &link->sa, sizeof(link->ll)) < 0) {
>> > +err = -errno;
>> > close(s);
>> > -return -errno;
>> > +return err;
>>
>> 'err' → 'r', for consistency with other code.
>
> Actually, just use close_nointr_nofail() here, as that saves/restore
> errno for you, then you don't need to store this in a temporary variable
> at all...
I fixed this before applying.
-t
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 00/11] Finalize initial DHCP support
On Fri, Dec 20, 2013 at 4:16 PM, Patrik Flykt wrote: > The first seven patches fix a few issues with the current code. > > Patch 09 adds DHCP lease renewing support when timer T1 triggers. Using > the UDP socket sending implementation in patch 08, the DHCP lease > renewal is unicasted to the DHCP server. This means that systemd-network > should have applied the acquired IP address and default route to the > proper interface before timer T1 triggers. > > Common code is factored out in patch 10, which makes patch 11 containing > the broadcasting of DHCP Requests at timer T2 trigger quite small. > > At this point in time support for fetching DNS, NTP, etc options from > the DHCP message(s) is still missing, sorry for that. Also Init-Reboot > state support is missing; adding that functionality can speed up the > address acquisition if the host comes back to a known network where > it still has an unexpired lease. Hi Patrik, I applied these patches, with the minor suggestions from Lennart and Zbigniew. Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] 5 commits - TODO src/core src/libsystemd-bus src/login src/machine src/systemd
On Sun, 22.12.13 04:10, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
> > const sd_bus_vtable bus_cgroup_vtable[] = {
> > +SD_BUS_PROPERTY("CPUAccounting", "b", bus_property_get_bool,
> > offsetof(CGroupContext, cpu_accounting), SD_BUS_VTABLE_PROPERTY_CONST),
> > +SD_BUS_PROPERTY("CPUShares", "t", bus_property_get_ulong,
> > offsetof(CGroupContext, cpu_shares), SD_BUS_VTABLE_PROPERTY_CONST),
> > +SD_BUS_PROPERTY("BlockIOAccounting", "b", bus_property_get_bool,
> > offsetof(CGroupContext, blockio_accounting), SD_BUS_VTABLE_PROPERTY_CONST),
> > +SD_BUS_PROPERTY("BlockIOWeight", "t", bus_property_get_ulong,
> > offsetof(CGroupContext, blockio_weight), SD_BUS_VTABLE_PROPERTY_CONST),
> > +SD_BUS_PROPERTY("BlockIODeviceWeight", "a(st)",
> > property_get_blockio_device_weight, 0, SD_BUS_VTABLE_PROPERTY_CONST),
> > +SD_BUS_PROPERTY("BlockIOReadBandwidth", "a(st)",
> > property_get_blockio_device_bandwidths, 0, SD_BUS_VTABLE_PROPERTY_CONST),
> > +SD_BUS_PROPERTY("BlockIOWriteBandwidth", "a(st)",
> > property_get_blockio_device_bandwidths, 0, SD_BUS_VTABLE_PROPERTY_CONST),
> > +SD_BUS_PROPERTY("MemoryAccounting", "b", bus_property_get_bool,
> > offsetof(CGroupContext, memory_accounting), SD_BUS_VTABLE_PROPERTY_CONST),
> > +SD_BUS_PROPERTY("MemoryLimit", "t", NULL, offsetof(CGroupContext,
> > memory_limit), SD_BUS_VTABLE_PROPERTY_CONST),
> > +SD_BUS_PROPERTY("DevicePolicy", "s",
> > property_get_cgroup_device_policy, offsetof(CGroupContext, device_policy),
> > SD_BUS_VTABLE_PROPERTY_CONST),
> > +SD_BUS_PROPERTY("DeviceAllow", "a(ss)", property_get_device_allow,
> > 0, SD_BUS_VTABLE_PROPERTY_CONST),
> Aren't properties like "CPUShares", "MemoryAccounting", and others modifiable
> at runtime?
> Or does this _CONST mean something different?
Oh, you are right. I'll fix it.
(And yeah the const is supposed to mean that a property is constant
during the entire lifetime of the object it is on.)
https://bugs.freedesktop.org/show_bug.cgi?id=72958
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Split out /run/nologin creation into a separate service
On Sat, 21.12.13 04:45, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: > This has come up before, and will come up again: running > systemd-tmpfiles --create kills user logins. In principle > this is documented, but in practice people don't always > read the documentation. Split out /run/nologin creation > so it's harder to do execute it by mistake. > > https://bugzilla.redhat.com/show_bug.cgi?id=1043212 Hmmm, --create is dangerous, beyond /run/nologin it will also empty dirs and truncate files (for "D" and "F" lines), and that's really not what people should do during runtime, and assume it was not dangerous.. Maybe go the other way and refuse to work (or just warn?) during normal operation if no arguments are passed? Note entirely sure though what to detect "during normal operation" with though. Maybe warn/fail if we are run from a tty (in opposition to run as a service with no tty)? Or maybe we should allow "--create" only a single time during each boot (unless a specific file name is specified), so that all later calls generate a warning or fail? And then maybe a new "--force" switch or so, that makes that warning/failure go away? I'd certainly prefer if we'd go this way instead of fraying out the snippets too wildly... > --- > Hi Lennart, > this patch is essentially harmless, but not very pretty, so I'm > sending it to the mailing list in case you want to veto it. > > Zbyszek > > Makefile-man.am | 5 + > Makefile.am | 12 +++ > man/systemd-tmpfiles.xml | 26 > +++ > tmpfiles.d/systemd-forbid-user-logins.conf.noauto | 11 ++ > tmpfiles.d/systemd.conf | 2 -- > units/.gitignore | 1 + > units/systemd-forbid-user-logins.service.in | 21 ++ > units/systemd-tmpfiles-setup.service.in | 1 + > 8 files changed, 64 insertions(+), 15 deletions(-) > create mode 100644 tmpfiles.d/systemd-forbid-user-logins.conf.noauto > create mode 100644 units/systemd-forbid-user-logins.service.in > > diff --git a/Makefile-man.am b/Makefile-man.am > index c5f73d4..c337d09 100644 > --- a/Makefile-man.am > +++ b/Makefile-man.am > @@ -180,6 +180,7 @@ MANPAGES_ALIAS += \ > man/systemd-ask-password-console.path.8 \ > man/systemd-ask-password-wall.path.8 \ > man/systemd-ask-password-wall.service.8 \ > + man/systemd-forbid-user-logins.service.8 \ > man/systemd-fsck-root.service.8 \ > man/systemd-fsck.8 \ > man/systemd-hibernate.service.8 \ > @@ -283,6 +284,7 @@ man/sd_notifyf.3: man/sd_notify.3 > man/systemd-ask-password-console.path.8: > man/systemd-ask-password-console.service.8 > man/systemd-ask-password-wall.path.8: > man/systemd-ask-password-console.service.8 > man/systemd-ask-password-wall.service.8: > man/systemd-ask-password-console.service.8 > +man/systemd-forbid-user-logins.service.8: man/systemd-tmpfiles.8 > man/systemd-fsck-root.service.8: man/systemd-fsck@.service.8 > man/systemd-fsck.8: man/systemd-fsck@.service.8 > man/systemd-hibernate.service.8: man/systemd-suspend.service.8 > @@ -538,6 +540,9 @@ man/systemd-ask-password-wall.path.html: > man/systemd-ask-password-console.servic > man/systemd-ask-password-wall.service.html: > man/systemd-ask-password-console.service.html > $(html-alias) > > +man/systemd-forbid-user-logins.service.html: man/systemd-tmpfiles.html > + $(html-alias) > + > man/systemd-fsck-root.service.html: man/systemd-f...@.service.html > $(html-alias) > > diff --git a/Makefile.am b/Makefile.am > index 8507d8d..e1cd71f 100644 > --- a/Makefile.am > +++ b/Makefile.am > @@ -1578,12 +1578,14 @@ dist_systemunit_DATA += \ > nodist_systemunit_DATA += \ > units/systemd-tmpfiles-setup-dev.service \ > units/systemd-tmpfiles-setup.service \ > - units/systemd-tmpfiles-clean.service > + units/systemd-tmpfiles-clean.service \ > + units/systemd-forbid-user-logins.service > > dist_tmpfiles_DATA = \ > tmpfiles.d/systemd.conf \ > tmpfiles.d/tmp.conf \ > - tmpfiles.d/x11.conf > + tmpfiles.d/x11.conf \ > + tmpfiles.d/systemd-forbid-user-logins.conf.noauto > > if HAVE_SYSV_COMPAT > dist_tmpfiles_DATA += \ > @@ -1592,7 +1594,8 @@ endif > > SYSINIT_TARGET_WANTS += \ > systemd-tmpfiles-setup-dev.service \ > - systemd-tmpfiles-setup.service > + systemd-tmpfiles-setup.service \ > + systemd-forbid-user-logins.service > > dist_zshcompletion_DATA += \ > shell-completion/zsh/_systemd-tmpfiles > @@ -1608,7 +1611,8 @@ endif > EXTRA_DIST += \ > units/systemd-tmpfiles-setup-dev.service.in \ > units/systemd-tmpfiles-setup.service.in \ > - units/systemd-tmpfiles-clean.service.in > + units/systemd-tmpfiles-clean.service.in \ > + units/systemd-forbid-user-logins.service.in > > # > -
Re: [systemd-devel] [systemd-commits] 2 commits - TODO src/core
On Fri, Dec 20, 2013 at 03:54:32PM -0800, Lennart Poettering wrote: > New commits: > commit d86f9d5285742e959a158e743799506b5339fefc > Author: Lennart Poettering > Date: Sat Dec 21 00:19:37 2013 +0100 > > core: pass notify fd across reexecs > > That way we the random socket name stays stable across reexec and we > won't lose client messages. > Hi Lennart, >From #systemd: 04:14 < zbyszek> poettering: I just daemon-reexec'ed into HEAD~10 and I see a segfault: 04:14 < zbyszek> systemd[1]: Assertion 'm->notify_fd == fd' failed at src/core/manager.c:1283, function manager_dispatch_notify_fd(). Aborting. 04:18 < zbyszek> http://paste.fedoraproject.org/63664/13875959 I didn't see anything in subsequent commits that would fix this. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] 2 commits - TODO src/core
On Sun, 22.12.13 15:30, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: > > On Fri, Dec 20, 2013 at 03:54:32PM -0800, Lennart Poettering wrote: > > New commits: > > commit d86f9d5285742e959a158e743799506b5339fefc > > Author: Lennart Poettering > > Date: Sat Dec 21 00:19:37 2013 +0100 > > > > core: pass notify fd across reexecs > > > > That way we the random socket name stays stable across reexec and we > > won't lose client messages. > > > Hi Lennart, > > >From #systemd: > 04:14 < zbyszek> poettering: I just daemon-reexec'ed into HEAD~10 and I see a > segfault: > 04:14 < zbyszek> systemd[1]: Assertion 'm->notify_fd == fd' failed at > src/core/manager.c:1283, function > manager_dispatch_notify_fd(). Aborting. > 04:18 < zbyszek> http://paste.fedoraproject.org/63664/13875959 > > I didn't see anything in subsequent commits that would fix this. Hmm, weird. I don't see how that could ever happen from the code... Do you know a reproducer for this? reexec appears to work fine here... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to control socket activation when it run respawn infinitely.
Hello. As you recommend me to use "Accept=", I set this as "true". But Client process waited for a few minute, it showed error message "connection was refused". In this case, The best case to execute the service unit is to set "Accept= false". But It will definitely present error message and be hanged. systemd[1]: test_server.service start request repeated too quickly, refusing to start. systemd[1]: Failed to start test_server.service.systemd[1]: test_server.service start request repeated too quickly, refusing to start. Frankly speaking, I don't understand why service daemon is infinitely spawned when I set the option "Accept= false". And Why couldn't the client process connect to socket unit that I made by setting "Accept= true". Thanks. 2013/12/19 Tony Seo > Hello. > I tried to execute a process by using socket activation. > As it is referred at systemd manual, I made "server" and "client" process > by using "sd-daemon.h" and "sd-daemon.c". > when I made those processes, I used UDS(Unix Domain Socket) to make > communication between server and client. > (I also made "/run/test_server" which executes like "/run/foobar.sk" in > example of systemd manual for socket activation) > http://0pointer.de/blog/projects/socket-activation.html > > And then, In order to make the process started, I made test_server.socket > and test_server.service. > those thing have contents like below: > > test_server.socket--- > [Socket] > ListenStream=/run/test_server > > [Install] > WantedBy=sockets.target > > > > test_server.service--- > [Service] > Type=oneshot > ExecStart=/bin/sh /usr/bin/kill-avn-process.sh > StandardOutput=journal+console > TTYPath=/dev/ttyTCC0 > > > [Install] > WantedBy=multi-user.target > > > > > As soon as I executed the client process, test_server.service worked > rapidly but it seemed to run in infinite loop with changing it's PID and > then, it showed that error messages like: > systemd[1]: test_server.service start request repeated too quickly, > refusing to start. > systemd[1]: Failed to start test_server.service. > > I already knew that a process executed by socket activation would be > respawn. > But, what the important thing is that I don't know how to control the > number of respawn. > And, why does systemd make the error about request timing. > > Thanks. > ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to control socket activation when it run respawn infinitely.
On Sun, Dec 22, 2013 at 11:43 AM, Tony Seo wrote: > Frankly speaking, I don't understand why service daemon is infinitely > spawned when I set the option "Accept= false". > And Why couldn't the client process connect to socket unit that I made by > setting "Accept= true". I think you need to learn more about Unix socket programming before it's possible to explain how those options work in systemd. The stage of accept() is pretty key, and it's not systemd-specific. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] hwdb/20-sdio-classes.hwdb hwdb/20-sdio-vendor-model.hwdb hwdb/sdio.ids Makefile.am
On Sun, Dec 22, 2013 at 10:25:10AM -0800, Marcel Holtmann wrote: > Makefile.am|2 + > hwdb/20-sdio-classes.hwdb | 33 ++ > hwdb/20-sdio-vendor-model.hwdb | 45 > + > hwdb/sdio.ids | 40 > 4 files changed, 120 insertions(+) > > New commits: > commit d5f7759a9881e2d3b94a2e706397dae87830f1dd > Author: Marcel Holtmann > Date: Sun Dec 22 10:21:20 2013 -0800 > > hwddb: Add database for SDIO vendor and class information > +sdio:c*v1180* > + ID_VENDOR_FROM_DATABASE=Ricoh We already have "Ricoh Ltd." and "Ricoh, Ltd" in other hwdb files. Is there hope to unify this? Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] 2 commits - TODO src/core
On Sun, Dec 22, 2013 at 03:40:35PM +0100, Lennart Poettering wrote: > On Sun, 22.12.13 15:30, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: > > > > > On Fri, Dec 20, 2013 at 03:54:32PM -0800, Lennart Poettering wrote: > > > New commits: > > > commit d86f9d5285742e959a158e743799506b5339fefc > > > Author: Lennart Poettering > > > Date: Sat Dec 21 00:19:37 2013 +0100 > > > > > > core: pass notify fd across reexecs > > > > > > That way we the random socket name stays stable across reexec and we > > > won't lose client messages. > > > > > Hi Lennart, > > > > >From #systemd: > > 04:14 < zbyszek> poettering: I just daemon-reexec'ed into HEAD~10 and I see > > a segfault: > > 04:14 < zbyszek> systemd[1]: Assertion 'm->notify_fd == fd' failed at > > src/core/manager.c:1283, function > > manager_dispatch_notify_fd(). Aborting. > > 04:18 < zbyszek> http://paste.fedoraproject.org/63664/13875959 > > > > I didn't see anything in subsequent commits that would fix this. > > Hmm, weird. I don't see how that could ever happen from the code... Do > you know a reproducer for this? reexec appears to work fine here... I cannot reproduce it now either. Strange. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v2] loginctl: fix output of type with class
Applied. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
