Re: [systemd-devel] shutdown
On 12/04/2014 04:26 PM, Lennart Poettering wrote: On Fri, 31.10.14 18:50, Tom Deblauwe (deblauwe...@gmail.com) wrote: Hmm, this smells like 4b5d8d0f22ae61ceb45a25391354ba53b43ee992 might fix your issue? Could you verify that this is the issue you are running into? Hello, Thanks for the reply. I am using buildroot with systemd and after searching and trying out many things, I decided to just override the systemd-shutdown.service and systemd-reboot.service by changing in both cases the ExecStart= line to this: ExecStart=/sbin/reboot -f and ExecStart=/sbin/poweroff -f And this works for me. So I was searching for some hanging jobs, but it turned out no jobs were hanging and it was just the shutdown that didn't work ok. Best regards Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] networkd: Support setting mtu / mac address by interface name
Hi Lennart, Moreover, if we give people this feature I'm pretty sure we'll get lots of people expecting it to work also for any other sort of name and getting confused when it doesn't. Well, this is something we can fix by documentation, no? Or maybe name the match option differently, maybe OriginalName= or KernelName= or so, and then only matching interfaces where you know that the name was selected by userspace in the first place? I like the idea of OriginalName, much less likely to get people confused. I now implemented that, with the restriction that we cannot match on renamed names. For now I left it open to match on ethX style names, as people in principle could do sensible things like OriginalName=eth* or even OriginalName=eth0 when we know there is only one interface. One thing to consider would be to disallow renaming from a .link file where the OriginalName was used to match. That way we don't have the somewhat odd situation that a .link file can only be applied once (we do not remember the original name, so cannot match on that the second time around, as that would be a mess)... Maybe we should even store the original name in a udev property, so that we can make this fully idempotent simply because we can always check this new property for the original name passed down from the kernel? you do realize that once the kernel renamed the name, it is free to reuse that name again. So eth0 as OriginalName can then be present multiple times. I think that you can only have OriginalName matching if a renaming has never occurred. Otherwise this is really not deterministic. Since foo0 (renamed from eth0) and and bar0 (renamed from eth0) will both match OriginalName=eth0. The difference is only timing and that is inhering racy of course. Regards Marcel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-nspawn@.service is unusable
2014-12-05 4:43 GMT+03:00 Lennart Poettering lenn...@poettering.net: On Thu, 04.12.14 20:12, Peter Lemenkov (lemen...@gmail.com) wrote: Hello All! I'm playing with systemd-nspawn@.service and cannot make it work. It seems that similar issues were discussed (and addressed upstream) in Debian bug #770275 ( https://bugs.debian.org/770275 ) however I believe I've hit by something else. What I've done so far: * Ensured that /var/lib/container exists * Created both /var/log/journal/machineid and /var/lib/container/containername/var/log/journal/machineid * Ensured that Storage=persistent is set in /var/lib/container/containername/etc/systemd/journald.conf Every my attempt to run systemctl status systemd-nspawn@containername ended up like this: https://paste.fedoraproject.org/156640/14177088/ Please note that systemd-journald fails so I can't find out what's going on there. I'm stuck right here. Some other services failed as well, and I can't login using machinectl login but that's another story I believe. Any advice on how to debug this and make systemd-nspawn@containername usable are highly appreciate! What happens if you run the same nspawn command from the command line? Does journald then start up correctly in it? Yes, it works perfectly fine if I run it as $ sudo /usr/bin/systemd-nspawn --keep-unit --boot --directory=/var/lib/container/earlyannounce I can login and see logs. Unfortunately no logs from the previous boot are available (due to failed systemd-journald.service). What happens if you add debug to the end of the nspawn cmdline? Do you see anything interesting in the additional log output this generates? Can't say for sure. Here is a diff between two logs (with whitespace ignored) - first one is successful boot, second one is the failed boot (using systemd service): * https://paste.fedoraproject.org/156867/77223114/raw/ And here are actual boot logs: * https://paste.fedoraproject.org/156862/17770249/ (from the service-file) * https://paste.fedoraproject.org/156862/17770249/ (using the command mentioned above) -- With best regards, Peter Lemenkov. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] /usr vs /etc for default distro units enablement
Le 05/12/2014 02:13, Lennart Poettering a écrit : On Tue, 02.12.14 12:50, Didier Roche (didro...@ubuntu.com) wrote: Just to sum up other branches of this thread: we are trying to avoid having systemctl calls in debian/ubuntu postinst (or duplicated manual symlinks logic as we currently have). systemctl preset seems the cleanest path, but we want to ensure corner cases can be handled. d/u policy is to enable newly installed package by default (difference from other distributions) Le 02/12/2014 01:59, Lennart Poettering a écrit : I don't think we should have systemctl preset new_service running under any condition as a wipe of /etc and then systemctl preset-all would give a potential different result (I'm not even sure how this will work with those alias, the first matching the alias wins and get the symlinks?) Dont follow? wipe? I meant deleting the entire /etc content (or I guess as you told using systemctl preset-all to reset to default): 1. lightdm and gdm were installed on my system. 2. gdm was enabled as the default display-manager. 3. I then use systemctl preset-all - how the behavior of selecting the display-manager will be determined? See below implementing this with presets where enabling all services is the default. Hmm, this is actually undefined currently. THe code for preset-all iterates through the unit paths and processes the files in the order they are read by readdir(), which is pretty much undefined. We really should investigate what to do about that. Probably just order things lexicographically. I added this to the TODO list for now. See my suggestion below. So we need for any services shipping Aliases to have a preset list per flavor (if their behaviors differs) with: 99-ubuntu-desktop.preset: enable lightdm.service disable kdm.service disable gdm.service disable nodm.service (and whatnot… dm files in distro) Hmm, indeed I guess... Then, we would have 01-ubuntu-gnome.preset: enable gdm.service disable lightdm.service disable kdm.service … It seems maintaining this list in sync for all flavors would be a growing pain (this is a positive effect of the disable by default: you don't have to maintain such a list), or do you think we can come with something better? Hmm, yuck. No good suggestion. I figure this problem doesn't exist with the fedora default of everything is disabled by default... All open to ideas... Can we maybe extend the preset dictionary by having an alias (or alias-default) keyword taking a pair of arguments, like: alias display-manager.service lightdm.service Then, the preset command, for each alias, will stop at the first one it encounters. If the service doesn't exist, it's a noop, if it's there, it enables (--force in case something else was enabled for that Alias?) lightdm.service. It means of course that lightdm.service should contain: [Install] Alias=display-manager.service or preset would then generates a warning. Finally, on the know what the administrator did on this machine, here are two cases that we can identify: I. if the administrator removes the service package, we usually keep current service state (enabled/disabled) on reinstall. So: foo.service enabled by default 1. systemctl disable foo.service 2. apt-get remove foo 3. apt-get install foo - foo should still be disabled. However, that won't be the case as on reinstall, systemctl preset will re-enable the service as of the preset policy. Indeed, we don't have any record that the admin disabled it compared default distro policy as there is no difference between: no previous installation state and service being disabled state (no symlink). Yeah, not sure how you can provide that with the scheme we devised there in systemd. Sorry! All ears for ideas... So, I think we should really be able to fix case I. I mean, you can fix case I, by explicitly storing the state away before you remove a package. Or storing only the previous *default* state? Then, we can have a trigger updating that previous distro state (combining services installed and default preset) everytime we install/update a package containing a preset file or a an unit file? How does this all precisely work on on ? Most of them shipped a conffile like /etc/default/service_name file with an ENABLED=true/false keyword. This doesn't really map in the systemd world (repetition of enablement/disablement states) * apt-get remove keeps conffiles * apt-get remove --purge deletes them. * When an upgrade occurs: - if the package conffile didn't change - kept with the modifications if any - if the package conffile did change - infamous debconf prompt about a maintainer configuration file changes, do you want to apply maintainer changes/keep as it is/see the diff… That's how all those use cases are handled on sysvinit. Of course, we could introduce that back with ExecStartPre=`grep …` but well, 2 places (systemd symlinks + a /etc/default/ file) to decide one thing isn't really appealing nor
Re: [systemd-devel] [PATCH] 60-persistent-storage.rules: ignore partitions with ID_FS_TYPE of parent
On 05.12.2014 08:20, Andrei Borzenkov wrote: В Thu, 04 Dec 2014 18:24:11 +0100 Harald Hoyer har...@redhat.com пишет: On 04.12.2014 18:19, Andrei Borzenkov wrote: В Thu, 04 Dec 2014 15:14:00 +0100 Harald Hoyer har...@redhat.com пишет: On 04.12.2014 15:10, Zbigniew Jędrzejewski-Szmek wrote: On Thu, Dec 04, 2014 at 12:57:36PM +0100, har...@redhat.com wrote: From: Harald Hoyer har...@redhat.com If ID_FS_TYPE of a parent is already set, then it's something like linux_raid_member or mpath_member and the disk is already in use, so don't handle the partitions Is this trying to fix an existing problem? yes, for mpath_member disk partitions, we should never ever advertise the /dev/disk/by* symlinks or set SYSTEMD_READY for it. How is it going to work? I mean, first we get device, then it is processed by multipathd. At the time rules are processed by udev, we have no idea whether it will be added to mpath later. For the disk, we should/must the flag set immediately in 62-multipath.rules. OK it is 56-multipath.rules here and it is actually sets ID_FS_TYPE to none, but the effect should be the same. I do not see this rule in multipath-tools ... should not it be unified across distros? Yeah, should be ... Upstream does not even ship a rule, which sets ID_FS_TYPE. I don't know why we have 100 patches in Fedora rawhide on top of upstream for the multipath tools. Seems like nobody is pushing patches upstream, or upstream is not accepting any. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] networkd: Support setting mtu / mac address by interface name
On 5 Dec 2014 10:07, Marcel Holtmann mar...@holtmann.org wrote: Hi Lennart, Moreover, if we give people this feature I'm pretty sure we'll get lots of people expecting it to work also for any other sort of name and getting confused when it doesn't. Well, this is something we can fix by documentation, no? Or maybe name the match option differently, maybe OriginalName= or KernelName= or so, and then only matching interfaces where you know that the name was selected by userspace in the first place? I like the idea of OriginalName, much less likely to get people confused. I now implemented that, with the restriction that we cannot match on renamed names. For now I left it open to match on ethX style names, as people in principle could do sensible things like OriginalName=eth* or even OriginalName=eth0 when we know there is only one interface. One thing to consider would be to disallow renaming from a .link file where the OriginalName was used to match. That way we don't have the somewhat odd situation that a .link file can only be applied once (we do not remember the original name, so cannot match on that the second time around, as that would be a mess)... Maybe we should even store the original name in a udev property, so that we can make this fully idempotent simply because we can always check this new property for the original name passed down from the kernel? you do realize that once the kernel renamed the name, it is free to reuse that name again. So eth0 as OriginalName can then be present multiple times. I think that you can only have OriginalName matching if a renaming has never occurred. Otherwise this is really not deterministic. Since foo0 (renamed from eth0) and and bar0 (renamed from eth0) will both match OriginalName=eth0. The difference is only timing and that is inhering racy of course. Well, matching on kernel names is not sane, and I put a warning in the manpage. The reason I left it in was that you could match on eth0 of you know it is the only ethX device on your system, or you could match on eth* which would also be deterministic. Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-nspawn@.service is unusable
2014-12-05 12:41 GMT+03:00 Peter Lemenkov lemen...@gmail.com: 2014-12-05 4:43 GMT+03:00 Lennart Poettering lenn...@poettering.net: On Thu, 04.12.14 20:12, Peter Lemenkov (lemen...@gmail.com) wrote: Hello All! I'm playing with systemd-nspawn@.service and cannot make it work. It seems that similar issues were discussed (and addressed upstream) in Debian bug #770275 ( https://bugs.debian.org/770275 ) however I believe I've hit by something else. What I've done so far: * Ensured that /var/lib/container exists * Created both /var/log/journal/machineid and /var/lib/container/containername/var/log/journal/machineid * Ensured that Storage=persistent is set in /var/lib/container/containername/etc/systemd/journald.conf Every my attempt to run systemctl status systemd-nspawn@containername ended up like this: https://paste.fedoraproject.org/156640/14177088/ Please note that systemd-journald fails so I can't find out what's going on there. I'm stuck right here. Some other services failed as well, and I can't login using machinectl login but that's another story I believe. Any advice on how to debug this and make systemd-nspawn@containername usable are highly appreciate! What happens if you run the same nspawn command from the command line? Does journald then start up correctly in it? Yes, it works perfectly fine if I run it as $ sudo /usr/bin/systemd-nspawn --keep-unit --boot --directory=/var/lib/container/earlyannounce I can login and see logs. Unfortunately no logs from the previous boot are available (due to failed systemd-journald.service). What happens if you add debug to the end of the nspawn cmdline? Do you see anything interesting in the additional log output this generates? Can't say for sure. Here is a diff between two logs (with whitespace ignored) - first one is successful boot, second one is the failed boot (using systemd service): * https://paste.fedoraproject.org/156867/77223114/raw/ And here are actual boot logs: * https://paste.fedoraproject.org/156862/17770249/ (from the service-file) * https://paste.fedoraproject.org/156862/17770249/ (using the command mentioned above) Wrong last link, sorry. Here is a proper one: * https://paste.fedoraproject.org/156894/79578141/ (using the command mentioned above) -- With best regards, Peter Lemenkov. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-nspawn@.service is unusable
2014-12-05 4:43 GMT+03:00 Lennart Poettering lenn...@poettering.net:
On Thu, 04.12.14 20:12, Peter Lemenkov (lemen...@gmail.com) wrote:
Hello All!
I'm playing with systemd-nspawn@.service and cannot make it work. It
seems that similar issues were discussed (and addressed upstream) in
Debian bug #770275 ( https://bugs.debian.org/770275 ) however I
believe I've hit by something else.
What I've done so far:
* Ensured that /var/lib/container exists
* Created both /var/log/journal/machineid and
/var/lib/container/containername/var/log/journal/machineid
* Ensured that Storage=persistent is set in
/var/lib/container/containername/etc/systemd/journald.conf
Every my attempt to run systemctl status
systemd-nspawn@containername ended up like this:
https://paste.fedoraproject.org/156640/14177088/
Please note that systemd-journald fails so I can't find out what's
going on there. I'm stuck right here. Some other services failed as
well, and I can't login using machinectl login but that's another
story I believe.
Any advice on how to debug this and make
systemd-nspawn@containername usable are highly appreciate!
What happens if you run the same nspawn command from the command line?
Does journald then start up correctly in it?
What happens if you add debug to the end of the nspawn cmdline? Do
you see anything interesting in the additional log output this
generates?
If it fails then, too. Can you strace -ff -o ~/nspawnlogs the whole nspawn
process
(and hence also its child processes), then find the strace log this
created for journald, and check what the last bits are that it does.
Ok, now I've got something. Here is a a diff between good (1st,
commandline) and bad (2nd, systemd service) sessions:
* https://gist.github.com/lemenkov/ee70c42baedcb9b43189#file-sessions-diff
More specifically I found these pieces interesting:
*
https://gist.github.com/lemenkov/ee70c42baedcb9b43189#file-sessions-diff-L253-L258
Notice open(/dev/urandom, O_RDONLY|O_NOCTTY|O_CLOEXEC) = -1 EACCES
(Permission denied) when started as systemd service:
*
https://gist.github.com/lemenkov/ee70c42baedcb9b43189#file-sessions-diff-L699-L700
Notice unlink(/run/systemd/journal/dev-log) = -1 EACCES
(Permission denied) followed by bind(7, {sa_family=AF_LOCAL,
sun_path=/run/systemd/journal/dev-log}, 30) = -1 EADDRINUSE (Address
already in use).
Looks like systemd-nspawn either doesn't mounts (bind mounts) a
necessary devices or doesn't create them properly.
--
With best regards, Peter Lemenkov.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] preset enables everything by default
On Thu, 04.12.14 18:58, Michael Marineau (michael.marin...@coreos.com) wrote: We use the machine-id file as check whether /etc is populated or not. If people pre-populate /etc, and don't wan't the full first-boot logic of systemd to take action, then they should also add machine-id file there (they can even just touch it if they want, which will disable the first-boot logic, but still initialize the file either directly if writable or overmounted if not). So when assembling a machine image that will be used to create a bunch of pre-configured hosts the correct thing to do is 'echo machine-id', not 'rm machine-id'? Well, it's up to you: a) install a disable * preset file in your /usr, and use rm /etc/machine-id b) don't install any preset file and use echo /etc/machine-id If you opt for a, then this has the benefit that the first bootup is still special, and ConditionFirstBoot= will still trigger for it, which might be useful for a number of services. If I were you I'd opt for a). This behavior is probably ok in the case of interactively using systemctl preset and preset-all when it is known that the user explicitly asked the system to do something and can see what it did. In the case of the system booting I would expect do nothing to be the default when no preset file explicitly sates otherwise. Then ship a disable * preset file in /sr. In this case, nothing will be enabled by default. THis is what we do on Fedora. And I've added this to CoreOS too. The gist of my rambling email was why is this not the default? Well, for simplicity reasons, outside of the stateless machines business it is kinda useful being able to ignore the entire complexity of presets, enabling, disabling, and just consider the RPM scriptlets as something that truns on what is being installed, end of story. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] user environment variables
Dear all, For the user services started by systemctl --user, I sometimes need to tell systemd some environment variables values. For this purpose, I use drop-in configuration files (MyService.conf) in /etc/systemd/system/user@.service.d I am wondering if there is another way to pass the variables values. I was thinking to some user directory like this : ~/.config/systemd/user@.service.d (does not work) or import one only file with all these variables values with this command at session start up: systemctl --import-environment FILE (does not work), or maybe something like systemctl --import-environment 'cat FILE'. Thank you for any hint. Regards. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] networkd: Support setting mtu / mac address by interface name
On Fri, 05.12.14 10:07, Marcel Holtmann (mar...@holtmann.org) wrote: Hi Lennart, Moreover, if we give people this feature I'm pretty sure we'll get lots of people expecting it to work also for any other sort of name and getting confused when it doesn't. Well, this is something we can fix by documentation, no? Or maybe name the match option differently, maybe OriginalName= or KernelName= or so, and then only matching interfaces where you know that the name was selected by userspace in the first place? I like the idea of OriginalName, much less likely to get people confused. I now implemented that, with the restriction that we cannot match on renamed names. For now I left it open to match on ethX style names, as people in principle could do sensible things like OriginalName=eth* or even OriginalName=eth0 when we know there is only one interface. One thing to consider would be to disallow renaming from a .link file where the OriginalName was used to match. That way we don't have the somewhat odd situation that a .link file can only be applied once (we do not remember the original name, so cannot match on that the second time around, as that would be a mess)... Maybe we should even store the original name in a udev property, so that we can make this fully idempotent simply because we can always check this new property for the original name passed down from the kernel? you do realize that once the kernel renamed the name, it is free to reuse that name again. So eth0 as OriginalName can then be present multiple times. I think that you can only have OriginalName matching if a renaming has never occurred. Otherwise this is really not deterministic. Since foo0 (renamed from eth0) and and bar0 (renamed from eth0) will both match OriginalName=eth0. The difference is only timing and that is inhering racy of course. Well, sure, if you use OriginalName= for such names, it's your own fault. I think using OriginalName= is primarily useful for things like veth links where the names are chosen by userspace anyway. Hmm, now that the naming policy is exposed by the kernel, can we detect the cases where naming happens like eth0, eth1, and print a nice warning or so, if people then match against that? 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-nspawn@.service is unusable
On Fri, 05.12.14 16:58, Peter Lemenkov (lemen...@gmail.com) wrote:
Ok, now I've got something. Here is a a diff between good (1st,
commandline) and bad (2nd, systemd service) sessions:
* https://gist.github.com/lemenkov/ee70c42baedcb9b43189#file-sessions-diff
More specifically I found these pieces interesting:
*
https://gist.github.com/lemenkov/ee70c42baedcb9b43189#file-sessions-diff-L253-L258
Notice open(/dev/urandom, O_RDONLY|O_NOCTTY|O_CLOEXEC) = -1 EACCES
(Permission denied) when started as systemd service:
*
https://gist.github.com/lemenkov/ee70c42baedcb9b43189#file-sessions-diff-L699-L700
Notice unlink(/run/systemd/journal/dev-log) = -1 EACCES
(Permission denied) followed by bind(7, {sa_family=AF_LOCAL,
sun_path=/run/systemd/journal/dev-log}, 30) = -1 EADDRINUSE (Address
already in use).
Looks like systemd-nspawn either doesn't mounts (bind mounts) a
necessary devices or doesn't create them properly.
Hmm, do you have SELinux enabled and in enforcing mode?
nspawn mounts a tmpfs to /run, very early on, before invoking the
first binary, it should definitely be writable.
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] user environment variables
On Fri, 05.12.14 14:13, arnaud gaboury (arnaud.gabo...@gmail.com) wrote: Dear all, For the user services started by systemctl --user, I sometimes need to tell systemd some environment variables values. For this purpose, I use drop-in configuration files (MyService.conf) in /etc/systemd/system/user@.service.d I am wondering if there is another way to pass the variables values. I was thinking to some user directory like this : ~/.config/systemd/user@.service.d (does not work) or import one only file with all these variables values with this command at session start up: systemctl --import-environment FILE (does not work), or maybe something like systemctl --import-environment 'cat FILE'. systemctl set-environment `cat FILE` should work, no? 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-nspawn@.service is unusable
2014-12-05 16:25 GMT+03:00 Lennart Poettering lenn...@poettering.net:
On Fri, 05.12.14 16:58, Peter Lemenkov (lemen...@gmail.com) wrote:
Ok, now I've got something. Here is a a diff between good (1st,
commandline) and bad (2nd, systemd service) sessions:
* https://gist.github.com/lemenkov/ee70c42baedcb9b43189#file-sessions-diff
More specifically I found these pieces interesting:
*
https://gist.github.com/lemenkov/ee70c42baedcb9b43189#file-sessions-diff-L253-L258
Notice open(/dev/urandom, O_RDONLY|O_NOCTTY|O_CLOEXEC) = -1 EACCES
(Permission denied) when started as systemd service:
*
https://gist.github.com/lemenkov/ee70c42baedcb9b43189#file-sessions-diff-L699-L700
Notice unlink(/run/systemd/journal/dev-log) = -1 EACCES
(Permission denied) followed by bind(7, {sa_family=AF_LOCAL,
sun_path=/run/systemd/journal/dev-log}, 30) = -1 EADDRINUSE (Address
already in use).
Looks like systemd-nspawn either doesn't mounts (bind mounts) a
necessary devices or doesn't create them properly.
Hmm, do you have SELinux enabled and in enforcing mode?
nspawn mounts a tmpfs to /run, very early on, before invoking the
first binary, it should definitely be writable.
Yes! That's a SELinux denial. I'm sorry for bothering you and for not
trying switching selinux off and on again - I actually thought that
all the SELinux issues are gone already.
In case you're interested - here is a dump of dmesg | audit2allow:
#= getty_t ==
allow getty_t devpts_t:chr_file { write getattr setattr read open ioctl };
allow getty_t rpm_var_lib_t:file open;
allow getty_t tmpfs_t:chr_file read;
#= syslogd_t ==
allow syslogd_t tmpfs_t:chr_file { read write ioctl open };
allow syslogd_t tmpfs_t:dir { write create add_name };
allow syslogd_t tmpfs_t:file { create setattr };
allow syslogd_t tmpfs_t:sock_file write;
#= systemd_logind_t ==
allow systemd_logind_t tmpfs_t:filesystem mount;
allow systemd_logind_t tmpfs_t:sock_file write;
allow systemd_logind_t user_tmp_t:dir mounton;
#= systemd_sysctl_t ==
# This avc can be allowed using the boolean 'domain_kernel_load_modules'
allow systemd_sysctl_t kernel_t:system module_request;
#==
And here is a full explanation:
https://paste.fedoraproject.org/156932/78730514/
I'll try to open a bug reports in RHBZ on each issue found.
--
With best regards, Peter Lemenkov.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] /usr vs /etc for default distro units enablement
On Fri, 05.12.14 11:06, Didier Roche (didro...@ubuntu.com) wrote: It seems maintaining this list in sync for all flavors would be a growing pain (this is a positive effect of the disable by default: you don't have to maintain such a list), or do you think we can come with something better? Hmm, yuck. No good suggestion. I figure this problem doesn't exist with the fedora default of everything is disabled by default... All open to ideas... Can we maybe extend the preset dictionary by having an alias (or alias-default) keyword taking a pair of arguments, like: alias display-manager.service lightdm.service Then, the preset command, for each alias, will stop at the first one it encounters. If the service doesn't exist, it's a noop, if it's there, it enables (--force in case something else was enabled for that Alias?) lightdm.service. It means of course that lightdm.service should contain: [Install] Alias=display-manager.service or preset would then generates a warning. So far this is not how presets work: they are just a database you pass in as key a service name, and it tells you whether to enable it or not, in a simple boolean way. It is something where you pass in the name of a unit you want to enable/disable, and after you got that, you do that, but you do not verify again the individual steps enabling/disabling precisely entail. It also is currently entirely stateless: you could in theory ask a web server for such a preset question, and it will always tell you the same answer, because it does *not* take your local configuration and set of packages into consideration... This kind of disconnected logic I'd really like to keep. Hmm, what about this proposal: Whenever the preset db is queried we'll no longer just return the verdict boolean, but also a numeric overall line number, of the line we found the verdict on. Then, when preset-all is invoked, we determine all the operations to execute for everything. Then, before applying them, we check if there are any conflicting operations. If so, we remove the ones with the higher line number. In effect this would mean: if you list to DMs as enable in the preset file, and both are to be installed, then the one that is enabled earlier will win in case of preset-all. To me this appears quite a natural extension of the logic already in place. How does this all precisely work on on ? Most of them shipped a conffile like /etc/default/service_name file with an ENABLED=true/false keyword. This doesn't really map in the systemd world (repetition of enablement/disablement states) * apt-get remove keeps conffiles * apt-get remove --purge deletes them. * When an upgrade occurs: - if the package conffile didn't change - kept with the modifications if any - if the package conffile did change - infamous debconf prompt about a maintainer configuration file changes, do you want to apply maintainer changes/keep as it is/see the diff… That's how all those use cases are handled on sysvinit. Of course, we could introduce that back with ExecStartPre=`grep …` but well, 2 places (systemd symlinks + a /etc/default/ file) to decide one thing isn't really appealing nor wanted :) To be honest I find the entire stuff with ENABLED=true/false really questionnable, I think it would be agreat step ahead to get rid of it. (But then again, I cannot make Debian's decisions there...) Only preinst can (getting the install or upgrade argument), not postinst (getting configure in both case). And we need to run the preset/enable in postinst (meaning: after unpacking). This sounds quite a limitation. Maybe you can keep a couple of touch files in /var/lib/ somewhere where you store whether you already applied systemctl preset before? 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] /usr vs /etc for default distro units enablement
Lennart Poettering wrote on 05/12/14 13:52: Only preinst can (getting the install or upgrade argument), not postinst (getting configure in both case). And we need to run the preset/enable in postinst (meaning: after unpacking). This sounds quite a limitation. Maybe you can keep a couple of touch files in /var/lib/ somewhere where you store whether you already applied systemctl preset before? For what it's worth, this is the technique I used when migrating sysvinit - native units. For a while, we had both sysvinit script and systemd units shipped in the same package (to allow a choice of init system - but we dropped support for sysvinit ages ago - in fact the last distro version that supported this went EOL the other day!). When the systemd unit was first introduced in the package (assuming the user was upgrading) we would migrate the enablement state of the sysvinit script to the systemd unit - if sysvinit was enabled, then so should the systemd unit; if it was disabled then so should the systemd unit. We only did this the first time the systemd unit showed up in the package and touched a file in /var/lib to track this. After this initial transition, their enablement state (whether it be sysvinit or native) was in the hands of the admin. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v2 5/5] mount: auto-detect iSCSI and FCoE as requiring network
On Fri, Dec 05, 2014 at 01:46:06AM +0100, Lennart Poettering wrote: With such an API you have the liberty to change later on what precisely you expose there. The fact that you watch a file would be entirely opaque, it could one day be a pipe or socket, or even an fd on some kernel fd, where you just tell us the kind of events you want the user code to listen on. This is how we wrap a lot of our own APIs, to allow integration into arbitrary main loops, without restricting us to decide how precisely the event is generated. Does this make sense? Yep. Would love to get an API in place for this in libmount, because I don't really want to release systemd with the current code. Implemented. I have added struct libmnt_monitor to make this new interface easy to extend and usable for more resources (I'll probably also add mountinfo fd for findmnt(8), but this is irrelevant for systemd;-) All you need is: mn = mnt_new_monitor(); fd = mnt_monitor_userspace_get_fd(mn, NULL);/* utab monitor fd */ mnt_monitor_get_events(mn, fd, ev.events); /* EPOLLIN ... */ efd = epoll_create1(EPOLL_CLOEXEC); epoll_ctl(efd, EPOLL_CTL_ADD, fd, ev); n = epoll_wait(efd, events, 1, -1); id (n == 1 mnt_monitor_is_changed(mn, fd) == 1) printf(%s: change detected\n, mnt_monitor_get_filename(mn, fd)); mnt_unref_monitor(mn); close(efd); I guess it's enough to add the 'fd' to systmed sd_event_add_io() and call mnt_table_parse_mtab() when a change is detected. (As already implemeted in the original Chris' patch.) usable example: https://github.com/karelzak/util-linux/blob/master/libmount/src/monitor.c#L345 Karel -- Karel Zak k...@redhat.com http://karelzak.blogspot.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] /usr vs /etc for default distro units enablement
Le 05/12/2014 14:52, Lennart Poettering a écrit : On Fri, 05.12.14 11:06, Didier Roche (didro...@ubuntu.com) wrote: It seems maintaining this list in sync for all flavors would be a growing pain (this is a positive effect of the disable by default: you don't have to maintain such a list), or do you think we can come with something better? Hmm, yuck. No good suggestion. I figure this problem doesn't exist with the fedora default of everything is disabled by default... All open to ideas... Can we maybe extend the preset dictionary by having an alias (or alias-default) keyword taking a pair of arguments, like: alias display-manager.service lightdm.service Then, the preset command, for each alias, will stop at the first one it encounters. If the service doesn't exist, it's a noop, if it's there, it enables (--force in case something else was enabled for that Alias?) lightdm.service. It means of course that lightdm.service should contain: [Install] Alias=display-manager.service or preset would then generates a warning. So far this is not how presets work: they are just a database you pass in as key a service name, and it tells you whether to enable it or not, in a simple boolean way. It is something where you pass in the name of a unit you want to enable/disable, and after you got that, you do that, but you do not verify again the individual steps enabling/disabling precisely entail. It also is currently entirely stateless: you could in theory ask a web server for such a preset question, and it will always tell you the same answer, because it does *not* take your local configuration and set of packages into consideration... This kind of disconnected logic I'd really like to keep. Hmm, what about this proposal: Whenever the preset db is queried we'll no longer just return the verdict boolean, but also a numeric overall line number, of the line we found the verdict on. Then, when preset-all is invoked, we determine all the operations to execute for everything. Then, before applying them, we check if there are any conflicting operations. If so, we remove the ones with the higher line number. In effect this would mean: if you list to DMs as enable in the preset file, and both are to be installed, then the one that is enabled earlier will win in case of preset-all. To me this appears quite a natural extension of the logic already in place. And I guess the default behavior (enable *) has a lower priority than overrides? (enable/disable). Also, I guess you concatenate all preset files as if it was a single one (ascii ordered?) to build that list. So, retaking the display-manager (on the principle they all have: Alias=display-manager.service) example, that would mean: * ubuntu-desktop would ship 99-defaults with: enable lightdm * If someone, install the gnome-ubuntu-desktop metapackage on the same install, they would get an additional preset file 50-gnome-ubuntu with: enable gdm And so, lightdm would be removed on a preset-all call as conflicting with gdm (due to sharing the same Alias) and having higher line number. Sounds like a nice way to handle Alias. Happy to have a look at this. How does this all precisely work on on ? Most of them shipped a conffile like /etc/default/service_name file with an ENABLED=true/false keyword. This doesn't really map in the systemd world (repetition of enablement/disablement states) * apt-get remove keeps conffiles * apt-get remove --purge deletes them. * When an upgrade occurs: - if the package conffile didn't change - kept with the modifications if any - if the package conffile did change - infamous debconf prompt about a maintainer configuration file changes, do you want to apply maintainer changes/keep as it is/see the diff… That's how all those use cases are handled on sysvinit. Of course, we could introduce that back with ExecStartPre=`grep …` but well, 2 places (systemd symlinks + a /etc/default/ file) to decide one thing isn't really appealing nor wanted :) To be honest I find the entire stuff with ENABLED=true/false really questionnable, I think it would be agreat step ahead to get rid of it. (But then again, I cannot make Debian's decisions there...) Agreed, I already removed it from some ubuntu-only packages like whoopsie, xdiagnose… and I'm trying to investigate the right way to get a systemd-oriented solutions (while still being compatible with older init system for debian) Only preinst can (getting the install or upgrade argument), not postinst (getting configure in both case). And we need to run the preset/enable in postinst (meaning: after unpacking). This sounds quite a limitation. Maybe you can keep a couple of touch files in /var/lib/ somewhere where you store whether you already applied systemctl preset before? This is possible, but really not encouraged (due to some possibility to have unpacking or other intermediate states failing). This would also only fix the newly installed case, not the upgrade with new
Re: [systemd-devel] user environment variables
systemctl set-environment `cat FILE` should work, no? Lennart I am messing with it. $ systemctl --user set-environment toto=3 tata=4 $ systemctl --user show-environment .. tata=4 toto=3 - Now: -- $ echo 'lolo=4 lala=5' | tee test lolo=4 lala=5 $ systemctl --user set-environment 'cat test' Failed to set environment: Invalid environment assignments --- No idea what I do wrong. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] journal: Fix navigating backwards missing entries
With DIRECTION_UP (i.e. navigating backwards) in generic_array_bisect() when the
needle was found as the last item in the array, it wasn't actually processed as
match, resulting in entries being missed.
https://bugs.freedesktop.org/show_bug.cgi?id=86855
---
This was a good excuse for me to dive in and learn about journal's internals,
but someone with actual knowledge of said internals should review this, in case
I missed something.
src/journal/journal-file.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/journal/journal-file.c b/src/journal/journal-file.c
index 7858435..c5d2d19 100644
--- a/src/journal/journal-file.c
+++ b/src/journal/journal-file.c
@@ -1657,7 +1657,7 @@ static int generic_array_bisect(
}
}
-if (k n) {
+if (k = n) {
if (direction == DIRECTION_UP) {
i = n;
subtract_one = true;
--
2.1.3
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] networkd: Support setting mtu / mac address by interface name
On Fri, Dec 5, 2014 at 2:21 PM, Lennart Poettering lenn...@poettering.net wrote: On Fri, 05.12.14 10:07, Marcel Holtmann (mar...@holtmann.org) wrote: Hi Lennart, Moreover, if we give people this feature I'm pretty sure we'll get lots of people expecting it to work also for any other sort of name and getting confused when it doesn't. Well, this is something we can fix by documentation, no? Or maybe name the match option differently, maybe OriginalName= or KernelName= or so, and then only matching interfaces where you know that the name was selected by userspace in the first place? I like the idea of OriginalName, much less likely to get people confused. I now implemented that, with the restriction that we cannot match on renamed names. For now I left it open to match on ethX style names, as people in principle could do sensible things like OriginalName=eth* or even OriginalName=eth0 when we know there is only one interface. One thing to consider would be to disallow renaming from a .link file where the OriginalName was used to match. That way we don't have the somewhat odd situation that a .link file can only be applied once (we do not remember the original name, so cannot match on that the second time around, as that would be a mess)... Maybe we should even store the original name in a udev property, so that we can make this fully idempotent simply because we can always check this new property for the original name passed down from the kernel? you do realize that once the kernel renamed the name, it is free to reuse that name again. So eth0 as OriginalName can then be present multiple times. I think that you can only have OriginalName matching if a renaming has never occurred. Otherwise this is really not deterministic. Since foo0 (renamed from eth0) and and bar0 (renamed from eth0) will both match OriginalName=eth0. The difference is only timing and that is inhering racy of course. Well, sure, if you use OriginalName= for such names, it's your own fault. I think using OriginalName= is primarily useful for things like veth links where the names are chosen by userspace anyway. Hmm, now that the naming policy is exposed by the kernel, can we detect the cases where naming happens like eth0, eth1, and print a nice warning or so, if people then match against that? I added some warnings to git now. Still need to push some more kernel patches to get more stuff tagged correctly, but at least the systemd side is now good. Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] 60-persistent-storage.rules: ignore partitions with ID_FS_TYPE of parent
On Fri, Dec 05, 2014 at 11:07:35AM +0100, Harald Hoyer wrote: On 05.12.2014 08:20, Andrei Borzenkov wrote: В Thu, 04 Dec 2014 18:24:11 +0100 Harald Hoyer har...@redhat.com пишет: On 04.12.2014 18:19, Andrei Borzenkov wrote: В Thu, 04 Dec 2014 15:14:00 +0100 Harald Hoyer har...@redhat.com пишет: On 04.12.2014 15:10, Zbigniew Jędrzejewski-Szmek wrote: On Thu, Dec 04, 2014 at 12:57:36PM +0100, har...@redhat.com wrote: From: Harald Hoyer har...@redhat.com If ID_FS_TYPE of a parent is already set, then it's something like linux_raid_member or mpath_member and the disk is already in use, so don't handle the partitions Is this trying to fix an existing problem? yes, for mpath_member disk partitions, we should never ever advertise the /dev/disk/by* symlinks or set SYSTEMD_READY for it. How is it going to work? I mean, first we get device, then it is processed by multipathd. At the time rules are processed by udev, we have no idea whether it will be added to mpath later. For the disk, we should/must the flag set immediately in 62-multipath.rules. OK it is 56-multipath.rules here and it is actually sets ID_FS_TYPE to none, but the effect should be the same. I do not see this rule in multipath-tools ... should not it be unified across distros? Yeah, should be ... Upstream does not even ship a rule, which sets ID_FS_TYPE. I don't know why we have 100 patches in Fedora rawhide on top of upstream for the multipath tools. Seems like nobody is pushing patches upstream, or upstream is not accepting any. Since multipath upstream doesn't have a stable branch. The safest thing to do is to pick a point and pull then, and just apply known stable patches on top of it, instead of trying to keep in sync with upstream, and repeatedly pulling down patches that break things. But, yes, upstream currently doesn't appear to be taking patches. Christophe hasn't responded to any of my emails recently, and and the last patch of mine he's accepted (or even commented on) was IIRC in September. I assume this is just temporary, and was planning to wait until January to see if he came back. -Ben ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] user environment variables
On 05/12/14 16:13, arnaud gaboury wrote: Now: -- $ echo 'lolo=4 lala=5' | tee test lolo=4 lala=5 $ systemctl --user set-environment 'cat test' Failed to set environment: Invalid environment assignments --- No idea what I do wrong. This is invalid shell syntax. This should work: $ systemctl --user set-environment `cat test` or, if you are using bash, I find this more readable: $ systemctl --user set-environment $(cat test) Cheers, Daniele ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] user environment variables
$ systemctl --user set-environment `cat test` Damned. Thank you ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] user environment variables
On Fri, Dec 5, 2014 at 5:20 PM, Daniele Nicolodi dani...@grinta.net wrote: On 05/12/14 16:13, arnaud gaboury wrote: Now: -- $ echo 'lolo=4 lala=5' | tee test lolo=4 lala=5 $ systemctl --user set-environment 'cat test' Failed to set environment: Invalid environment assignments --- No idea what I do wrong. This is invalid shell syntax. This should work: $ systemctl --user set-environment `cat test` or, if you are using bash, I find this more readable: $ systemctl --user set-environment $(cat test) As the variables sometimes have spaces, this might be more reliable: xargs systemctl --user set-environment test (With -d '\n' or without, depending on chosen syntax.) It's possible to emulate import-environment using: xargs -d '\0' systemctl --user set-environment /proc/self/environ -- Mantas Mikulėnas graw...@gmail.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] /usr vs /etc for default distro units enablement
On Fri, 05.12.14 16:02, Didier Roche (didro...@ubuntu.com) wrote: Whenever the preset db is queried we'll no longer just return the verdict boolean, but also a numeric overall line number, of the line we found the verdict on. Then, when preset-all is invoked, we determine all the operations to execute for everything. Then, before applying them, we check if there are any conflicting operations. If so, we remove the ones with the higher line number. In effect this would mean: if you list to DMs as enable in the preset file, and both are to be installed, then the one that is enabled earlier will win in case of preset-all. To me this appears quite a natural extension of the logic already in place. And I guess the default behavior (enable *) has a lower priority than overrides? (enable/disable). Also, I guess you concatenate all preset files as if it was a single one (ascii ordered?) to build that list. Yeah, the default policy of enable * would have the largest possible line number, so that any other line number wins. So, retaking the display-manager (on the principle they all have: Alias=display-manager.service) example, that would mean: * ubuntu-desktop would ship 99-defaults with: enable lightdm * If someone, install the gnome-ubuntu-desktop metapackage on the same install, they would get an additional preset file 50-gnome-ubuntu with: enable gdm And so, lightdm would be removed on a preset-all call as conflicting with gdm (due to sharing the same Alias) and having higher line number. correct. Sounds like a nice way to handle Alias. Happy to have a look at this. Would love to take a patch for this. Only preinst can (getting the install or upgrade argument), not postinst (getting configure in both case). And we need to run the preset/enable in postinst (meaning: after unpacking). This sounds quite a limitation. Maybe you can keep a couple of touch files in /var/lib/ somewhere where you store whether you already applied systemctl preset before? This is possible, but really not encouraged (due to some possibility to have unpacking or other intermediate states failing). This would also only fix the newly installed case, not the upgrade with new distro defaults or various purge vs remove ones. That's why I think some kind of previous state db can help getting all those requirements met as you propose, and doing some comparisons between states (only when they deviated from defaults). Then, we can run preset on packages that matches previous defaults (meaning: where the admin didn't override the default choice) as a dpkg trigger (when new units are installed/upgraded and on a new/updated preset file shipped). Would that makes sense? Not sure I grok what you are proposing. I'd be very careful with keeping yet another layer of service enablement states (even if just as history) in systemd upstream. 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] /usr vs /etc for default distro units enablement
On Fri, 2014-12-05 at 02:39 +0100, Lennart Poettering wrote: On Tue, 02.12.14 20:02, Uoti Urpala (uoti.urp...@pp1.inet.fi) wrote: On Tue, 2014-12-02 at 01:51 +0100, Lennart Poettering wrote: On Tue, 18.11.14 16:09, Michael Biebl (mbi...@gmail.com) wrote: WantedBy=multi-user.target and version B has [Install] WantedBy=foo.target Package installs should probably not try to do something about this case, just leave things as is. I think this would be a very bad idea. Installing a system and then upgrading it should give you the same state as installing a newer system directly; silently leaving outdated configuration in use almost ensures that systems will fail/degrade over time. Well, things are not that easy. If distro Foobarix decides one day that from this day on sendmail should be enabled again by default, what is the right upgrade path for old installs? Should it be enabled now, because that's the new default for new installs? Or should it stay disabled, since that's what the user is accustomed to? The context here was a package changing its install target, not changing default enable/disable behavior as in your example. The latter is a less clear-cut case: if the unit has a [Install] section, then presumably the packager considers both enabled and disabled state supported at least to some degree, and thus both are explicitly valid choices even on newly installed systems. By contrast, leaving symlinks from targets that do not match the [Install] section of the current service file anymore is more arbitrary reconfiguration, which cannot be expected to work in general (as in linking arbitrary units from arbitrary targets is not expected to work), and it's the admin's responsibility to investigate what he needs to do to make such configurations work and keep them working. Keeping such obsolete configuration would mean that systems rot over time. Package configuration files are not handled that way, and package startup configuration shouldn't be either, for the same reasons. Just leaving the symlinks would not give good behavior even in the case where the admin wants to keep the old target: temporary disable + then re-enable would now change the target. Perhaps the recommended way to change targets in local configuration should be to override the [Install] section, instead of just leaving different symlinks? units towards statically enabled ones anyway. But again: if something was optional before, and is optional after, then be conservative, don't change things... IMO in the changing-targets case it's not conservative at all to silently leave the system in a state where it has obsolete configuration which does not match anything supported by the current packaging. Such behavior is almost 100% guaranteed to break things at some point. Conservative would be something like refusing to upgrade until the admin resolves possible conflicts manually. If no local configuration can be detected, using the new packaging defaults has a better chance of avoiding breakage than leaving obsolete configuration. Sure, if you know that changes in your unit files actively break a previous default, then you should do something about it, but I think cases like this are best handled with careful, manually written postinst scripts, that do the right thing in the most defensive possible way. But blindly enabling all kinds of stuff just because the upstream default changed is really not a good idea I think. The new defaults could enable more things, or they could disable parts that are now deemed insecure or unnecessary, or just generally fix bugs. The sane default assumption is that later package versions are better than earlier ones, and leaving the system using old default configuration is worse than new configuration. And that's assuming the old configuration even works anymore given changes elsewhere. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] 60-persistent-storage.rules: ignore partitions with ID_FS_TYPE of parent
On Fri, Dec 05, 2014 at 11:07:35AM +0100, Harald Hoyer wrote:
On 05.12.2014 08:20, Andrei Borzenkov wrote:
В Thu, 04 Dec 2014 18:24:11 +0100
Harald Hoyer har...@redhat.com пишет:
On 04.12.2014 18:19, Andrei Borzenkov wrote:
В Thu, 04 Dec 2014 15:14:00 +0100
Harald Hoyer har...@redhat.com пишет:
On 04.12.2014 15:10, Zbigniew Jędrzejewski-Szmek wrote:
On Thu, Dec 04, 2014 at 12:57:36PM +0100, har...@redhat.com wrote:
From: Harald Hoyer har...@redhat.com
If ID_FS_TYPE of a parent is already set,
then it's something like linux_raid_member or mpath_member
and the disk is already in use, so don't handle the partitions
Is this trying to fix an existing problem?
yes, for mpath_member disk partitions, we should never ever advertise
the
/dev/disk/by* symlinks or set SYSTEMD_READY for it.
How is it going to work? I mean, first we get device, then it is
processed by multipathd. At the time rules are processed by udev, we
have no idea whether it will be added to mpath later.
For the disk, we should/must the flag set immediately in
62-multipath.rules.
OK it is 56-multipath.rules here and it is actually sets ID_FS_TYPE to
none, but the effect should be the same. I do not see this rule in
multipath-tools ... should not it be unified across distros?
Yeah, should be ...
The redhat multipath rules assume that you are using find_multipaths.
This isn't upstream yet. Hannes has rejected the patch twice, for
reasons I don't really understand. He recently requested that I push it
again, and I have in my last batch of patches. But Christophe hasn't
pulled them, or any of my recent patches. But that isn't a big deal.
It just involes changing multipath -c to multipath -i -c to ignore
the wwids file and just use the blacklist, when claiming a block device.
The bigger reason I've held off from pushing the rules is that, in order
to keep from doing all the 'multipath -c' work on every change event
(which could cause problems for udev if there were a large number of
events coming in at the same time) I added a timestamp that lets
multipathd know if /etc/multipath.conf or /etc/multipath/wwids has
changed. However theres no way to compare db values in udev rules.
for instance
ENV{TEST_A}=$env{TEST_B} lets you assign the value of TEST_B to TEST_A
and
ENV{TEST_A}==foo lets you compare the value of TEST_A to foo
however
ENV{TEST_A}==$env{TEST_B} doesn't work. You can't compare
the value of TEST_B to the value of TEST_A
So multipath has to hackily work around this in the udev rules. I filed
a bug for this,
https://bugzilla.redhat.com/show_bug.cgi?id=1007650
and I don't want to push in hacky code without at least an answer why
this can't be solved in udev.
-Ben
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] How to use libudev to monitor for /sys/firmware/iscsi_boot*?
Hi: I am trying to figure out how to use libudev to monitor for new iSCSI boot targets. For Emulex CNA cards, a new directory gets created of the form /sys/firmware/iscsi_bootN. I am new to libudev, but it looks like it's set up to monitor for new devices. Can I use it to monitor for non-device events? There must be some better way than polling. Thanks. -- Lee Duncan ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to use libudev to monitor for /sys/firmware/iscsi_boot*?
On Fri, Dec 05, 2014 at 11:51:16AM -0800, Lee Duncan wrote: Hi: I am trying to figure out how to use libudev to monitor for new iSCSI boot targets. For Emulex CNA cards, a new directory gets created of the form /sys/firmware/iscsi_bootN. Really? That's horrid, what kernel driver is doing that? I am new to libudev, but it looks like it's set up to monitor for new devices. Can I use it to monitor for non-device events? There must be some better way than polling. Yes, go kick some kernel developers to do this properly, which does not mean using raw kobjects. If you want, I will be glad to do that, just point me at them... thanks, greg k-h ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to use libudev to monitor for /sys/firmware/iscsi_boot*?
On 12/05/2014 01:14 PM, Greg KH wrote: On Fri, Dec 05, 2014 at 11:51:16AM -0800, Lee Duncan wrote: Hi: I am trying to figure out how to use libudev to monitor for new iSCSI boot targets. For Emulex CNA cards, a new directory gets created of the form /sys/firmware/iscsi_bootN. Really? That's horrid, what kernel driver is doing that? Why is it horrid? drivers/scsi/iscsi_boot_sysfs.c does that, and it looks like it's been doing it for quite a while. The code in open-iscsi that looks for firmware iSCSI boot targets knows to look in both /sys/firmware/iscsi_boot%d, and in /sys/firmware/ibft. iBFT is actually the standard, but many iSCSI CNA cards don't follow the standard. I am new to libudev, but it looks like it's set up to monitor for new devices. Can I use it to monitor for non-device events? There must be some better way than polling. Yes, go kick some kernel developers to do this properly, which does not mean using raw kobjects. If you want, I will be glad to do that, just point me at them... Feel free to kick away, though I'm still not sure why (or who). The '/sys/firmware' subsystem seems like a good place to me for iSCSI CNA cards to place their firmware target information. But I obviously have much to learn about it. And, for the record, I believe you are saying that my interpretation of libudev was right: it's not the tool to detect new iSCSI boot target presence, at least using the current /sys/firmware/iscsi_boot%d architecture. Correct? thanks, greg k-h . -- Lee Duncan ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to use libudev to monitor for /sys/firmware/iscsi_boot*?
On Fri, Dec 05, 2014 at 01:42:29PM -0800, Lee Duncan wrote: On 12/05/2014 01:14 PM, Greg KH wrote: On Fri, Dec 05, 2014 at 11:51:16AM -0800, Lee Duncan wrote: Hi: I am trying to figure out how to use libudev to monitor for new iSCSI boot targets. For Emulex CNA cards, a new directory gets created of the form /sys/firmware/iscsi_bootN. Really? That's horrid, what kernel driver is doing that? Why is it horrid? drivers/scsi/iscsi_boot_sysfs.c does that, and it looks like it's been doing it for quite a while. The code in open-iscsi that looks for firmware iSCSI boot targets knows to look in both /sys/firmware/iscsi_boot%d, and in /sys/firmware/ibft. iBFT is actually the standard, but many iSCSI CNA cards don't follow the standard. Why is this a firmware thing at all? These are devices, and attributes for different devices, how are they related to firmware like ACPI and PnP? I am new to libudev, but it looks like it's set up to monitor for new devices. Can I use it to monitor for non-device events? There must be some better way than polling. Yes, go kick some kernel developers to do this properly, which does not mean using raw kobjects. If you want, I will be glad to do that, just point me at them... Feel free to kick away, though I'm still not sure why (or who). The '/sys/firmware' subsystem seems like a good place to me for iSCSI CNA cards to place their firmware target information. But I obviously have much to learn about it. And, for the record, I believe you are saying that my interpretation of libudev was right: it's not the tool to detect new iSCSI boot target presence, at least using the current /sys/firmware/iscsi_boot%d architecture. Correct? That is correct, and that is why it's not a good idea for the kernel to be placing code in such a location where no tool will ever be able to see it. It is making your life harder than it has to be, but now that it is in that location, the odds of being able to move it out is slim. greg k-h ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] /usr vs /etc for default distro units enablement
On Fri, 05.12.14 10:58, Andrei Borzenkov (arvidj...@gmail.com) wrote: That's not how I actually understood it. enable/disable still applies only to units with [Install] section as it is now. Just that systemctl disable means that if there are links in /usr/lib, they are masked in /etc. I.o. unit foo.service is enabled if 1. [Install] section exists 2. Links from [Install] section are present either in /usr/lib or in /etc unit foo.service is disabled if 1. [Install] section exists 2. There are no links from [Install] in /usr/lib or /etc *OR* there are links in /usr/lib which are masked in /etc. Units without [Install] section remains static as they are today. This will allow to cleanly separate distribution default (/usr/lib) and admin decision (/etc). Also this will allow systemctl list-unit-files to supply information like enabled (default)/enabled (admin) depending on whether link in /usr/lib or /etc exists. IOW - /usr/lib keeps default state and /etc keeps overrides for default state. Hmm, I figure I could live with such a scheme. Not enthusiastic about the idea, but I see the value, hence I'd merge a good patch for it. Masking dependency symlinks is certainly OK, the part I am not overly enthusiastic about is the changes to systemctl enable and systemctl disable you propose. But given that behaviour of these commands wouldn't change unless you actually have symlinks in /usr + [Install] in the unit file, which doesn't really happen so far, I am fine with it. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd-nspawn old guests
I have been having trouble running nspawn containers that don't have systemd (centos 6, Ubuntu 14.04, debian wheezy etc), I imagine I am just not finding the solution online. The container seems to start without issue but never presents a login prompt. I added audit=0 to the kernel arguments as the manpage suggested but to no avail. I am using systemd 217 on Arch Linux. Any suggestions as to where I should look to solve this? Thomas S. Hatch | Founder, CTO 3400 N. Ashton Blvd, Suite 110 | Lehi, UT 84043 tha...@saltstack.com | www.saltstack.com http://saltstack.com/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
