Re: [systemd-devel] [PATCH] systemctl: allow to change the default target without the --force switch
On Mon, 14.04.14 01:07, Djalal Harouni (tix...@opendz.org) wrote: Currently systemctl set-default will fail to change the default target due to the 'default.target' being a symlink which is always the case. Humm, no? Normally default.target should not exist in /etc, only in /usr. This means systemctl set-default should just work if it is run on a pristine system, and only requires --force if there's already user configuration in place that is conflicting. To work around this, the user must specify the --force switch to be able to overwrite the existing symlink. This is clearly a regression that was introduced by commit 718db96199e since it worked before without the --force switch and the man pages do not mention that you need to specify it. It is expected that this is a symlink. So just explicity set the force flag to make it work again. https://bugs.freedesktop.org/show_bug.cgi?id=76623 Hmm, I find the behaviour before this patch actually more sensible, since it treats this symlink like any other symlink we create/remove in install.c. It appears more like a issue of printing a nice error message that informs the user that --force might be a good idea to use when this happens... But anyway, my opinion on this isn't very strong, so I am going to leave this patch as is. 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] Systemd askpassword
On Sat, 12.04.14 22:08, Ismael Bouya (ismael.bo...@normalesup.org) wrote: (Side question: Is there a way to say that systemd-tty-ask-password-agent can be run by the user and not only by root to mount the disk? If he know the disk password then he's most probably allowed to mount it...) The GNOME password agent I wrote does support this, but it will do this only via a PoliyKit security transition. I am pretty sure that's necessary because setting up a LUKS volume is a relatively heavy operation, due to the hashing involved. We shouldn't open up such heavy operations to unpriviligied users without involing some kind of auth, so that users cannot simply DoS this. 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] Default file permissions in user mode
On Sat, 12.04.14 12:14, Tanu Kaskinen (tanu.kaski...@linux.intel.com) wrote: Hi, The systemd.socket man page says that the default value for DirectoryMode is 0755. Judging from the code in the socket_init() function, the documentation matches the implementation. 0755 seems appropriate for the system mode, but wouldn't 0700 be better for the user mode? Likewise for the default socket mode 0666 vs. 0600, and probably similar permissions are specified elsewhere too. The usual approach for user code is to keep things as closed as necessary and as open as possible and leave the rest to the user with umask or parent directories. 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] names: take the registry write lock in kdbus_name_release()
On Fri, Apr 18, 2014 at 9:55 PM, David Herrmann dh.herrm...@gmail.com wrote: On Fri, Apr 18, 2014 at 3:16 AM, Djalal Harouni tix...@opendz.org wrote: Take the write lock in kdbus_name_release() instead of kdbus_cmd_name_release() in order to reduce the lock hold time. This change permits to convert the kdbus_bus_find_conn_by_id() call to kdbus_conn_find_peer() since the bus lock will also be taken later in kdbus_name_release(). Another advantage is that now kdbus_cmd_name_release() and kdbus_name_release() have the same semantic of kdbus_cmd_name_acquire() and kdbus_name_acquire() Signed-off-by: Djalal Harouni tix...@opendz.org Looks good to me. Applied. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Persistent timers delay Type=idle units
Am 22.04.2014 07:07, schrieb Lennart Poettering: On Fri, 18.04.14 11:34, Thomas Bächler (tho...@archlinux.org) wrote: According to [1], when a persistent timer runs its service on boot, it delays startup. Humm? What precisely do you mean by delays bootup? Just scheduling a timer unit should have about zero effect on boot times... If it does this would be a bug. From the description that I linked in the first post, it seems that the unit it started as soon as the timer is started. I don't know if delay bootup is the right expression, but the Type=idle units, like getty, don't start until the timer's unit finished starting up. What does systemctl list-jobs print when this happens? (i.e. when the bootup is supposedly delayed?) I'd have to build a test-case for this, since I have not seen any negative effect myself yet (I can't do this until later this week). I'm CC'ing the original reporter, maybe he can give more information. 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] Persistent timers delay Type=idle units
On Tue, Apr 22, 2014 at 9:37 AM, Thomas Bächler tho...@archlinux.org wrote: I'm CC'ing the original reporter, maybe he can give more information. I think you forgot to do that... -t ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Persistent timers delay Type=idle units
Am 22.04.2014 10:33, schrieb Tom Gundersen: On Tue, Apr 22, 2014 at 9:37 AM, Thomas Bächler tho...@archlinux.org wrote: I'm CC'ing the original reporter, maybe he can give more information. I think you forgot to do that... Strange stuff - he is listed in CC in the mail I received, but his address is missing on-list. 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] systemctl: allow to change the default target without the --force switch
On Tue, Apr 22, 2014 at 08:01:43AM +0200, Lennart Poettering wrote: On Mon, 14.04.14 01:07, Djalal Harouni (tix...@opendz.org) wrote: Currently systemctl set-default will fail to change the default target due to the 'default.target' being a symlink which is always the case. Humm, no? Normally default.target should not exist in /etc, only in /usr. This means systemctl set-default should just work if it is run on a pristine system, and only requires --force if there's already user configuration in place that is conflicting. Yes, you are right! To work around this, the user must specify the --force switch to be able to overwrite the existing symlink. This is clearly a regression that was introduced by commit 718db96199e since it worked before without the --force switch and the man pages do not mention that you need to specify it. It is expected that this is a symlink. So just explicity set the force flag to make it work again. https://bugs.freedesktop.org/show_bug.cgi?id=76623 Hmm, I find the behaviour before this patch actually more sensible, since it treats this symlink like any other symlink we create/remove in install.c. It appears more like a issue of printing a nice error message that informs the user that --force might be a good idea to use when this happens... But anyway, my opinion on this isn't very strong, so I am going to leave this patch as is. Ok, Thanks. IMO we shouldn't care too much, apart from the first set-default, 1) it will always be a symlink, 2) the necessary security checks are there. Lennart -- Lennart Poettering, Red Hat -- Djalal Harouni http://opendz.org ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-networkd: setting the MAC address for a .netdev unit?
Hi Matthias, On Fri, Apr 18, 2014 at 1:08 AM, Matthias Schiffer mschif...@universe-factory.net wrote: On 04/18/2014 12:14 AM, Matthias Schiffer wrote: On 04/17/2014 11:28 PM, Dave Reisner wrote: On Thu, Apr 17, 2014 at 11:02:11PM +0200, Matthias Schiffer wrote: Hi, I'd like to configure the MAC address of a bridge device statically (as bridges tend to change their MAC address depending on the order the ports are added on Linux otherwise), but there doesn't seem to be a way to match for a bridge in a .link unit. This would be very useful for macvlans as well. Link files can match bridges generally with Type=bridge or Driver=bridge in the [Match] section, or more specifically by just matching on name. In the [Link] section, MACAddressPolicy=persistent should give you persistent hw addresses in the general case, or you can use MACAddress=fe:ed:fa:ce:be:ef to set whatever you like for more specific matches. Does this not work for you? Hmm, I thought I tried that before, but using MACAddress=fe:ed:fa:ce:be:ef seems to work now. Please note that the Name= match is not documented in the systemd.link manpage. I have to correct myself: The Name= match does not exist for .link units. My testcase just seemed to work as a [Match] section only consisting of a Name= match was considered an empty [Match] section and matched on all devices... This should really be added as AFAICT there is currently no way to match on virtual devices like briges, TAP devices, batman-adv devices, etc... which have neither a persistent MAC address nor an ID_PATH to match on. So I think what we should do here is to allow MAC address (and other things) to be set when creating the netdevs. I made an attempt at this by generating a predictable one based on the interface name and the machine-id. Would that do it for you, or are you after a _specific_ mac address, rather than just one that is always the same? I had to revert the code doing this for now as there was a kernel bug, however we'll hopefully get that sorted soon and then get back to this. Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-networkd: setting the MAC address for a .netdev unit?
On 04/22/2014 04:07 PM, Tom Gundersen wrote:
Hi Matthias,
On Fri, Apr 18, 2014 at 1:08 AM, Matthias Schiffer
mschif...@universe-factory.net wrote:
On 04/18/2014 12:14 AM, Matthias Schiffer wrote:
On 04/17/2014 11:28 PM, Dave Reisner wrote:
On Thu, Apr 17, 2014 at 11:02:11PM +0200, Matthias Schiffer wrote:
Hi,
I'd like to configure the MAC address of a bridge device statically (as
bridges tend to change their MAC address depending on the order the
ports are added on Linux otherwise), but there doesn't seem to be a way
to match for a bridge in a .link unit. This would be very useful for
macvlans as well.
Link files can match bridges generally with Type=bridge or Driver=bridge
in the [Match] section, or more specifically by just matching on name.
In the [Link] section, MACAddressPolicy=persistent should give you
persistent hw addresses in the general case, or you can use
MACAddress=fe:ed:fa:ce:be:ef to set whatever you like for more specific
matches.
Does this not work for you?
Hmm, I thought I tried that before, but using
MACAddress=fe:ed:fa:ce:be:ef seems to work now. Please note that the
Name= match is not documented in the systemd.link manpage.
I have to correct myself: The Name= match does not exist for .link
units. My testcase just seemed to work as a [Match] section only
consisting of a Name= match was considered an empty [Match] section and
matched on all devices...
This should really be added as AFAICT there is currently no way to match
on virtual devices like briges, TAP devices, batman-adv devices, etc...
which have neither a persistent MAC address nor an ID_PATH to match on.
So I think what we should do here is to allow MAC address (and other
things) to be set when creating the netdevs. I made an attempt at this
by generating a predictable one based on the interface name and the
machine-id. Would that do it for you, or are you after a _specific_
mac address, rather than just one that is always the same? I had to
revert the code doing this for now as there was a kernel bug, however
we'll hopefully get that sorted soon and then get back to this.
Cheers,
Tom
For my usecase, a predictable, but otherwise random MAC address would
do. But I also see that setting an arbitrary MAC address (or any other
link parameter) for a specific virtual device is useful as well
(especially as it is possible to do so with real devices). As virtual
devices are almost always created with specific names, a Name= match for
.link units would make the most sense in my opinion.
As a workaround, I've added the following udev rule to
80-net-setup-link.rules for now to allow matching for virtual devices
with Path= matches:
ENV{DEVPATH}==/devices/virtual/net/*, ENV{ID_PATH}==,
ENV{ID_PATH}=virtual-$kernel
Thanks,
Matthias
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] Unit configuration for S3QL filesystem
Lennart Poettering lenn...@poettering.net writes: On Mon, 21.04.14 19:05, Diogo Vieira (d...@eurotux.com) wrote: Hello, I'm trying to create a unit to automatically mount a fuse filesystem known as S3QL, which is the one in question in this older thread: http://lists.freedesktop.org/archives/systemd-devel/2012-May/005062.html. The problem seems to be that after unmounting the filesystem it still needs network access to transfer data. Can someone tell me if it's already possible to create a mount unit configuration that covers this or should I go with a service unit? And if I need a service unit how do I deal with the chance of someone manually unmounting the filesystem thus making (I believe, didn't test it) the service status return successfully when in fact the filesystem's not mounted? I don't know if it's useful, but I'm trying this on Fedora. systemd will invoke /bin/mount when mounting a file system, and /bin/umount when unmountin it. fuse file systems may fork off background processes from there, that will be kept around while the file system is mounted, and terminated atfer the file system is unmounted again. Is there any way to avoid that, and give the background process some time to terminate on its own? Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Persistent timers delay Type=idle units
Hi, I'll try to answer all questions at once... On Tue, 22 Apr 2014 09:37:29 +0200 Thomas Bächler tho...@archlinux.org wrote: Am 22.04.2014 07:07, schrieb Lennart Poettering: Humm? What precisely do you mean by delays bootup? Just scheduling a timer unit should have about zero effect on boot times... If it does this would be a bug. This is right for the usual, e.g. OnBootSec= timers. Just to give a little background, archlinux has recently replaced daily cron jobs (like indexing of man and locate databases) with OnCalendar= timers: https://mailman.archlinux.org/pipermail/arch-dev-public/2014-March/026044.html . From the description that I linked in the first post, it seems that the unit it started as soon as the timer is started. I don't know if delay bootup is the right expression, but the Type=idle units, like getty, don't start until the timer's unit finished starting up. Right. I see no delay between scheduling an OnCalendar= timer and starting the corresponding service. This wouldn't be a problem in general, but if the /var/lib/systemd/stamp-... file is old enough, the timer and service are launched at boot. However, the latter usually takes some time to start. Ideally, one would like to specify the above delay in the .timer file, because services started by the OnCalendar timers are sometimes maintainance jobs and not always needed for booting the system. What does systemctl list-jobs print when this happens? (i.e. when the bootup is supposedly delayed?) I'll have to test this, but I'll speculate that list-jobs will show nothing by the time I login, because it takes about 30 sec for me to enter login credentials... Thanks, L. -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D signature.asc Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Compilation with gcc-4.9 fails
On Monday 2014-03-03 07:51, Jan Engelhardt wrote: When building with GCC 4.9.0 [svn r208221], then the following happens: [...] $ nm src/libsystemd/sd-bus/.libs/libsystemd_la-sd-bus.o 0001 C __gnu_lto_slim 0001 C __gnu_lto_v1 $ make [...] CCLD libgudev-1.0.la /usr/bin/ld.gold: error: .libs/libgudev-1.0.ver:2:1: syntax error, unexpected LOCAL, expecting STRING or QUOTED_STRING or EXTERN /usr/bin/ld.gold: fatal error: unable to parse version script file .libs/libgudev-1.0.ver collect2: error: ld returned 1 exit status A workaround is to use ./configure NM=gcc-nm-4.9 Ultimately this is something for the libtool and/or gcc projects to tackle, systemd is not the culprit here. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Compilation with gcc-4.9 fails
El 22/04/14 20:05, Jan Engelhardt escribió: On Monday 2014-03-03 07:51, Jan Engelhardt wrote: When building with GCC 4.9.0 [svn r208221], then the following happens: [...] $ nm src/libsystemd/sd-bus/.libs/libsystemd_la-sd-bus.o 0001 C __gnu_lto_slim 0001 C __gnu_lto_v1 $ make [...] CCLD libgudev-1.0.la /usr/bin/ld.gold: error: .libs/libgudev-1.0.ver:2:1: syntax error, unexpected LOCAL, expecting STRING or QUOTED_STRING or EXTERN /usr/bin/ld.gold: fatal error: unable to parse version script file .libs/libgudev-1.0.ver collect2: error: ld returned 1 exit status A workaround is to use ./configure NM=gcc-nm-4.9 I was just debugging this (and loosing the remaining hair) , I already realized this is a bug in some piece of the toolchain by now.. but this helps very much, thanks :-) -- Cristian I don't know the key to success, but the key to failure is trying to please everybody. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Compilation with gcc-4.9 fails
El 22/04/14 20:05, Jan Engelhardt escribió: On Monday 2014-03-03 07:51, Jan Engelhardt wrote: When building with GCC 4.9.0 [svn r208221], then the following happens: [...] $ nm src/libsystemd/sd-bus/.libs/libsystemd_la-sd-bus.o 0001 C __gnu_lto_slim 0001 C __gnu_lto_v1 $ make [...] CCLD libgudev-1.0.la /usr/bin/ld.gold: error: .libs/libgudev-1.0.ver:2:1: syntax error, unexpected LOCAL, expecting STRING or QUOTED_STRING or EXTERN /usr/bin/ld.gold: fatal error: unable to parse version script file .libs/libgudev-1.0.ver collect2: error: ld returned 1 exit status A workaround is to use ./configure NM=gcc-nm-4.9 Ultimately this is something for the libtool and/or gcc projects to tackle, systemd is not the culprit here. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel Complete workaround, you also have to export AR=gcc-ar-4.9 for systemd git head to build correctly without modification. Still this pesky warning shows up everywhere.. /usr/include/bits/poll2.h: In function 'bus_poll': /usr/include/bits/poll2.h:71:2: warning: call to '__ppoll_chk_warn' declared with attribute warning: ppoll called with fds buffer too small file nfds entries [enabled by default] return __ppoll_chk (__fds, __nfds, __timeout, __ss, __bos (__fds)); happens with lto enabled only.. guess it is another compiler bug.. -- Cristian I don't know the key to success, but the key to failure is trying to please everybody. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] gudev: avoid using export-symbols-regex
There is no need for this hackery, just hide the internal functions using glib 's G_GNUC_INTERNAL macro. --- Makefile.am | 3 +-- src/gudev/gudevprivate.h | 4 ++-- 2 files changed, 3 insertions(+), 4 deletions(-) diff --git a/Makefile.am b/Makefile.am index 6967b6f..903d888 100644 --- a/Makefile.am +++ b/Makefile.am @@ -3016,8 +3016,7 @@ libgudev_1_0_la_LIBADD = \ libgudev_1_0_la_LDFLAGS = \ $(AM_LDFLAGS) \ -version-info $(LIBGUDEV_CURRENT):$(LIBGUDEV_REVISION):$(LIBGUDEV_AGE) \ - -export-dynamic -no-undefined \ - -export-symbols-regex '^g_udev_.*' + -no-undefined src/gudev/gudevmarshal.h: src/gudev/gudevmarshal.list $(AM_V_at)$(MKDIR_P) $(dir $@) diff --git a/src/gudev/gudevprivate.h b/src/gudev/gudevprivate.h index 52e272b..a656ff2 100644 --- a/src/gudev/gudevprivate.h +++ b/src/gudev/gudevprivate.h @@ -31,9 +31,9 @@ G_BEGIN_DECLS GUdevDevice * -_g_udev_device_new (struct udev_device *udevice); +_g_udev_device_new (struct udev_device *udevice) G_GNUC_INTERNAL; -struct udev *_g_udev_client_get_udev (GUdevClient *client); +struct udev *_g_udev_client_get_udev (GUdevClient *client) G_GNUC_INTERNAL; G_END_DECLS -- 1.8.4.5 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Unit configuration for S3QL filesystem
On Tue, 22.04.14 07:48, Nikolaus Rath (nikol...@rath.org) wrote: Lennart Poettering lenn...@poettering.net writes: On Mon, 21.04.14 19:05, Diogo Vieira (d...@eurotux.com) wrote: Hello, I'm trying to create a unit to automatically mount a fuse filesystem known as S3QL, which is the one in question in this older thread: http://lists.freedesktop.org/archives/systemd-devel/2012-May/005062.html. The problem seems to be that after unmounting the filesystem it still needs network access to transfer data. Can someone tell me if it's already possible to create a mount unit configuration that covers this or should I go with a service unit? And if I need a service unit how do I deal with the chance of someone manually unmounting the filesystem thus making (I believe, didn't test it) the service status return successfully when in fact the filesystem's not mounted? I don't know if it's useful, but I'm trying this on Fedora. systemd will invoke /bin/mount when mounting a file system, and /bin/umount when unmountin it. fuse file systems may fork off background processes from there, that will be kept around while the file system is mounted, and terminated atfer the file system is unmounted again. Is there any way to avoid that, and give the background process some time to terminate on its own? It has that. We always send SIGTERM first, and after a timeout of 90s (by default) this is followed by SIGKILL if the process didn't exit on its own by then. Your fuse file system should simply handle SIGTERM properly, like any other UNIX process... 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] Persistent timers delay Type=idle units
On Tue, 22.04.14 12:13, Leonid Isaev (lis...@umail.iu.edu) wrote: Am 22.04.2014 07:07, schrieb Lennart Poettering: Humm? What precisely do you mean by delays bootup? Just scheduling a timer unit should have about zero effect on boot times... If it does this would be a bug. This is right for the usual, e.g. OnBootSec= timers. Just to give a little background, archlinux has recently replaced daily cron jobs (like indexing of man and locate databases) with OnCalendar= timers: https://mailman.archlinux.org/pipermail/arch-dev-public/2014-March/026044.html . Awesome! This sounds great! From the description that I linked in the first post, it seems that the unit it started as soon as the timer is started. I don't know if delay bootup is the right expression, but the Type=idle units, like getty, don't start until the timer's unit finished starting up. Right. I see no delay between scheduling an OnCalendar= timer and starting the corresponding service. This wouldn't be a problem in general, but if the /var/lib/systemd/stamp-... file is old enough, the timer and service are launched at boot. However, the latter usually takes some time to start. Ideally, one would like to specify the above delay in the .timer file, because services started by the OnCalendar timers are sometimes maintainance jobs and not always needed for booting the system. Ah, OK, I think I got it now: You have services that are to be started by timers that take a long time to complete. THe timers have been configured to be persistent. If the system comes up and the timestamp files suggest that the timers need to be triggered immediately this is done, adding the service execution time to the bootup time. This is normally not a problem except when there's some other bootup service that uses Type=idle which will then be affected by these long running services... Did I get this right? Hmm, this sounds nasty. I wodner what we can do about it... Maybe we should add a new setting PersistentExtraSec= to timer units or so which allows delaying these kind of timers by an extra margin. Would this work for you? What does systemctl list-jobs print when this happens? (i.e. when the bootup is supposedly delayed?) I'll have to test this, but I'll speculate that list-jobs will show nothing by the time I login, because it takes about 30 sec for me to enter login credentials... Use systemctl enable debug-shell... 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] Proper use of the Session.Unlock method call
On Thu, 03.04.14 21:42, Kirill Elagin (kirela...@gmail.com) wrote: Hi, There are plenty people who have some kind of automatic session unlocking set up. Examples are: BT phone proximity, USB-drive being plugged in, etc. This is normally done via DBus `ScreenSaver.SetActive(false)` call, but this interface is not well-documented and, actually, it seems that this call is intended only for screen saver disabling and is not meant for session unlocking. This is exactly the way the guys from KDE decided to interpret the interface: they take any possibility to unlock a session without entering the user's password to be a bug.[1] When presented with a number of convincing arguments in favour of some kind of auto-unlock functionality, their answer now is “KDE session manager is going to respect logind's Lock/Unlock signals, so do your unlocking stuff through logind”. So, my question is this: what is the intended use of the `Session.Unlock` call, is it acceptable to employ this method to achieve this kind of auto-unlocking functionality? Hmm, I mostly took this call over from ConsoleKit. Given that the method is called Unlock it should probably really unlock, and not ask the user for any password. It's a priviliged method call, hence this should be safe. Here is how I see it: * User attaches his USB-drive. * Special udev invokes a helper. * The helper looks inside the drive and determines the owner. * Checks the owner configuration, performs the drive authentication. * If everything is fine, it enumerates all the sessions of this user (proper multi-session!) * and unlocks them. The issue here is that the `Session.Unlock` method is privileged, so I'm not sure yet how to go with that. In case of udev everything is OK as it's running as root, but this is not always the case. So, `pkexec`? Or maybe something completely different? Yeah, this sounds like a valid usecase for Unlock() to me, and yes, you'd have to add pkexec or sudo or some other kind of authenticated security transition to this if you want to open this up for specific unpriviliged programs. 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] systemd-udevd seems to kill mount.ntfs started in rules scripts?
On Thu, 03.04.14 16:13, Barry Scott (barry.sc...@onelan.co.uk) wrote:
More of my porting from F16 to F20.
I have the following in /etc/udev/rules.d
ACTION==add, SUBSYSTEM==block, SUBSYSTEMS==usb,
RUN+=/usr/local/onelan/ntb/bin/ntb_mount_usb
ACTION==remove, SUBSYSTEM==block, SUBSYSTEMS==usb,
RUN+=/usr/local/onelan/ntb/bin/ntb_mount_usb
This run the ntb_mount_usb script as expected.
The script on the ADD action ends up doing:
mount -t ntfs -o uid=onelan,gid=onelan,noatime,noexec ${DEVNAME} /my-mount-
point
As mentioned by others in this trhead, you need to invoke such scripts
as systemd units, as we'll kill all remaining worker processes after we
are done with all the work from udev.
Also note that very recent udev versions will run in their own mount
namespace, which disables propagation of mounts from udev to the
host. Hence, if you want to mount something from udev, the best approach
is to simply use nofail in fstab, and if you need more complex matches
pulling in the .mount unit via SYSTEMD_WANTS from an udev rule.
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] LXC not working with systemd 209 or later
On Sat, 05.04.14 22:04, John Lane (syst...@jelmail.com) wrote: it starts: will see journal output in the console boot messages, like this: 30systemd[1]: Set hostname to test. you can log in as root. no password. Long delay. Eventual user@0.service start operation timed out. Terminating You can then halt. slow to stop. user@0.service start operation timed out. Terminating takes 90 seconds. Eventually stops, host prompt returned. Is this still an issue? This appears to be some issue related to checking whether cgroups are empty, and properly getting notified about it... It might be worth checking whether the cgroup tree you run this in is properly empty before you start the container... 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] seat 0 provided by standalone X server (Xspice, xvnc)
On Tue, 01.04.14 15:31, David Jaša (dj...@redhat.com) wrote: Hi, I'm looking at clean solution how to create additional seat for standalone, self-contained X server (one X server per seat, X server does not rely on any physical hardware). Such X server are xvnc or Xspice. I could find a dated howto for such a configuration: http://zeusville.wordpress.com/2012/01/27/setting-up-vncserver-on-fedora-16/ and two oldish related bugs from time of logind transition: https://bugzilla.redhat.com/show_bug.cgi?id=896648 https://bugzilla.redhat.com/show_bug.cgi?id=988030 some 1ft overview of multi-seat with systemd-logind: http://www.freedesktop.org/wiki/Software/systemd/multiseat/ and it's detailed dbus interface: http://www.freedesktop.org/wiki/Software/systemd/logind/ What I miss is a general overview of how should things work together. More specifically: The seat concept exposed by logind is about device management. Thus, for virtual sessions like ssh, xvnc, xspice the concept does not apply at all, because they don't need access to any physical device. Sessions in logind are either attached to a seat or not. Virtual sessions are not. 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] Unable to override systemd-udevd.service
On Sun, 30.03.14 19:23, Andrey Borzenkov (arvidj...@gmail.com) wrote: linux-qbc6:~ # systemctl show systemd-udevd.service -p FragmentPath FragmentPath=/usr/lib/systemd/system/systemd-udevd.service linux-qbc6:~ # cp /usr/lib/systemd/system/systemd-udevd.service /etc/systemd/system linux-qbc6:~ # systemctl daemon-reload linux-qbc6:~ # cp /usr/lib/systemd/system/systemd-udevd.service /etc/systemd/system linux-qbc6:~ # systemctl show systemd-udevd.service -p FragmentPath FragmentPath=/usr/lib/systemd/system/systemd-udevd.service linux-qbc6:~ # exit From non-exhaustive testing it appears to be the only unit showing this property. Enabling systemd debug does not add any useful information (no output about unit discovery). Any way to debug it? The version is systemd-208-19.1.x86_64 from openSUSE. Hmm, that's weird. Is /etc on some weird mount point or so? It might be interesting to run strace -o log -e open -p 1 and then trigger a reload, and then look at the generate log file log. It should show you where systemd is looking for the udev service file, and might contain a hint, why it skips the file in /etc? 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] backlight: do nothing if max_brightness is 0
On Thu, 27.03.14 23:41, Thomas Bächler (tho...@archlinux.org) wrote: On virtually any newer Asus mainboard, the eeepc-wmi driver is loaded. It exposes a backlight device despite the lack of any physical backlight devices. This fake backlight device has max_brightness set to 0. Since the introduction of the clamp_brightness function, systemd-backlight tries to write '1' to brightness and fails. This patch changes systemd-backlight to exit gracefully when max_brightness is 0 before performing any action. This affects both the load and save actions. Humm. To me this appears like the driver is broken. The kernel should not expose a backlight device if there isn't any backend to it? Have you filed a kernel bug? I have changed git now to still print a warning in this case, as we shouldn't silently tape over broken drivers. 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] build: change tcpwrappers support to disabled by default
On Tue, 25.03.14 19:11, Michael Biebl (mbi...@gmail.com) wrote: 2014-03-20 20:29 GMT+01:00 Lennart Poettering lenn...@poettering.net: TO figure out what we can do in Fedora I have now started a discussion on fedora-devel, about getting rid of tcpwrap system-wide. Let's see where this goes. Would be interested in feedback about this from other distros too. I don't really have an opinion on this, just wanted to share that on Debian apparently there is no unit file using TCPWrapName [0] so it's probably not going to be a big deal for us. That said, you mentioned that packages still can utilise tcpd. How exactly would that work for a socket-activated service? If you have a socket service for a binary /usr/bin/foobard, then simply use: ExecStart=@/usr/sbin/tcpd /usr/bin/foobard This is pretty much identical to how you would plug tcpd into inetd. The @ is required to tell systemd that the second string passed shall actually be set as argv[0], which is the moronic way how tcpd expects the binary to invoke to be told. See tcpd(8) for details. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
