Re: [systemd-devel] [PATCH] loginctl: fix output of type with class
On Sun, Dec 22, 2013 at 4:00 AM, Zbigniew Jędrzejewski-Szmek
wrote:
> On Sun, Dec 22, 2013 at 02:54:05AM +0200, Mantas Mikulėnas wrote:
>> ---
>> src/login/loginctl.c | 4 +++-
>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/src/login/loginctl.c b/src/login/loginctl.c
>> index 36c65bc..5f57f62 100644
>> --- a/src/login/loginctl.c
>> +++ b/src/login/loginctl.c
>> @@ -364,10 +364,12 @@ static void
>> print_session_status_info(SessionStatusInfo *i) {
>>
>> printf("\n");
>> } else if (i->type) {
>> -printf("\tType: %s\n", i->type);
>> +printf("\tType: %s", i->type);
>>
>> if (i->class)
>> printf("; class %s", i->class);
>> +
>> +printf("\n");
>> } else if (i->class)
>> printf("\t Class: %s\n", i->class);
>>
> Can you rebase (if this is still an issue)?
>
> Zbyszek
Ouch, I thought I had done that for both branches. Resent.
--
Mantas Mikulėnas
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH v2] loginctl: fix output of type with class
---
src/login/loginctl.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/login/loginctl.c b/src/login/loginctl.c
index 914f316..6900253 100644
--- a/src/login/loginctl.c
+++ b/src/login/loginctl.c
@@ -453,10 +453,12 @@ static int print_session_status_info(sd_bus *bus, const
char *path, bool *new_li
printf("\n");
} else if (i.type) {
-printf("\tType: %s\n", i.type);
+printf("\tType: %s", i.type);
if (i.class)
printf("; class %s", i.class);
+
+printf("\n");
} else if (i.class)
printf("\t Class: %s\n", i.class);
--
1.8.5.1.277.g0e0d235
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] fstab-generator: Do not try to fsck non-devices
On Sat, Dec 21, 2013 at 05:49:19PM +0100, Tom Gundersen wrote:
> On Sat, Dec 21, 2013 at 5:42 PM, Kay Sievers wrote:
> > On Sat, Dec 21, 2013 at 5:33 PM, Dave Reisner wrote:
> >> On Sat, Dec 21, 2013 at 12:49:07PM +0100, Tom Gundersen wrote:
> >>> On Sat, Dec 21, 2013 at 11:22 AM, Thomas Bächler
> >>> wrote:
> >>> > This fixes a regression introduced in 64e70e4 where the mount fails
> >>> > when fstab is misconfigured with fs_passno > 0 on a virtual file
> >>> > system like tmpfs.
> >>> > ---
> >>> > src/fstab-generator/fstab-generator.c | 8 +---
> >>> > 1 file changed, 5 insertions(+), 3 deletions(-)
> >>> >
> >>> > diff --git a/src/fstab-generator/fstab-generator.c
> >>> > b/src/fstab-generator/fstab-generator.c
> >>> > index 1227f08..709a1c3 100644
> >>> > --- a/src/fstab-generator/fstab-generator.c
> >>> > +++ b/src/fstab-generator/fstab-generator.c
> >>> > @@ -255,9 +255,11 @@ static int add_mount(
> >>> > "Before=%s\n",
> >>> > post);
> >>> >
> >>> > -r = add_fsck(f, what, where, type, passno);
> >>> > -if (r < 0)
> >>> > -return r;
> >>> > +if(is_device_path(what)) {
> >>> > +r = add_fsck(f, what, where, type, passno);
> >>> > +if (r < 0)
> >>> > +return r;
> >>> > +}
Hi,
patch is applied, but I moved the chck into add_fsck, because the check
for passno is there. And I added a warning, since this is a configuration
error that should be corrected.
Also, I don't see how the mount could fail for tmpfs: tmpfs must always
be specified as the type, and if the type is specified, add_fsck
looks for /sbin/fsck. and only emits a warning. But in case of
a non-device fs which can be given with "auto" as the type, e.g. nfs,
there indeed was a problem.
> >>> How does "fsck -A" deal with these cases?
> >>
> >> tmpfs falls into the category of pseudofs, which fsck -A will
> >> intentionally ignore, regardless of the passno.
> >>
> >>> Also, how does your patch deal with LABEL= and UUDI=?
> >>
> >> At this point, "what" has been filtered through fstab_node_to_udev_node,
> >> so LABEL=foo will be /dev/disk/by-label/foo.
> >
> > Generally, not sure if that it always correct here, kernel "nodev"
> > superblocks have a dev_t with major == 0 and are very simple to detect
> > that way.
There's no superblock yet at this point, because the device might not be there
yet. But I think that the is_device_path test is OK.
> Hm, so why doesn't fsck just deal gracefully with this?
We call /sbin/fsck. directly, which in this case doesn't exist. Also
systemd waits for the device to appear before calling fsck.
Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] libsystemd-login: add sd_session_get_remote_{host, user}
On Sun, Dec 22, 2013 at 02:48:46AM +0200, Mantas Mikulėnas wrote: > --- > Makefile-man.am| 15 + > man/sd_session_is_active.xml | 50 > +++--- > src/login/libsystemd-login.sym | 7 ++ > src/login/sd-login.c | 28 +++ > src/login/test-login.c | 14 +++- > src/systemd/sd-login.h | 11 +- > 6 files changed, 120 insertions(+), 5 deletions(-) Looks reasonable. Applied. Zbyszek ___ 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 Sat, Dec 21, 2013 at 06:54:53PM -0800, Lennart Poettering wrote:
> TODO | 12 +
> src/core/automount.c |1
> src/core/busname.c |1
> src/core/dbus-automount.c|9 -
> src/core/dbus-automount.h|1
> src/core/dbus-busname.c |7 -
> src/core/dbus-busname.h |1
> src/core/dbus-cgroup.c | 22 +--
> src/core/dbus-device.c |5
> src/core/dbus-device.h |1
> src/core/dbus-execute.c | 118 -
> src/core/dbus-job.c |6
> src/core/dbus-kill.c |8 -
> src/core/dbus-manager.c | 46 +++---
> src/core/dbus-mount.c| 21 ---
> src/core/dbus-mount.h|1
> src/core/dbus-path.c | 13 -
> src/core/dbus-path.h |1
> src/core/dbus-scope.c|7 -
> src/core/dbus-scope.h|1
> src/core/dbus-service.c | 59 +++-
> src/core/dbus-service.h |1
> src/core/dbus-snapshot.c |2
> src/core/dbus-socket.c | 76 ---
> src/core/dbus-socket.h |1
> src/core/dbus-swap.c | 14 --
> src/core/dbus-swap.h |1
> src/core/dbus-timer.c| 15 --
> src/core/dbus-timer.h|1
> src/core/dbus-unit.c | 126 --
> src/core/device.c|1
> src/core/mount.c |1
> src/core/path.c |3
> src/core/scope.c |1
> src/core/service.c |1
> src/core/socket.c|1
> src/core/swap.c |1
> src/core/timer.c |1
> src/core/unit.h |3
> src/libsystemd-bus/bus-introspect.c |8 -
> src/libsystemd-bus/bus-objects.c | 212
> ---
> src/libsystemd-bus/test-bus-introspect.c |3
> src/libsystemd-bus/test-bus-objects.c| 27 +++
> src/login/logind-dbus.c | 22 +--
> src/login/logind-seat-dbus.c |6
> src/login/logind-session-dbus.c | 35 ++---
> src/login/logind-user-dbus.c | 17 +-
> src/machine/machine-dbus.c | 22 +--
> src/systemd/sd-bus-vtable.h | 15 +-
> 49 files changed, 481 insertions(+), 477 deletions(-)
>
> New commits:
> commit bee7e928990fd8a0c5909c2022a2b9eede557c81
> Author: Lennart Poettering
> Date: Sun Dec 22 03:50:30 2013 +0100
>
> update TODO
>
> diff --git a/TODO b/TODO
> index de5738e..3704445 100644
> --- a/TODO
> +++ b/TODO
> @@ -113,14 +113,13 @@ Features:
> * libsystemd-bus:
>- when kdbus doesn't take our message without memfds, try again with memfds
>- implement monitor logic
> - - when triggering property change events, allow a NULL strv indicate that
> all properties listed as such are send out as changed
>- see if we can drop more message validation on the sending side
> - - support "const" properties as flag
>- add API to clone sd_bus_message objects
>- SD_BUS_COMMENT() macro for inclusion in vtables, syntax inspired by gdbus
>- systemd-bus-proxyd needs to synthesize NameLost/NameAcquired
> + - systemd-bus-proxyd needs to enforce good old XML policy
> + - upload minimal kdbus policy into the kernel at boot
>- kdbus: matches against source or destination pids for an "strace
> -p"-like feel. Problem: The PID info needs to be available in userspace too...
> - - kdbus: we need a way to figure out whether there's currently an
> activator for a name that is already activated
>- longer term:
> * priority queues
> * priority inheritance
> @@ -129,7 +128,7 @@ Features:
> - kdbus mapping
> - NameLost/NameAcquired obsolete
> - GVariant
> - - "const" properties
> + - "const" properties (posted)
>
> * sd-event
>- allow multiple signal handlers per signal?
>
> commit aec8de63b14a93b91b85dc15bf879604352fbbe1
> Author: Lennart Poettering
> Date: Sun Dec 22 03:43:03 2013 +0100
>
> core: no need to list properties for PropertiesChanged messages anymore
>
> Since the vtable includes this information anyway, let's just use that
>
> diff --git a/src/core/automount.c b/src/core/automount.c
> index c6e0a74..c44521c 100644
> --- a/src/core/automount.c
> +++ b/src/core/automount.c
> @@ -874,7 +874,6 @@ const UnitVTable automount_vtable = {
>
> .bus_interface = "org.freedesktop.systemd1.Automount",
> .bus_vtable = bus_autom
Re: [systemd-devel] [PATCH] loginctl: fix output of type with class
On Sun, Dec 22, 2013 at 02:54:05AM +0200, Mantas Mikulėnas wrote:
> ---
> src/login/loginctl.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/src/login/loginctl.c b/src/login/loginctl.c
> index 36c65bc..5f57f62 100644
> --- a/src/login/loginctl.c
> +++ b/src/login/loginctl.c
> @@ -364,10 +364,12 @@ static void print_session_status_info(SessionStatusInfo
> *i) {
>
> printf("\n");
> } else if (i->type) {
> -printf("\tType: %s\n", i->type);
> +printf("\tType: %s", i->type);
>
> if (i->class)
> printf("; class %s", i->class);
> +
> +printf("\n");
> } else if (i->class)
> printf("\t Class: %s\n", i->class);
>
Can you rebase (if this is still an issue)?
Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] loginctl: fix output of type with class
---
src/login/loginctl.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/login/loginctl.c b/src/login/loginctl.c
index 36c65bc..5f57f62 100644
--- a/src/login/loginctl.c
+++ b/src/login/loginctl.c
@@ -364,10 +364,12 @@ static void print_session_status_info(SessionStatusInfo
*i) {
printf("\n");
} else if (i->type) {
-printf("\tType: %s\n", i->type);
+printf("\tType: %s", i->type);
if (i->class)
printf("; class %s", i->class);
+
+printf("\n");
} else if (i->class)
printf("\t Class: %s\n", i->class);
--
1.8.5.1.277.g0e0d235
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] libsystemd-login: add sd_session_get_remote_{host, user}
--- Makefile-man.am| 15 + man/sd_session_is_active.xml | 50 +++--- src/login/libsystemd-login.sym | 7 ++ src/login/sd-login.c | 28 +++ src/login/test-login.c | 14 +++- src/systemd/sd-login.h | 11 +- 6 files changed, 120 insertions(+), 5 deletions(-) diff --git a/Makefile-man.am b/Makefile-man.am index d25d642..7ca8b4f 100644 --- a/Makefile-man.am +++ b/Makefile-man.am @@ -908,8 +908,11 @@ MANPAGES_ALIAS += \ man/sd_seat_can_multi_session.3 \ man/sd_seat_can_tty.3 \ man/sd_seat_get_sessions.3 \ + man/sd_session_is_remote.3 \ man/sd_session_get_class.3 \ man/sd_session_get_display.3 \ + man/sd_session_get_remote_host.3 \ + man/sd_session_get_remote_user.3 \ man/sd_session_get_seat.3 \ man/sd_session_get_service.3 \ man/sd_session_get_state.3 \ @@ -939,8 +942,11 @@ man/sd_seat_can_graphical.3: man/sd_seat_get_active.3 man/sd_seat_can_multi_session.3: man/sd_seat_get_active.3 man/sd_seat_can_tty.3: man/sd_seat_get_active.3 man/sd_seat_get_sessions.3: man/sd_seat_get_active.3 +man/sd_session_is_remote.3: man/sd_session_is_active.3 man/sd_session_get_class.3: man/sd_session_is_active.3 man/sd_session_get_display.3: man/sd_session_is_active.3 +man/sd_session_get_remote_host.3: man/sd_session_is_active.3 +man/sd_session_get_remote_user.3: man/sd_session_is_active.3 man/sd_session_get_seat.3: man/sd_session_is_active.3 man/sd_session_get_service.3: man/sd_session_is_active.3 man/sd_session_get_state.3: man/sd_session_is_active.3 @@ -1006,6 +1012,9 @@ man/sd_seat_can_tty.html: man/sd_seat_get_active.html man/sd_seat_get_sessions.html: man/sd_seat_get_active.html $(html-alias) +man/sd_session_is_remote.html: man/sd_session_is_active.html + $(html-alias) + man/sd_session_get_class.html: man/sd_session_is_active.html $(html-alias) @@ -1021,6 +1030,12 @@ man/sd_session_get_service.html: man/sd_session_is_active.html man/sd_session_get_state.html: man/sd_session_is_active.html $(html-alias) +man/sd_session_get_remote_host.html: man/sd_session_is_active.html + $(html-alias) + +man/sd_session_get_remote_user.html: man/sd_session_is_active.html + $(html-alias) + man/sd_session_get_tty.html: man/sd_session_is_active.html $(html-alias) diff --git a/man/sd_session_is_active.xml b/man/sd_session_is_active.xml index 293ce71..d94ae19 100644 --- a/man/sd_session_is_active.xml +++ b/man/sd_session_is_active.xml @@ -66,6 +66,11 @@ +int sd_session_is_remote +const char* session + + + int sd_session_get_state const char* session char** state @@ -108,6 +113,18 @@ +int sd_session_get_remote_host +const char* session +char** remote_host + + + +int sd_session_get_remote_user +const char* session +char** remote_user + + + int sd_session_get_tty const char* session char** tty @@ -130,6 +147,11 @@ (i.e. currently in the foreground and available for user input) or not. +sd_session_is_remote() may +be used to determine whether the session identified by +the specified session identifier is a remote session +(i.e. its remote host is known) or not. + sd_session_get_state() may be used to determine the state of the session identified by the specified session identifier. The @@ -201,6 +223,23 @@ free3 call after use. +sd_session_get_remote_host() +may be used to determine the remote hostname of the +session identified by the specified session +identifier. The returned string needs to be +freed with the libc + free3 +call after use. + +sd_session_get_remote_user() +may be used to determine the remote username of the +session identified by the specified session +identifier. The returned string needs to be +freed with the libc + free3 +call after use. N
Re: [systemd-devel] [PATCH] fstab-generator: Do not try to fsck non-devices
Am 21.12.2013 12:49, schrieb Tom Gundersen:
>> -r = add_fsck(f, what, where, type, passno);
>> -if (r < 0)
>> -return r;
>> +if(is_device_path(what)) {
>> +r = add_fsck(f, what, where, type, passno);
>> +if (r < 0)
>> +return r;
>> +}
>>
>> fprintf(f,
>> "\n"
> Also, how does your patch deal with LABEL= and UUDI=?
This patch mirrors the old behaviour of the (now removed) FsckPassNo
code path.
signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 00/11] *** SUBJECT HERE ***
On Thu, Dec 19, 2013 at 02:20:10PM +0100, Florian Weimer wrote: > This patch series removes all uses of readdir_r. The changes are not > entirely mechanical, some of the patches fix bugs in error handling. > > readdir_r is rather broken on Linux because there are some directories > it cannot read. I don't think our usage was incorrect, but we never access the same DIR* from two threads, so we don't really need readdir_r anyway. Applied. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] loginctl: corretly show session IDs on session-status
On Sat, Dec 21, 2013 at 03:49:46PM +0100, Djalal Harouni wrote: > Commit f8f14b3654bcd introduced a regression that makes > loginctl session-status to not show the correct session ID(s) Applied. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] fstrim "cron" job
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. 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. Arguably Btrfs and XFS can be mounted rw from the get go. And for ext3/ext4 fsck is still done presumably because they could have journaling disabled. Chris Murphy ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] fstrim "cron" job
On Dec 21, 2013, at 6:25 AM, Bastien Nocera wrote: > > I wanted to integrate that in Fedora, through a systemd daily unit. I > was wondering whether this sort of integration (I'd intend to port the > fstrim-all code to C) should be in systemd itself, or whether it should > be a unit shipped separately (in the util-linux package maybe?). For legacy SATA 3.0 spec drives and controllers, this is useful since their non-queued TRIM command complicates issuance with the file system discard mount option by default. For SATA spec 3.1 drives and controllers, this is a queued command, so between the file systems and block layer TRIM can be asynchronous with other commands. So I'd say if you can plan the obsolescence of scheduled fstrim, and ensure it only applies to SATA rev 3.0 links, and have some way of not running the command on schedule if the block device is busy (that is, the block device could have more than one file system so it's not sufficient to poll "a" file system, you'd need to see if the device itself is busy), then I think it's OK. Otherwise I'd leave it alone for manual end user configuration, the problem goes away in about 3 years anyway. Chris Murphy ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] fstab-generator: Do not try to fsck non-devices
On Sat, Dec 21, 2013 at 5:42 PM, Kay Sievers wrote:
> On Sat, Dec 21, 2013 at 5:33 PM, Dave Reisner wrote:
>> On Sat, Dec 21, 2013 at 12:49:07PM +0100, Tom Gundersen wrote:
>>> On Sat, Dec 21, 2013 at 11:22 AM, Thomas Bächler
>>> wrote:
>>> > This fixes a regression introduced in 64e70e4 where the mount fails
>>> > when fstab is misconfigured with fs_passno > 0 on a virtual file
>>> > system like tmpfs.
>>> > ---
>>> > src/fstab-generator/fstab-generator.c | 8 +---
>>> > 1 file changed, 5 insertions(+), 3 deletions(-)
>>> >
>>> > diff --git a/src/fstab-generator/fstab-generator.c
>>> > b/src/fstab-generator/fstab-generator.c
>>> > index 1227f08..709a1c3 100644
>>> > --- a/src/fstab-generator/fstab-generator.c
>>> > +++ b/src/fstab-generator/fstab-generator.c
>>> > @@ -255,9 +255,11 @@ static int add_mount(
>>> > "Before=%s\n",
>>> > post);
>>> >
>>> > -r = add_fsck(f, what, where, type, passno);
>>> > -if (r < 0)
>>> > -return r;
>>> > +if(is_device_path(what)) {
>>> > +r = add_fsck(f, what, where, type, passno);
>>> > +if (r < 0)
>>> > +return r;
>>> > +}
>>> >
>>> > fprintf(f,
>>> > "\n"
>>>
>>> How does "fsck -A" deal with these cases?
>>
>> tmpfs falls into the category of pseudofs, which fsck -A will
>> intentionally ignore, regardless of the passno.
>>
>>> Also, how does your patch deal with LABEL= and UUDI=?
>>
>> At this point, "what" has been filtered through fstab_node_to_udev_node,
>> so LABEL=foo will be /dev/disk/by-label/foo.
>
> Generally, not sure if that it always correct here, kernel "nodev"
> superblocks have a dev_t with major == 0 and are very simple to detect
> that way.
Hm, so why doesn't fsck just deal gracefully with this?
-t
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] fstab-generator: Do not try to fsck non-devices
On Sat, Dec 21, 2013 at 5:33 PM, Dave Reisner wrote:
> On Sat, Dec 21, 2013 at 12:49:07PM +0100, Tom Gundersen wrote:
>> On Sat, Dec 21, 2013 at 11:22 AM, Thomas Bächler
>> wrote:
>> > This fixes a regression introduced in 64e70e4 where the mount fails
>> > when fstab is misconfigured with fs_passno > 0 on a virtual file
>> > system like tmpfs.
>> > ---
>> > src/fstab-generator/fstab-generator.c | 8 +---
>> > 1 file changed, 5 insertions(+), 3 deletions(-)
>> >
>> > diff --git a/src/fstab-generator/fstab-generator.c
>> > b/src/fstab-generator/fstab-generator.c
>> > index 1227f08..709a1c3 100644
>> > --- a/src/fstab-generator/fstab-generator.c
>> > +++ b/src/fstab-generator/fstab-generator.c
>> > @@ -255,9 +255,11 @@ static int add_mount(
>> > "Before=%s\n",
>> > post);
>> >
>> > -r = add_fsck(f, what, where, type, passno);
>> > -if (r < 0)
>> > -return r;
>> > +if(is_device_path(what)) {
>> > +r = add_fsck(f, what, where, type, passno);
>> > +if (r < 0)
>> > +return r;
>> > +}
>> >
>> > fprintf(f,
>> > "\n"
>>
>> How does "fsck -A" deal with these cases?
>
> tmpfs falls into the category of pseudofs, which fsck -A will
> intentionally ignore, regardless of the passno.
>
>> Also, how does your patch deal with LABEL= and UUDI=?
>
> At this point, "what" has been filtered through fstab_node_to_udev_node,
> so LABEL=foo will be /dev/disk/by-label/foo.
Generally, not sure if that it always correct here, kernel "nodev"
superblocks have a dev_t with major == 0 and are very simple to detect
that way.
Kay
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] fstab-generator: Do not try to fsck non-devices
On Sat, Dec 21, 2013 at 12:49:07PM +0100, Tom Gundersen wrote:
> On Sat, Dec 21, 2013 at 11:22 AM, Thomas Bächler wrote:
> > This fixes a regression introduced in 64e70e4 where the mount fails
> > when fstab is misconfigured with fs_passno > 0 on a virtual file
> > system like tmpfs.
> > ---
> > src/fstab-generator/fstab-generator.c | 8 +---
> > 1 file changed, 5 insertions(+), 3 deletions(-)
> >
> > diff --git a/src/fstab-generator/fstab-generator.c
> > b/src/fstab-generator/fstab-generator.c
> > index 1227f08..709a1c3 100644
> > --- a/src/fstab-generator/fstab-generator.c
> > +++ b/src/fstab-generator/fstab-generator.c
> > @@ -255,9 +255,11 @@ static int add_mount(
> > "Before=%s\n",
> > post);
> >
> > -r = add_fsck(f, what, where, type, passno);
> > -if (r < 0)
> > -return r;
> > +if(is_device_path(what)) {
> > +r = add_fsck(f, what, where, type, passno);
> > +if (r < 0)
> > +return r;
> > +}
> >
> > fprintf(f,
> > "\n"
>
> How does "fsck -A" deal with these cases?
tmpfs falls into the category of pseudofs, which fsck -A will
intentionally ignore, regardless of the passno.
> Also, how does your patch deal with LABEL= and UUDI=?
At this point, "what" has been filtered through fstab_node_to_udev_node,
so LABEL=foo will be /dev/disk/by-label/foo.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] loginctl: corretly show session IDs on session-status
Commit f8f14b3654bcd introduced a regression that makes
loginctl session-status to not show the correct session ID(s)
In print_session_status_info() the map[] array, element "Seat" receives
the offset of the "id" in "SessionStatusInfo" struct instead of the
offset of the "seat" member.
This will cause prop_map_first_of_struct() function to overwrite the
SessionStatusInfo.id memory with seats if there are any.
Fix this typo by using the "seat" member.
Before:
- tixxdz (1000)
Since: Sat 2013-12-21 10:07:23 CET; 5h 26min ago
Leader: 1265 (sshd)
After:
1 - tixxdz (1000)
Since: Sat 2013-12-21 10:07:23 CET; 5h 26min ago
Leader: 1265 (sshd)
---
src/login/loginctl.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/login/loginctl.c b/src/login/loginctl.c
index 5f3221e..725f169 100644
--- a/src/login/loginctl.c
+++ b/src/login/loginctl.c
@@ -365,7 +365,7 @@ static int print_session_status_info(sd_bus *bus, const
char *path, bool *new_li
{ "Remote", "b", NULL, offsetof(SessionStatusInfo, remote)
},
{ "Timestamp", "t", NULL, offsetof(SessionStatusInfo,
timestamp) },
{ "User", "(uo)", prop_map_first_of_struct,
offsetof(SessionStatusInfo, uid) },
-{ "Seat", "(so)", prop_map_first_of_struct,
offsetof(SessionStatusInfo, id) },
+{ "Seat", "(so)", prop_map_first_of_struct,
offsetof(SessionStatusInfo, seat) },
{}
};
@@ -412,7 +412,7 @@ static int print_session_status_info(sd_bus *bus, const
char *path, bool *new_li
printf("\n");
}
-if (i.seat) {
+if (!isempty(i.seat)) {
printf("\tSeat: %s", i.seat);
if (i.vtnr > 0)
--
1.8.3.1
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] fstrim "cron" job
Bastien Nocera hadess.net> writes: > > Hey, > > I've seen that Ubuntu recently added transparent support for trimming > filesystems on SSDs: > https://blueprints.launchpad.net/ubuntu/+spec/core-1311-ssd-trimming > and in the patch for util-linux: > https://launchpadlibrarian.net/159909554/util-linux_2.20.1-5.1ubuntu11.diff.gz > > (looks for fstrim-all) > > I wanted to integrate that in Fedora, through a systemd daily unit. I > was wondering whether this sort of integration (I'd intend to port the > fstrim-all code to C) should be in systemd itself, or whether it should > be a unit shipped separately (in the util-linux package maybe?). > > Cheers > Karel added fstrim "--all" recently (util-linux 2.24-git): https://git.kernel.org/cgit/utils/util-linux/util-linux.git/commit/?id=36c370cbf1 https://git.kernel.org/cgit/utils/util-linux/util-linux.git/commit/?id=e05a3400e7 https://git.kernel.org/cgit/utils/util-linux/util-linux.git/commit/?id=d6bbe8044b The only missing feature compared to the shell script Ubuntu ships is detect when the FS has "discard" in fstab to skip it. Once this is in place, no shell will be needed at all. Just a one-liner "ExecStart" systemd unit. -- Marcos ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] fstrim "cron" job
Am 21.12.2013 15:23, schrieb Kay Sievers: > On Sat, Dec 21, 2013 at 3:11 PM, Reindl Harald wrote: >> Am 21.12.2013 14:44, schrieb Kay Sievers: >>> 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. >> >> doing it permanently on the fs-layer degrades all time performance >> doing it in a cron job regulary does not affect performance that way > > No. Modern filesystems are like kernel services not silent and dumb > dong nothing in the background. They can do whatever they need to do > in whatever manner, and they can do it right. that's no the point the point is that mountig with trim means every time you delete something the physical disks get notified, doing it once per day avoids this overhead >>> Readahead is pointless and wrong enough already to ship and enable in >>> systemd; using slows down bootup on all of my machines >> >> yes and no >> >> the question is not only hwo long the boot process itself takes >> how long does it take until you KDE/GNOME session is fully loaded >> >> there are always a few seconds between boot and enter username / pwd >> in this time window readahead already loads things from disk which >> are need due login - the summary of both is the interesting number > > I have auto-login and using read-ahead was just slower yes because auto-login - for the sake of security not to recommend in that case you gain nothing because there is no time window between boot and login > Maybe the new block multi-queue stuff changes the picture; but in > general I'm convinced that read-ahead is a tool from the past on > current modern systems/SSDs, it should no longer be enabled by default define modern systems as long as SD cards are dying silent without any error and claiming data are written while delete, format with several filesystems and overwrite with /dev/zero as well as /dev/urandom leads to after remove the card and insert it again the old data is still there like all the overwrites and formats never happened i stay on not so modern RAID10 spindles with 4 to 12 disks which are not really slower for most usecases, more reliable and much larger flash devices typically are dying from one moment to the next while a classical harddisk starts to throw errors long before signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] fstrim "cron" job
On Sat, Dec 21, 2013 at 3:11 PM, Reindl Harald wrote: > > > Am 21.12.2013 14:44, schrieb Kay Sievers: >> 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. > > doing it permanently on the fs-layer degrades all time performance > doing it in a cron job regulary does not affect performance that way No. Modern filesystems are like kernel services not silent and dumb dong nothing in the background. They can do whatever they need to do in whatever manner, and they can do it right. Userspace can _never_ be better than a well-engineered modern file systems while it is running. Maybe if you can unmount it and do it at that time, that could be simpler and more efficient, but not while it is running. Running cron jobs for normal filesystem maintenance is just wrong at too many levels. >> Readahead is pointless and wrong enough already to ship and enable in >> systemd; using slows down bootup on all of my machines > > yes and no > > the question is not only hwo long the boot process itself takes > how long does it take until you KDE/GNOME session is fully loaded > > there are always a few seconds between boot and enter username / pwd > in this time window readahead already loads things from disk which > are need due login - the summary of both is the interesting number I have auto-login and using read-ahead was just slower. Maybe the new block multi-queue stuff changes the picture; but in general I'm convinced that read-ahead is a tool from the past on current modern systems/SSDs, it should no longer be enabled by default. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] fstrim "cron" job
Am 21.12.2013 14:44, schrieb Kay Sievers: > 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. doing it permanently on the fs-layer degrades all time performance doing it in a cron job regulary does not affect performance that way > Readahead is pointless and wrong enough already to ship and enable in > systemd; using slows down bootup on all of my machines yes and no the question is not only hwo long the boot process itself takes how long does it take until you KDE/GNOME session is fully loaded there are always a few seconds between boot and enter username / pwd in this time window readahead already loads things from disk which are need due login - the summary of both is the interesting number signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] fstrim "cron" job
On Sat, Dec 21, 2013 at 2:25 PM, Bastien Nocera wrote: > I've seen that Ubuntu recently added transparent support for trimming > filesystems on SSDs: > https://blueprints.launchpad.net/ubuntu/+spec/core-1311-ssd-trimming > and in the patch for util-linux: > https://launchpadlibrarian.net/159909554/util-linux_2.20.1-5.1ubuntu11.diff.gz > > (looks for fstrim-all) > > I wanted to integrate that in Fedora, through a systemd daily unit. I > was wondering whether this sort of integration (I'd intend to port the > fstrim-all code to C) should be in systemd itself, or whether it should > be a unit shipped separately (in the util-linux package maybe?). No, not in systemd itself. 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. 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. Readahead is pointless and wrong enough already to ship and enable in systemd; using slows down bootup on all of my machines. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] fstrim "cron" job
Hey, I've seen that Ubuntu recently added transparent support for trimming filesystems on SSDs: https://blueprints.launchpad.net/ubuntu/+spec/core-1311-ssd-trimming and in the patch for util-linux: https://launchpadlibrarian.net/159909554/util-linux_2.20.1-5.1ubuntu11.diff.gz (looks for fstrim-all) I wanted to integrate that in Fedora, through a systemd daily unit. I was wondering whether this sort of integration (I'd intend to port the fstrim-all code to C) should be in systemd itself, or whether it should be a unit shipped separately (in the util-linux package maybe?). Cheers ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] fstab-generator: Do not try to fsck non-devices
On Sat, Dec 21, 2013 at 11:22 AM, Thomas Bächler wrote:
> This fixes a regression introduced in 64e70e4 where the mount fails
> when fstab is misconfigured with fs_passno > 0 on a virtual file
> system like tmpfs.
> ---
> src/fstab-generator/fstab-generator.c | 8 +---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/src/fstab-generator/fstab-generator.c
> b/src/fstab-generator/fstab-generator.c
> index 1227f08..709a1c3 100644
> --- a/src/fstab-generator/fstab-generator.c
> +++ b/src/fstab-generator/fstab-generator.c
> @@ -255,9 +255,11 @@ static int add_mount(
> "Before=%s\n",
> post);
>
> -r = add_fsck(f, what, where, type, passno);
> -if (r < 0)
> -return r;
> +if(is_device_path(what)) {
> +r = add_fsck(f, what, where, type, passno);
> +if (r < 0)
> +return r;
> +}
>
> fprintf(f,
> "\n"
How does "fsck -A" deal with these cases?
Also, how does your patch deal with LABEL= and UUDI=?
Cheers,
Tom
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] fstab-generator: Do not try to fsck non-devices
This fixes a regression introduced in 64e70e4 where the mount fails
when fstab is misconfigured with fs_passno > 0 on a virtual file
system like tmpfs.
---
src/fstab-generator/fstab-generator.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/src/fstab-generator/fstab-generator.c
b/src/fstab-generator/fstab-generator.c
index 1227f08..709a1c3 100644
--- a/src/fstab-generator/fstab-generator.c
+++ b/src/fstab-generator/fstab-generator.c
@@ -255,9 +255,11 @@ static int add_mount(
"Before=%s\n",
post);
-r = add_fsck(f, what, where, type, passno);
-if (r < 0)
-return r;
+if(is_device_path(what)) {
+r = add_fsck(f, what, where, type, passno);
+if (r < 0)
+return r;
+}
fprintf(f,
"\n"
--
1.8.5.2
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 00/11] *** SUBJECT HERE ***
On Fri, Dec 20, 2013 at 11:59:16AM -0800, Shawn Landden wrote: > On Fri, Dec 20, 2013 at 11:50 AM, Colin Walters wrote: > > On Thu, 2013-12-19 at 14:20 +0100, Florian Weimer wrote: > > > >> readdir_r is rather broken on Linux because there are some directories > >> it cannot read. > > > > Citation? Are you talking about > > http://womble.decadent.org.uk/readdir_r-advisory.html > kinda unrelated, but this reminds me that with pid namespaces, > /proc/self doesn't necessarily > always work anymore even if /proc is mounted. It should work within a separate mount namespace and /proc mounted, accesses to the /proc// are in the context of that PID namespace. -- Djalal Harouni http://opendz.org ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
