Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
Am 22.09.2014 um 01:48 schrieb Jóhann B. Guðmundsson: > The reason for increased log entries in the journal is that more things > are happening now since this is what happening when a job is run. that don't change the fact that a user not acting as systemd-developer and not debugging his system don't need that flood you need to distinct between users and developers users want to have *abnormal* things logged and not burried inside noise > Those that have cron job that send email that notifies every time that it ran > ( to know it ran ) and those that do > not send an email unless the job it was running failed and rely on logwatch > to inform them if the cron job ran or not. >> >>> If you dont like it filter it and retrieve only the information you >>> want/need with journalctl >> if they would have a prefix i would filter them to nowhere in rsyslog >> >> please understand that not everybody is using journalctl > > Well this is upstream that ships nothing but journalctl whether they use it > or not then add at least *prefixes* to write filter rules what you say is "we don't ship nothing but" and "we don't care about nothing but" that is the reason for the polarity "we are upstream and don't care" just give "journald.conf" a verbosity option and all are happy honestly the messages about "reaching target" are nonsense without a prefix pointing out that it is about a *user session* because it looks like a bootlog every minute Mar 4 13:01:01 rawhide systemd[1559]: Starting Paths. Mar 4 13:01:01 rawhide systemd[1559]: Reached target Paths. Mar 4 13:01:01 rawhide systemd[1559]: Starting Timers. Mar 4 13:01:01 rawhide systemd[1559]: Reached target Timers. Mar 4 13:01:01 rawhide systemd[1559]: Starting Sockets. Mar 4 13:01:01 rawhide systemd[1559]: Reached target Sockets. Mar 4 13:01:01 rawhide systemd[1559]: Starting Basic System. Mar 4 13:01:01 rawhide systemd[1559]: Reached target Basic System. Mar 4 13:01:01 rawhide systemd[1559]: Starting Default. Mar 4 13:01:01 rawhide systemd[1559]: Reached target Default. Mar 4 13:01:01 rawhide systemd[1559]: Startup finished in 9ms. signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Incorrect logic when /etc/machine-id is missing
Hello,
I believe that the following code is not correct:
src/core/machine-id-setup.c:188-190:
mkdir_parents(etc_machine_id, 0755);
fd = open(etc_machine_id, O_RDWR|O_CREAT|O_CLOEXEC|O_NOCTTY, 0444);
if (fd >= 0)
writable = true;
else {
fd = open(etc_machine_id, O_RDONLY|O_CLOEXEC|O_NOCTTY);
if (fd < 0) {
log_error("Cannot open %s: %m", etc_machine_id);
return -errno;
}
writable = false;
}
src/core/machine-id-setup.c:218-249:
r = generate(id, root);
if (r < 0)
return r;
if (S_ISREG(st.st_mode) && writable) {
lseek(fd, 0, SEEK_SET);
if (loop_write(fd, id, 33, false) == 33)
return 0;
}
fd = safe_close(fd);
/* Hmm, we couldn't write it? So let's write it to
* /run/machine-id as a replacement */
RUN_WITH_UMASK(0022) {
r = write_string_file(run_machine_id, id);
}
if (r < 0) {
log_error("Cannot write %s: %s", run_machine_id, strerror(-r));
unlink(run_machine_id);
return r;
}
/* And now, let's mount it over */
r = mount(run_machine_id, etc_machine_id, NULL, MS_BIND, NULL);
if (r < 0) {
log_error("Failed to mount %s: %m", etc_machine_id);
unlink_noerrno(run_machine_id);
return -errno;
}
If /etc/machine-id is missing on the system, the first open() call
should probably handle that case. That's actually not true (at least on
my system), because the underlying filesystem is read-only at that
time. The second open() call fails as well, because there's no
/etc/machine-id, resulting in a boot failure.
I tried briding the code so that if the second open() fails, it jumps to
the line 218. It then correctly generates the id in /run/machine-id,
however the mount() call fails, because it's not possible to bind
mount a file to nowhere, i.e. the destination always has to exist. The
boot fails as well.
Now I was determined to fix this bug, however I'm left clueless as to
how this is actually supposed to work. Is the entire logic in this piece
of code wrong, or am I missing something? How is the
(re)generating/mounting of machine-id supposed to work?
Cheers,
--
Jan Synacek
Software Engineer, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] udevd: SAS: use SAS addr + PHY id in by-path whenever possible.
This patch changes the naming scheme for sas disks. The original names used
disk's sas address and lun, the new scheme uses sas address of the
nearest expander (if available) and a phy id of the used connection.
If no expander is used, the phy id of hba phy is used.
Note that names that refer to RAID or other abstract devices are
unchanged.
Name in raid configuration:
hba_pci_address-sas-raid_sas_address-lunY-partZ
Name in expander bare disk configuration:
hba_pci_address-sas-expander_sas_address-phyX-lunY-partZ
Name format without expanders:
hba_pci_address-sas-phyX-lunY-partZ
Signed-off-by: Maurizio Lombardi
---
src/udev/udev-builtin-path_id.c | 96 -
1 file changed, 95 insertions(+), 1 deletion(-)
diff --git a/src/udev/udev-builtin-path_id.c b/src/udev/udev-builtin-path_id.c
index 073f05a..7a97411 100644
--- a/src/udev/udev-builtin-path_id.c
+++ b/src/udev/udev-builtin-path_id.c
@@ -118,7 +118,7 @@ out:
return parent;
}
-static struct udev_device *handle_scsi_sas(struct udev_device *parent, char
**path) {
+static struct udev_device *handle_scsi_sas_wide_port(struct udev_device
*parent, char **path) {
struct udev *udev = udev_device_get_udev(parent);
struct udev_device *targetdev;
struct udev_device *target_parent;
@@ -154,6 +154,100 @@ out:
return parent;
}
+static struct udev_device *handle_scsi_sas(struct udev_device *parent, char
**path)
+{
+struct udev *udev = udev_device_get_udev(parent);
+struct udev_device *targetdev;
+struct udev_device *target_parent;
+struct udev_device *port;
+struct udev_device *expander;
+struct udev_device *target_sasdev = NULL;
+struct udev_device *expander_sasdev = NULL;
+struct udev_device *port_sasdev = NULL;
+const char *sas_address = NULL;
+const char *phy_id;
+const char *phy_count;
+char *lun = NULL;
+
+targetdev = udev_device_get_parent_with_subsystem_devtype(parent,
"scsi", "scsi_target");
+if (targetdev == NULL)
+return NULL;
+
+target_parent = udev_device_get_parent(targetdev);
+if (target_parent == NULL)
+return NULL;
+
+/* Get sas device */
+target_sasdev = udev_device_new_from_subsystem_sysname(udev,
+ "sas_device",
udev_device_get_sysname(target_parent));
+if (target_sasdev == NULL)
+return NULL;
+
+/* The next parent is sas port */
+port = udev_device_get_parent(target_parent);
+if (port == NULL) {
+parent = NULL;
+goto out;
+}
+
+/* Get port device */
+port_sasdev = udev_device_new_from_subsystem_sysname(udev,
+ "sas_port", udev_device_get_sysname(port));
+
+phy_count = udev_device_get_sysattr_value(port_sasdev, "num_phys");
+if (phy_count == NULL) {
+ parent = NULL;
+ goto out;
+}
+
+/* Check if we are simple disk */
+if (strncmp(phy_count, "1", 2) != 0) {
+ parent = handle_scsi_sas_wide_port(parent, path);
+ goto out;
+}
+
+/* Get connected phy */
+phy_id = udev_device_get_sysattr_value(target_sasdev,
"phy_identifier");
+if (phy_id == NULL) {
+parent = NULL;
+goto out;
+}
+
+/* The port's parent is either hba or expander */
+expander = udev_device_get_parent(port);
+if (expander == NULL) {
+parent = NULL;
+goto out;
+}
+
+/* Get expander device */
+expander_sasdev = udev_device_new_from_subsystem_sysname(udev,
+ "sas_device", udev_device_get_sysname(expander));
+if (expander_sasdev != NULL) {
+ /* Get expander's address */
+ sas_address = udev_device_get_sysattr_value(expander_sasdev,
+"sas_address");
+ if (sas_address == NULL) {
+parent = NULL;
+goto out;
+ }
+}
+
+format_lun_number(parent, &lun);
+if (sas_address)
+ path_prepend(path, "sas-exp%s-phy%s-%s", sas_address, phy_id,
lun);
+else
+ path_prepend(path, "sas-phy%s-%s", phy_id, lun);
+
+if (lun)
+free(lun);
+out:
+udev_device_unref(target_sasdev);
+udev_device_unref(expander_sasdev);
+udev_device_unref(port_sasdev);
+return parent;
+}
+
static struct udev_device *handle_scsi_iscsi(struct udev_device *parent, char
**path) {
struct udev *udev = udev_device_get_udev(parent);
struct udev_device *transportdev;
--
Maurizio Lombardi
___
systemd-devel
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
On 09/22/2014 11:40 AM, Reindl Harald wrote: Am 22.09.2014 um 13:28 schrieb Jóhann B. Guðmundsson: On 09/22/2014 09:23 AM, Reindl Harald wrote: Am 22.09.2014 um 01:48 schrieb Jóhann B. Guðmundsson: The reason for increased log entries in the journal is that more things are happening now since this is what happening when a job is run. that don't change the fact that a user not acting as systemd-developer and not debugging his system don't need that flood I guess we have different meaning of message flood again: we talk about rsyslog, like it or not Then file a bug report against rsyslog and provide a patch which fixes the default log filtering in Fedora to your expectation but leave systemd out of it. what you filter below is what i have in /var/log/cron and /var/log/secure but the other messages spit to the log are a lot more here you have a simple calculation https://bugzilla.redhat.com/show_bug.cgi?id=1072368#c8 why don't you look at https://bugzilla.redhat.com/show_bug.cgi?id=1072368 and the workaround "loginctl enable-linger" leads to another bugreport open for months: https://bugzilla.redhat.com/show_bug.cgi?id=1088619#c54 so what we have now is log flooding or hanging shutdowns why don't upstream just what users would help and reduce logging in a non-debug mode to a minimum so one can see without filter if something unusal happens on a system? if the developers would accept the need of their users then likely the users would also be more positive, just don't explain me how to maintain my servers i am fine with distribute-command.sh "cat /var/log/messages" all they years because the general log is silent until something bad happens you can't do that if systemd floods it for 30 machines # journalctl -f Sep 22 11:13:01 localhost.localdomain systemd[1]: Starting Session 59 of user johannbg. Sep 22 11:13:01 localhost.localdomain systemd[1]: Started Session 59 of user johannbg. Sep 22 11:13:01 localhost.localdomain CROND[7336]: (johannbg) CMD (/bin/systemd-cat -t "CROND" /bin/echo "Systemd journal cron job log test every minute" ) Sep 22 11:13:01 localhost.localdomain CROND[7336]: Systemd journal cron job log test every minute Hey let's filter this even further # journalctl -f SYSLOG_IDENTIFIER=CROND -- Logs begin at Thu 2013-10-24 11:47:22 GMT. -- Sep 22 11:14:01 localhost.localdomain CROND[7401]: (johannbg) CMD (/bin/systemd-cat -t "CROND" /bin/echo "Systemd journal cron job log test every minute" ) Sep 22 11:14:01 localhost.localdomain CROND[7401]: Systemd journal cron job log test every minute Anything regarding an text file and local and or remote logging using either rsyslog or syslog-ng is and it's default is not relevant to us and usually set by distribution maintainers. For remote logging I would assume administrator would create an cron filter which has the syslog identifier crond or CROND, the syslog facility 9 and an priority 6 and send that to the remote server So if systemd output is too much in any text file <-- file a bug against rsyslog or syslog-ng depending on which the distribution and have *them* fix their default filtering JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
Am 22.09.2014 um 13:45 schrieb Jóhann B. Guðmundsson: > On 09/22/2014 11:40 AM, Reindl Harald wrote: >> Am 22.09.2014 um 13:28 schrieb Jóhann B. Guðmundsson: >>> On 09/22/2014 09:23 AM, Reindl Harald wrote: Am 22.09.2014 um 01:48 schrieb Jóhann B. Guðmundsson: > The reason for increased log entries in the journal is that more things > are happening now since this is what happening when a job is run. that don't change the fact that a user not acting as systemd-developer and not debugging his system don't need that flood >>> I guess we have different meaning of message flood >> again: we talk about rsyslog, like it or not > > Then file a bug report against rsyslog and provide a patch which fixes > the default log filtering in Fedora to your expectation but leave > systemd out of it. wow - in any other case the systemd developers saying that they don't workround things because problems has to be solved at the root-cause - practice what you preach and make the log-verbosility configureable! * rsyslog is *not* responsible for the message flood produced by systemd * systemd is the one producing it without prefixes produce 8 loglines noise on a small infrastructure is insane that's the same all other services produce together is it really that hard to accept that this level of informations is only helpful for debugging, produces overhead if it could be filtered away and anyways has the bad impact that journald in rsyslog envoironments has the whole day to do with rotate [Journal] Storage=volatile Compress=yes RateLimitInterval=10s frankly i have seen more or less idle machines where journald is one of the top ressource consumers >> what you filter below is what i have in /var/log/cron and /var/log/secure >> but the other messages spit to the log are a lot more >> >> here you have a simple calculation >> https://bugzilla.redhat.com/show_bug.cgi?id=1072368#c8 >> >> why don't you look at https://bugzilla.redhat.com/show_bug.cgi?id=1072368 >> and the workaround "loginctl enable-linger" leads to another bugreport >> open for months: https://bugzilla.redhat.com/show_bug.cgi?id=1088619#c54 >> >> so what we have now is log flooding or hanging shutdowns >> why don't upstream just what users would help and reduce logging >> in a non-debug mode to a minimum so one can see without filter >> if something unusal happens on a system? >> >> if the developers would accept the need of their users then likely the users >> would also be more positive, just don't explain me how to maintain my servers >> >> i am fine with distribute-command.sh "cat /var/log/messages" all they >> years because the general log is silent until something bad happens >> >> you can't do that if systemd floods it for 30 machines >> >>> # journalctl -f >>> Sep 22 11:13:01 localhost.localdomain systemd[1]: Starting Session 59 of >>> user johannbg. >>> Sep 22 11:13:01 localhost.localdomain systemd[1]: Started Session 59 of >>> user johannbg. >>> Sep 22 11:13:01 localhost.localdomain CROND[7336]: (johannbg) CMD >>> (/bin/systemd-cat -t "CROND" /bin/echo "Systemd >>> journal cron job log test every minute" ) >>> Sep 22 11:13:01 localhost.localdomain CROND[7336]: Systemd journal cron job >>> log test every minute >>> >>> Hey let's filter this even further >>> >>> # journalctl -f SYSLOG_IDENTIFIER=CROND >>> -- Logs begin at Thu 2013-10-24 11:47:22 GMT. -- >>> Sep 22 11:14:01 localhost.localdomain CROND[7401]: (johannbg) CMD >>> (/bin/systemd-cat -t "CROND" /bin/echo "Systemd >>> journal cron job log test every minute" ) >>> Sep 22 11:14:01 localhost.localdomain CROND[7401]: Systemd journal cron job >>> log test every minute >>> >>> Anything regarding an text file and local and or remote logging using >>> either rsyslog or syslog-ng is and it's >>> default is not relevant to us and usually set by distribution maintainers. >>> >>> For remote logging I would assume administrator would create an cron filter >>> which has the syslog identifier crond >>> or CROND, the syslog facility 9 and an priority 6 and send that to the >>> remote server >>> >>> So if systemd output is too much in any text file <-- file a bug against >>> rsyslog or syslog-ng depending on which >>> the distribution and have *them* fix their default filtering 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] Incorrect logic when /etc/machine-id is missing
On 22/09/14 10:27, Jan Synacek wrote: > If /etc/machine-id is missing on the system, the first open() call > should probably handle that case. That's actually not true (at least on > my system), because the underlying filesystem is read-only at that > time. *What* is not true on your system? Are you saying that it is not true that /etc/machine-id is missing? (From context, probably not.) Are you saying that the first open() call doesn't handle ENOENT? (It "handles" it by trying the second open() call, in the hope that that might work better, because maybe the first one failed with EPERM; trying the second one on ENOENT is useless, but harmless.) > Now I was determined to fix this bug, however I'm left clueless as to > how this is actually supposed to work. Is the entire logic in this piece > of code wrong, or am I missing something? How is the > (re)generating/mounting of machine-id supposed to work? Installation of systemd is meant to create and populate /etc/machine-id (in the dpkg postinst, RPM %post, or whatever is the equivalent on your distribution). If that doesn't happen, systemd does the best it can to rectify the situation. Re-creating it would work, if your initramfs happened to have mounted the root filesystem read/write. If you're deleting /etc/machine-id in order to wipe a machine's identity when cloning the filesystem, then, yes, the "generate a temporary machine ID and mount it over the top" logic is not going to work. In Debian's live-build tool, I contributed a patch[1] to change the logic from "delete /etc/machine-id" to "truncate /etc/machine-id to 0 bytes", which works better. That might help your situation? S [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=745840 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
On 09/22/2014 12:07 PM, Reindl Harald wrote: Am 22.09.2014 um 13:45 schrieb Jóhann B. Guðmundsson: >On 09/22/2014 11:40 AM, Reindl Harald wrote: >>Am 22.09.2014 um 13:28 schrieb Jóhann B. Guðmundsson: >>>On 09/22/2014 09:23 AM, Reindl Harald wrote: Am 22.09.2014 um 01:48 schrieb Jóhann B. Guðmundsson: >The reason for increased log entries in the journal is that more things >are happening now since this is what happening when a job is run. that don't change the fact that a user not acting as systemd-developer and not debugging his system don't need that flood >>>I guess we have different meaning of message flood >>again: we talk about rsyslog, like it or not > >Then file a bug report against rsyslog and provide a patch which fixes >the default log filtering in Fedora to your expectation but leave >systemd out of it. wow - in any other case the systemd developers saying that they don't workround things because problems has to be solved at the root-cause - practice what you preach and make the log-verbosility configureable! Serves no purpose whatsoever doing that. * rsyslog is*not* responsible for the message flood produced by systemd No but it is responsible for the filtering <-- of log messages. * systemd is the one producing it without prefixes This is simply untrue as "journalctl -o export" will show you. I suggest you stop blaming systemd for your own administrative incompetence and broken implementation of rsyslog and syslog-ng in Fedora ( I tried to get it fixed before we defaulted to journal YES IT WAS BROKEN BEFORE AND STILL IS but was not allowed to do so thank those Red Hatters in the governing body's of Fedora ( FESCO/FPC ) for it's brokeness ) and write an rsyslog template suited for your environment which will filter things to your liking and expectation or better yet complain to those FESCO/FPC members since they need to learn a hard lesson of accepting responsibility for their own actions in the distribution. You can find how to write an rsyslog template in the upstream rsyslog documentation using it's powerful filtering capabilities and by looking at for example the one spice-vdagentd /etc/rsyslog.d/spice-vdagentd.conf in Fedora. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
Am 22.09.2014 um 14:44 schrieb Jóhann B. Guðmundsson: >>> > Then file a bug report against rsyslog and provide a patch which fixes >>> > the default log filtering in Fedora to your expectation but leave >>> > systemd out of it. >> wow - in any other case the systemd developers saying that >> they don't workround things because problems has to be >> solved at the root-cause - practice what you preach and >> make the log-verbosility configureable! > > Serves no purpose whatsoever doing that. >> >> * rsyslog is *not* responsible for the message flood produced by systemd > > No but it is responsible for the filtering <-- of log messages. > >> * systemd is the one producing it without prefixes it is ridiculous to have the need of filtering > This is simply untrue as "journalctl -o export" will show you. where is it in the message? the process is "systemd" how to distinct between user sessions and systemn boot? ":programname" don't work and ":msg, startswith" don't work Mar 18 23:01:01 rawhide systemd[577]: Stopped target Default. Mar 18 23:01:01 rawhide systemd[577]: Stopping Basic System. Mar 18 23:01:01 rawhide systemd[577]: Stopped target Basic System. Mar 18 23:01:01 rawhide systemd[577]: Stopping Paths. ... > I suggest you stop blaming systemd for your own administrative incompetence i suggest you get rid of that arrogance and some other developers too because it's the reason for the subject and proves that you *do not* care about users as long you have not the same opinion you are the one demanding a friendly tone from me, well, than practice what you preach or stop whining if someone calls you names the next time who do you think you are to assess others incompetence? > and broken implementation of rsyslog and syslog-ng in Fedora > (I tried to get it fixed before we defaulted to journal YES IT > WAS BROKEN BEFORE AND STILL IS but was not allowed to do so > thank those Red Hatters in the governing body's of Fedora > ( FESCO/FPC ) for it's brokeness) just don't create messages the majority of users don't want and need to see until debugging and even systemd needs to realize that the world is not turning around it > and write an rsyslog template suited for your environment which > will filter things to your liking and expectation or better yet > complain to those FESCO/FPC members since they need to learn a > hard lesson of accepting responsibility for their own actions > in the distribution who do you think you are? that arrogance and pure ignorance is the reason for subject and related websites as well as for users from time to time not complaining as nice as you would like it hence fedora devel CC'ed __ here the relevant links you decided to strip out and replace with your arrogant abuse as you always do if someone has a differnt opinion but demand from others not act the same way here you have a simple calculation https://bugzilla.redhat.com/show_bug.cgi?id=1072368#c8 why don't you look at https://bugzilla.redhat.com/show_bug.cgi?id=1072368 and the workaround "loginctl enable-linger" leads to another bugreport open for months: https://bugzilla.redhat.com/show_bug.cgi?id=1088619#c54 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] Cannot get Shutdown Script to Run (Libvirt Virtual Machine Shutdown)
On 22 September 2014 07:57, Alexander Groleau wrote: > I have tried the following script as well during my adventures with no > success: > > [Unit] > Description=Start/Stop Libvirt Windows Guest > Documentation=man:libvirtd(8) > Documentation=http://libvirt.org > After=libvirtd.service Manually ordering services with Before=/After= is usually a mistake. Try using Requires= or BindTo= instead, and let systemd handle ordering for you. > [Service] > ExecStart=/usr/bin/libvirt-windows.sh start > ExecStop=/usr/bin/libvirt-windows.sh stop > RemainAfterExit=yes > Type=oneshot > StandardOutput=journal+console > > [Install] > WantedBy=multi-user.target > > This works for boot (my sh script is run right after libvirtd is started); > however, the libvirtd daemon, started by libvirtd.service, is always > terminated well before my sh is run on shutdown/reboot. I can't see any other obvious problems. This should just work, unless something other than systemd is killing your libvirtd. Regards, T G-R ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Cannot get Shutdown Script to Run (Libvirt Virtual Machine Shutdown)
On Sep 22, 2014 4:07 PM, "Tobias Geerinckx-Rice" < tobias.geerinckx.r...@gmail.com> wrote: > > On 22 September 2014 07:57, Alexander Groleau wrote: > > I have tried the following script as well during my adventures with no > > success: > > > > [Unit] > > Description=Start/Stop Libvirt Windows Guest > > Documentation=man:libvirtd(8) > > Documentation=http://libvirt.org > > After=libvirtd.service > > Manually ordering services with Before=/After= is usually a mistake. > Try using Requires= or BindTo= instead, and let systemd handle > ordering for you. Neither Requires nor BindsTo imply any ordering though. So that might in fact *create* race conditions, if both A and B start at once, but A already expects B to be available. > > > [Service] > > ExecStart=/usr/bin/libvirt-windows.sh start > > ExecStop=/usr/bin/libvirt-windows.sh stop > > RemainAfterExit=yes > > Type=oneshot > > StandardOutput=journal+console > > > > [Install] > > WantedBy=multi-user.target > > > > This works for boot (my sh script is run right after libvirtd is started); > > however, the libvirtd daemon, started by libvirtd.service, is always > > terminated well before my sh is run on shutdown/reboot. > > I can't see any other obvious problems. This should just work, unless > something other than systemd is killing your libvirtd. > > Regards, > > T G-R > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- Mantas Mikulėnas ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
Hi, On 22/09/14 15:58, Reindl Harald wrote: > > Am 22.09.2014 um 14:44 schrieb Jóhann B. Guðmundsson: > Then file a bug report against rsyslog and provide a patch which fixes > the default log filtering in Fedora to your expectation but leave > systemd out of it. >>> wow - in any other case the systemd developers saying that >>> they don't workround things because problems has to be >>> solved at the root-cause - practice what you preach and >>> make the log-verbosility configureable! >> >> Serves no purpose whatsoever doing that. Could you elaborate? As generating 8 lines of log seems a bit excessive (seems in one bug which is linked it is rather a calculationg). I would definitly classify that as a bug. (It could for example keep a cpu or system from sleeping, thus draining more power). Anyway usually less debug is better as it is more obvious where a problem might be imho. Of course it is always a question about finding a balance. >>> * rsyslog is *not* responsible for the message flood produced by systemd >> >> No but it is responsible for the filtering <-- of log messages. >>> >>> * systemd is the one producing it without prefixes > > it is ridiculous to have the need of filtering > >> This is simply untrue as "journalctl -o export" will show you. > > where is it in the message? > the process is "systemd" Instead of blaming someone for being incompetent you could just have given the solution. Especially as you mentioned you knew something like that might happen but blamed Red Hat for not implementing a potential fix. Which you could have even documented and somebody could have found googling for it. That would have saved time for everybody involved. Although from what I know I rather agree there is a bug in systemd. You also seem to forget systemd adds a lot of layers of complexity that just did not exist with the old init. It makes it a lot harder to find out what is going on (despite all the available documentation). So if the prefix does not show in an obvious manner I could categorize that as a bug too. In this case it might actually make sense to have a different prefix as it will clearly indicate user vs system session. Also despite the loglevels available in journald. It is unclear from the documentation how the classification gets done http://www.freedesktop.org/software/systemd/man/journald.conf.html Maybe for our problem MaxLevelSyslog=err might work? But how do we know it won't suppress certain messages we would like to see and actually suppresses the one we don't want? Regards, Philippe ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
On 09/22/2014 12:58 PM, Reindl Harald wrote: i suggest you get rid of that arrogance and some other developers too because it's the reason for the subject and proves that you *do not* care about users as long you have not the same opinion you are the one demanding a friendly tone from me, well, than practice what you preach or stop whining if someone calls you names the next time who do you think you are to assess others incompetence? I think I'm the one based on your own actions as in after you cant even take your time to a read upstream rsyslog documentation then insert a single line of filtering in rsyslog, similar or equivalent of ":programname, isequal, "systemd" -/var/log/systemd.log" to filter out systemd message from /var/log/message or fine tune the filtering through the use of rsyslog templates and submit that as a patch against rsyslog in Fedora so the distribution can improve it's default filtering in rsyslog based on your input but instead choose to file gazillion bug reports against systemd which has nothing to do with the text file filtering in the distribution, clutter the comment sections with useless output in those bug reports "to prove your point over and over again" and call the lead developer of the project an idiot in one of those reports then show up upstream cursing and demanding fixes saying that systemd message cant be filtering even thou I pointed to "journalctl -o export" which shows all the messages fields each log contains including all the syslog entries which should provide an capable administrator pleathora of ideas how to filter message in conjunction with rsyslog powerful filtering capabilities and all that rant for something that is not our to fix in the firstplace. 1. https://bugzilla.redhat.com/show_bug.cgi?id=1072368#c4 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
Am 22.09.2014 um 15:55 schrieb Jóhann B. Guðmundsson: > On 09/22/2014 12:58 PM, Reindl Harald wrote: >> i suggest you get rid of that arrogance and some other developers >> too because it's the reason for the subject and proves that you >> *do not* care about users as long you have not the same opinion >> >> you are the one demanding a friendly tone from me, well, than >> practice what you preach or stop whining if someone calls you >> names the next time >> >> who do you think you are to assess others incompetence? > > I think I'm the one based on your own actions as in after you cant even take > your time to a read upstream rsyslog > documentation then insert a single line of filtering in rsyslog, similar or > equivalent of > > ":programname, isequal, "systemd" > -/var/log/systemd.log" no you refuse to understand that *nobody* wants to split out *all* systemd logs because just the excessive *user session* logging and that this messages should not exist at all in a non-debugging environment you also refuse to understand that the intention in production environments using a *centralized* SQL logging is do *drop that messages* but hardly to drop anything from systemd so the next time before you take "incompetence" in your mouth try to understand the context or ask yourself on which side it exists > clutter the comment sections with useless output in those bug > reports "to prove your point over and over again" and call the > lead developer of the project an idiot cause and effect - what reaction did he expect by follow a link to a for weeks existing bugreport and as only action close it with "NOBUG" a minute later > in one of those reports then show up upstream cursing and demanding fixes > saying that systemd message cant be filtering even thou I pointed to > "journalctl > -o export" which shows all the messages fields each log contains including > all the > syslog entries which should provide an capable administrator pleathora of > ideas > how to filter message in conjunction with rsyslog powerful filtering > capabilities > and all that rant for something that is not our to fix in the firstplace. surely - you have no need to produce that flood in the first instance and if you as systemd-developer want that informations then enable deugging but stop to decide what every user needs to have in his logs or actively to filter realize that the world don't turn around systemd developers and just stop your arrogance and ignorance - you will wonder how friendly the same people become complaining all the time if upstream stops to handle users like someone who disturbs > 1. https://bugzilla.redhat.com/show_bug.cgi?id=1072368#c4 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] I wonder… why systemd provokes this amount of polarity and resistance
> From: "Jóhann B. Guðmundsson" > > Did you ever ask yourself why your project provokes that amount of > > resistance and polarity? Did you ever ask yourself whether this > > really is just resistance against anything new from people who > > just do not like "new" or whether it contains*valuable* > > and*important* feedback? > > I'm not sure why you are under the assumption that we do not consider > and have not and are not gathering feedback from individuals, > communities or companies for that matter but I'm going to address your > questions anyway. I've brought a complaint about one of systemd's behaviors here. I have gotten useful feedback allowing me to refine what I think would be a good solution to the problem. What I *haven't* gotten is any useful feedback on how to implement a solution. I suspect others have had similar experiences. One metric that might be useful is to ask: Of the people who complain about one or another aspect of systemd, what fraction ultimately consider their complaint to be satisfactorily resolved? There are also "architectural" issues about systemd that I've noticed. I don't know to what degree these indicate quality control problems with the code, or whether they are just a matter of things being done in ways that are not common in the Un*x universe. But they do seem to me to be things that are going to inhibit adoption. 1. Systemd has some very large binaries, each of which implements many aspects of the system. Conversely, the typical Un*x approach is to separate functions into many executablels, many of which are scripts. The latter approach makes customization easier, especially for sysadmins who aren't deeply familiar with the system. 2. Systemd includes a tremendous number of features and behaviors, but a lot of them aren't documented very well. That's not so unusual in Un*x, but if you're introducing something new, nobody has any prior knowledge of it, and the lack of documentation becomes visible. Ultimately, writing e-mail messages saying "They're wrong" is useless, even if they *are* wrong. If there is a substantial body of people out there who dislike systemd, it's going to prevent its adoption. The fix is adjusting systemd (or the project surrounding it) so that people like it better. Dale ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
On 22/09/14 10:23, Reindl Harald wrote: > honestly the messages about "reaching target" are nonsense without > a prefix pointing out that it is about a *user session* because it > looks like a bootlog every minute You can tell this is not the system instance of systemd (init) because its process ID is > 1. systemd[1] indicates the system instance, systemd[anything else] is a user instance. This might be a useful basis for a filter. Configuring a higher (more severe) LogLevel in /etc/systemd/user.conf would probably also help in your situation. S ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
Am 22.09.2014 um 16:41 schrieb Simon McVittie: > On 22/09/14 10:23, Reindl Harald wrote: >> honestly the messages about "reaching target" are nonsense without >> a prefix pointing out that it is about a *user session* because it >> looks like a bootlog every minute > > You can tell this is not the system instance of systemd (init) because > its process ID is > 1. systemd[1] indicates the system instance, > systemd[anything else] is a user instance. This might be a useful > basis for a filter. first: thank you for a normal answer instead "shut up and go away" if you take that as decision for drop messages you have several problems * drop anything from "systemd" with PID != 1 will also affect future things nobody knows now and not related to user-sessions and so not happening every minute caused by cron * it is wasting of ressources for produce *and* filter the messages > Configuring a higher (more severe) LogLevel in /etc/systemd/user.conf > would probably also help in your situation why is it refused with such a vehemence to consider make default loggings not that verbose in general and act like many other software packages: configured log levels with non verbose defaults * informational * warning * error * fatal error the goal should not be produce a growing amount over the time and then force users how to filter it away - it should not be produced (produce and filter both taking ressources) the relevant information "New session started" was already produced by systemd-logind before introduce the new verbose log and that was easy to direct to /var/log/secure because the process name the normal user cares about * started * no error logged * ended but not about more details until something needs debugging which is unusual as long you are not a systemd-developer 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] Cannot get Shutdown Script to Run (Libvirt Virtual Machine Shutdown)
On 22 September 2014 15:36, Mantas Mikulėnas wrote: >> [Nonsense] > > Neither Requires nor BindsTo imply any ordering though. So that might in > fact *create* race conditions, if both A and B start at once, but A already > expects B to be available. [Indeed. That whole paragraph was hastily re-written and doesn't even make sense as-is: manually ordering is what Before= and After= *do*. They don't explicitly, uhm... imply dependencies, which is what I failed at saying.] On Mon, Sep 22, 2014 at 7:40 AM, Alexander Groleau wrote: > Here is my journalctl log: > > Sep 21 23:14:53 Xerxes9 systemd-logind[340]: System is rebooting. > Sep 21 23:14:53 Xerxes9 libvirtd[605]: End of file while reading data: > Input/output error // HERE IS LIBVIRTD TERMINATING My systems helpfully spam the life out of me when shutting down services. I'd see a "Stopping " line between these, if libvirtd were being stopped cleanly by systemd. Your logs don't mention _any_ services, though. Regards, T G-R ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] udevd: SAS: use SAS addr + PHY id in by-path whenever possible.
Hi Maurizio,
On Mon, Sep 22, 2014 at 11:48 AM, Maurizio Lombardi wrote:
> This patch changes the naming scheme for sas disks. The original names used
> disk's sas address and lun, the new scheme uses sas address of the
> nearest expander (if available) and a phy id of the used connection.
> If no expander is used, the phy id of hba phy is used.
> Note that names that refer to RAID or other abstract devices are
> unchanged.
What's the problem with the current scheme, what's the benefit of the
new one? Will this break backwards compatibility, if so, why is this
justifiable?
Cheers,
Tom
> Name in raid configuration:
> hba_pci_address-sas-raid_sas_address-lunY-partZ
>
> Name in expander bare disk configuration:
> hba_pci_address-sas-expander_sas_address-phyX-lunY-partZ
>
> Name format without expanders:
> hba_pci_address-sas-phyX-lunY-partZ
>
> Signed-off-by: Maurizio Lombardi
> ---
> src/udev/udev-builtin-path_id.c | 96
> -
> 1 file changed, 95 insertions(+), 1 deletion(-)
>
> diff --git a/src/udev/udev-builtin-path_id.c b/src/udev/udev-builtin-path_id.c
> index 073f05a..7a97411 100644
> --- a/src/udev/udev-builtin-path_id.c
> +++ b/src/udev/udev-builtin-path_id.c
> @@ -118,7 +118,7 @@ out:
> return parent;
> }
>
> -static struct udev_device *handle_scsi_sas(struct udev_device *parent, char
> **path) {
> +static struct udev_device *handle_scsi_sas_wide_port(struct udev_device
> *parent, char **path) {
> struct udev *udev = udev_device_get_udev(parent);
> struct udev_device *targetdev;
> struct udev_device *target_parent;
> @@ -154,6 +154,100 @@ out:
> return parent;
> }
>
> +static struct udev_device *handle_scsi_sas(struct udev_device *parent, char
> **path)
> +{
> +struct udev *udev = udev_device_get_udev(parent);
> +struct udev_device *targetdev;
> +struct udev_device *target_parent;
> +struct udev_device *port;
> +struct udev_device *expander;
> +struct udev_device *target_sasdev = NULL;
> +struct udev_device *expander_sasdev = NULL;
> +struct udev_device *port_sasdev = NULL;
> +const char *sas_address = NULL;
> +const char *phy_id;
> +const char *phy_count;
> +char *lun = NULL;
> +
> +targetdev = udev_device_get_parent_with_subsystem_devtype(parent,
> "scsi", "scsi_target");
> +if (targetdev == NULL)
> +return NULL;
> +
> +target_parent = udev_device_get_parent(targetdev);
> +if (target_parent == NULL)
> +return NULL;
> +
> +/* Get sas device */
> +target_sasdev = udev_device_new_from_subsystem_sysname(udev,
> + "sas_device",
> udev_device_get_sysname(target_parent));
> +if (target_sasdev == NULL)
> +return NULL;
> +
> +/* The next parent is sas port */
> +port = udev_device_get_parent(target_parent);
> +if (port == NULL) {
> +parent = NULL;
> +goto out;
> +}
> +
> +/* Get port device */
> +port_sasdev = udev_device_new_from_subsystem_sysname(udev,
> + "sas_port", udev_device_get_sysname(port));
> +
> +phy_count = udev_device_get_sysattr_value(port_sasdev, "num_phys");
> +if (phy_count == NULL) {
> + parent = NULL;
> + goto out;
> +}
> +
> +/* Check if we are simple disk */
> +if (strncmp(phy_count, "1", 2) != 0) {
> + parent = handle_scsi_sas_wide_port(parent, path);
> + goto out;
> +}
> +
> +/* Get connected phy */
> +phy_id = udev_device_get_sysattr_value(target_sasdev,
> "phy_identifier");
> +if (phy_id == NULL) {
> +parent = NULL;
> +goto out;
> +}
> +
> +/* The port's parent is either hba or expander */
> +expander = udev_device_get_parent(port);
> +if (expander == NULL) {
> +parent = NULL;
> +goto out;
> +}
> +
> +/* Get expander device */
> +expander_sasdev = udev_device_new_from_subsystem_sysname(udev,
> + "sas_device", udev_device_get_sysname(expander));
> +if (expander_sasdev != NULL) {
> + /* Get expander's address */
> + sas_address = udev_device_get_sysattr_value(expander_sasdev,
> +"sas_address");
> + if (sas_address == NULL) {
> +parent = NULL;
> +goto out;
> + }
> +}
> +
> +format_lun_number(parent, &lun);
> +if (sas_address)
> + path_prepend(path, "sas-exp%s-phy%s-%s", sas_address,
> phy_id, lun);
> +else
> + path_prepend(path, "sas-phy%s-%s", phy_id, lun)
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
On Mon, Sep 22, 2014 at 2:44 PM, "Jóhann B. Guðmundsson" wrote: > > On 09/22/2014 12:07 PM, Reindl Harald wrote: > > Am 22.09.2014 um 13:45 schrieb Jóhann B. Guðmundsson: > >> On 09/22/2014 11:40 AM, Reindl Harald wrote: > >>> Am 22.09.2014 um 13:28 schrieb Jóhann B. Guðmundsson: > On 09/22/2014 09:23 AM, Reindl Harald wrote: > > Am 22.09.2014 um 01:48 schrieb Jóhann B. Guðmundsson: > >> The reason for increased log entries in the journal is that more >> things >> are happening now since this is what happening when a job is run. > > that don't change the fact that a user not acting as > systemd-developer and not debugging his system don't > need that flood > I guess we have different meaning of message flood > >>> again: we talk about rsyslog, like it or not > >> >> Then file a bug report against rsyslog and provide a patch which fixes >> the default log filtering in Fedora to your expectation but leave >> systemd out of it. > > wow - in any other case the systemd developers saying that > they don't workround things because problems has to be > solved at the root-cause - practice what you preach and > make the log-verbosility configureable! > > > Serves no purpose whatsoever doing that. > > > * rsyslog is *not* responsible for the message flood produced by systemd > > > No but it is responsible for the filtering <-- of log messages. > > * systemd is the one producing it without prefixes > > > This is simply untrue as "journalctl -o export" will show you. > > I suggest you stop blaming systemd for your own administrative incompetence > and broken implementation of rsyslog and syslog-ng in Fedora Please let's not stoop to this level of name-calling. I haven't followed this debate in detail, so I don't know how this should be solved, but it seems fair to say that Harald's experience is suboptimal, so let's focus on making constructive suggestions for how journald/rsyslog or the local/distro config could be improved, rather than who is to blame. Anyway, I think this is decidedly off-topic for this thread, so please move this elsewhere. Cheers, Tom > ( I tried to > get it fixed before we defaulted to journal YES IT WAS BROKEN BEFORE AND > STILL IS but was not allowed to do so thank those Red Hatters in the > governing body's of Fedora ( FESCO/FPC ) for it's brokeness ) and write an > rsyslog template suited for your environment which will filter things to > your liking and expectation or better yet complain to those FESCO/FPC > members since they need to learn a hard lesson of accepting responsibility > for their own actions in the distribution. > > You can find how to write an rsyslog template in the upstream rsyslog > documentation using it's powerful filtering capabilities and by looking at > for example the one spice-vdagentd /etc/rsyslog.d/spice-vdagentd.conf in > Fedora. > > JBG > > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/systemd-devel > ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
On 22 September 2014 15:16, Dale R. Worley wrote: > 2. Systemd includes a tremendous number of features and behaviors, but > a lot of them aren't documented very well. That's not so unusual in > Un*x, but if you're introducing something new, nobody has any prior > knowledge of it, and the lack of documentation becomes visible. > It's maybe not so unusual in *nix, globbed to include Linux and starting in the past decade, but is unusual in Unix. When I started on Linux it was still possible to use all that documentation (http://www.opengroup.org/ was massively useful) and I spent quite some time understanding Posix standards and how things fitted together. You could teach yourself how to programme, use cron, administer the system, from man pages. -- imalone http://ibmalone.blogspot.co.uk ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] journalctl: allow customizable output formats
The current '--output FORMAT' argument defines a number of common output formats, but there are some useful cases it does cover. In particular when reading application logs it is often desirable to display the code file name, line number and function name. Rather than defining yet more fixed output formats, this patch introduces user defined output formats. The format string is an arbitrary string which contains a mixture of literal text and variable subsistitions. Each variable name corresponds to a journal field name. A variable name can be optionally followed by a data type, and in the case of string types, a length limit. This is best illustrated with an example: $ journalctl -o "format:%(__REALTIME_TIMESTAMP) \ [%(CODE_FILE):%(CODE_LINE):%(CODE_FUNC)] \ %(MESSAGE:string:80)\n" _COMM=libvirtd -- Logs begin at Mon 2013-12-23 16:31:41 GMT, end at Mon 2014-09-22 16:13:00 BST. -- Dec 23 17:19:25 [util/virlog.c:877:virLogVMessage] libvirt version: 1.1.3.1, package: 2.fc20 (Fedora Project, 2013-11-17-23:28:43, ... Dec 23 17:19:25 [conf/storage_conf.c:854:virStoragePoolDefParseXML] XML error: unknown storage pool type btrfs Dec 23 17:19:30 [conf/domain_conf.c:12671:virDomainObjParseNode] XML error: unexpected root element , expecting Dec 23 17:24:45 [qemu/qemu_monitor.c:653:qemuMonitorIO] internal error: End of file from monitor Dec 23 20:12:00 [qemu/qemu_monitor.c:653:qemuMonitorIO] internal error: End of file from monitor -- Reboot -- Dec 23 21:06:14 [util/virlog.c:877:virLogVMessage] libvirt version: 1.1.3.1, package: 2.fc20 (Fedora Project, 2013-11-17-23:28:43, ... Dec 23 21:06:21 [conf/storage_conf.c:854:virStoragePoolDefParseXML] XML error: unknown storage pool type btrfs Signed-off-by: Daniel P. Berrange --- man/journalctl.xml| 76 + src/journal-remote/journal-gatewayd.c | 11 +- src/journal/journalctl.c | 39 ++- src/shared/logs-show.c| 532 ++ src/shared/logs-show.h| 16 +- src/shared/output-mode.h | 1 + src/systemctl/systemctl.c | 20 +- 7 files changed, 615 insertions(+), 80 deletions(-) diff --git a/man/journalctl.xml b/man/journalctl.xml index acd75a6..bd8c2bd 100644 --- a/man/journalctl.xml +++ b/man/journalctl.xml @@ -375,6 +375,21 @@ + + + + format:FMT + + +generates output +according to the format +specification given in +the FMT string. See the +OUTPUT FORMAT STRINGS +section for details + + + @@ -878,6 +893,64 @@ +Output Format Strings + +An output format string provides precise control how journal +data records are formatted for output. A format string consists of +mixture of literal text and variables to be substituted with journal +data records. A variable takes the general form + +$(NAME:TYPE:LEN) + +The NAME component corresponds to any journal entry field +(eg MESSAGE, _SYSTEMD_UNIT, CODE_FUNC, etc). The TYPE component +determines the data format to use for printing the value. If +omitted, it defaults to a sensible format for the NAME of the +field. The LEN component places an upper limit on the length of +strings being printed, beyond which they will be ellipsized. +The valid data types for TYPE are: + + + +string +displayed if a printable string. If the value +contains non-printable characters, it will be shown as +'[blob data]'. + + + +string-raw +displayed as a raw string. All characters, +including non-printable o
Re: [systemd-devel] [PATCH] udevd: SAS: use SAS addr + PHY id in by-path whenever possible.
On 22/09/14 17:58, Tom Gundersen wrote: > Hi Maurizio, > > On Mon, Sep 22, 2014 at 11:48 AM, Maurizio Lombardi > wrote: >> This patch changes the naming scheme for sas disks. The original names used >> disk's sas address and lun, the new scheme uses sas address of the >> nearest expander (if available) and a phy id of the used connection. >> If no expander is used, the phy id of hba phy is used. >> Note that names that refer to RAID or other abstract devices are >> unchanged. > What's the problem with the current scheme, what's the benefit of the > new one? Will this break backwards compatibility, if so, why is this > justifiable? > I wonder if it will solve this one... https://bugs.freedesktop.org/show_bug.cgi?id=63806 ? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] shared/util.h: portable sizeof(long) == sizeof(int) test
Hi On Fri, Sep 19, 2014 at 10:56 PM, Emil Renner Berthing wrote: > On 19 September 2014 22:19, David Herrmann wrote: >> On Fri, Sep 19, 2014 at 8:26 PM, Emil Renner Berthing >> wrote: >>> Don't rely on __WORDSIZE, but just standard LONG_MAX >>> and INT_MAX from limits.h. >> >> Why? The commit message lacks any explanation of that change. > > Ah, sorry. This is a better version of the [RFC 5/25] patch I sent earlier. > The point is that __WORDSIZE is not portable, but both > LONG_MAX and INT_MAX are mandated in limits.h. > > I can resend with this explanation in the commit message if you want. I rewrote the commit-message and pushed the fix. Thanks David ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] journalctl: allow customizable output formats
On 22 September 2014 11:33, Daniel P. Berrange wrote: > The current '--output FORMAT' argument defines a number of > common output formats, but there are some useful cases it > does cover. In particular when reading application logs it > is often desirable to display the code file name, line number > and function name. Rather than defining yet more fixed output > formats, this patch introduces user defined output formats. > > The format string is an arbitrary string which contains a > mixture of literal text and variable subsistitions. Each > variable name corresponds to a journal field name. A variable > name can be optionally followed by a data type, and in the > case of string types, a length limit. > As an opposing point of view, I've been accomplishing this by piping output through a script that parses and displays JSON. I rather this style of composability than passing format strings to journalctl itself. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] journalctl: allow customizable output formats
On Monday 22 September 2014 at 12:43:28, Daurnimator wrote: > On 22 September 2014 11:33, Daniel P. Berrange wrote: > > > The current '--output FORMAT' argument defines a number of > > common output formats, but there are some useful cases it > > does cover. In particular when reading application logs it > > is often desirable to display the code file name, line number > > and function name. Rather than defining yet more fixed output > > formats, this patch introduces user defined output formats. > > > > The format string is an arbitrary string which contains a > > mixture of literal text and variable subsistitions. Each > > variable name corresponds to a journal field name. A variable > > name can be optionally followed by a data type, and in the > > case of string types, a length limit. > > > > As an opposing point of view, I've been accomplishing this by piping output > through a script that parses and displays JSON. > I rather this style of composability than passing format strings to > journalctl itself. I think that using dedicated ad-hoc JSON parser for customizing output is an overkill. For that matter, Git has support for custom output format in its "log" command, and I've found it useful many times. -- Ivan Shapovalov / intelfx / signature.asc Description: This is a digitally signed message part. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Cannot get Shutdown Script to Run (Libvirt Virtual Machine Shutdown)
Hmm, This is a fresh installation of arch linux with systemd. What else might be terminating my daemons or how might I be able to figure that out? Thanks, Alex On Mon, Sep 22, 2014 at 10:52 AM, Tobias Geerinckx-Rice < tobias.geerinckx.r...@gmail.com> wrote: > On 22 September 2014 15:36, Mantas Mikulėnas wrote: > > >> [Nonsense] > > > > Neither Requires nor BindsTo imply any ordering though. So that might in > > fact *create* race conditions, if both A and B start at once, but A > already > > expects B to be available. > > [Indeed. That whole paragraph was hastily re-written and doesn't even > make sense as-is: manually ordering is what Before= and After= *do*. > They don't explicitly, uhm... imply dependencies, which is what I > failed at saying.] > > On Mon, Sep 22, 2014 at 7:40 AM, Alexander Groleau > wrote: > > > Here is my journalctl log: > > > > Sep 21 23:14:53 Xerxes9 systemd-logind[340]: System is rebooting. > > Sep 21 23:14:53 Xerxes9 libvirtd[605]: End of file while reading data: > > Input/output error // HERE IS LIBVIRTD TERMINATING > > My systems helpfully spam the life out of me when shutting down > services. I'd see a "Stopping " line between these, if > libvirtd were being stopped cleanly by systemd. Your logs don't > mention _any_ services, though. > > Regards, > > T G-R > ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC] runtime configurable timer
On Wed, Sep 17, 2014 at 04:20:14PM +0900, WaLyong Cho wrote: > Before start working it, we need some of discussion about how make the > transient unit. I think we have two options. > One is, as you said, make systemd-at and the other is add option to > systemd-run. (e.g. --OnCalendar=, --OnActiveSec= or so) > If we choose the former, then we should consider how load the relate > unit(service). Because, the timer unit is not working alone. It related > with service unit. So, if the transient timer unit related with already > existing service then it will not much complicate. But if we want to add > both transient timer and transient service then it will more complicate. > In latter case, I think, it is more easier. Because, we can get a all of > information to make two transient service transient timer. Agreed, doing it all from a single systemd-run invocation seems the way to go. It should be both easier to implement and also nicer to use. > But > internally we should call StartTransientUnit method call to start the > timer unit and AddTransientUnit(or LoadTransientUnit(?)) to add service > unit what will be started by the timer unit. Something like that... but there are some corner cases. StartTransientUnit is fairly limited now in what can be set, and I think behaviour should be retained when the unit is started by transient timers. So maybe the best option is simply to extend StartTransientUnit (add a new call StartTransientUnitDelayed or something like that) with a parameter for timer specification. Then have systemd internally created both the transient service unit and a transient timer unit. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Cannot get Shutdown Script to Run (Libvirt Virtual Machine Shutdown)
On 23 September 2014 01:10, Alexander Groleau wrote:
> Hmm,
>
> This is a fresh installation of arch linux with systemd. What else might be
> terminating my daemons or how might I be able to figure that out?
A cursory search linked that suspicious EOF error message to libvirtd
crashing. If that's what's happening here, libvirtd could already be
dead while systemd is correctly handling ExecStop=. Does this error
message appear when manually stopping or restarting just
libvirtd.service?
There may be other hints somewhere in the logs. I just don't
understand why yours don't contain or show those "Stopping..."
messages that mine are full of [1]. You are using plain, unaliased
journalctl, right?
Also, focus on getting "systemd {stop,start,restart} libvirt.service"
to work first, without all the extra complexity (and potential races,
and time) of a full shut-down.
Regards,
T G-R
[1] Messages which are being fiercely attacked elsewhere on this list.
Hurry! ;-)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Cannot get Shutdown Script to Run (Libvirt Virtual Machine Shutdown)
Thanks Tobias for all of the responses. Yes, I am using plain, unaliased
jounalctl on Arch Linux with systemd 216. In fact, I see absolutely no
"Starting" "Stopping" service messages outside of standard triggers. Is
something wrong with my distro? :/ Was the logging changed in 216?
-Alex
On Mon, Sep 22, 2014 at 8:37 PM, Tobias Geerinckx-Rice <
tobias.geerinckx.r...@gmail.com> wrote:
> On 23 September 2014 01:10, Alexander Groleau wrote:
> > Hmm,
> >
> > This is a fresh installation of arch linux with systemd. What else might
> be
> > terminating my daemons or how might I be able to figure that out?
>
> A cursory search linked that suspicious EOF error message to libvirtd
> crashing. If that's what's happening here, libvirtd could already be
> dead while systemd is correctly handling ExecStop=. Does this error
> message appear when manually stopping or restarting just
> libvirtd.service?
>
> There may be other hints somewhere in the logs. I just don't
> understand why yours don't contain or show those "Stopping..."
> messages that mine are full of [1]. You are using plain, unaliased
> journalctl, right?
>
> Also, focus on getting "systemd {stop,start,restart} libvirt.service"
> to work first, without all the extra complexity (and potential races,
> and time) of a full shut-down.
>
> Regards,
>
> T G-R
>
> [1] Messages which are being fiercely attacked elsewhere on this list.
> Hurry! ;-)
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] LUKS passphrase asked twice when using plain device names
Dear systemd and dracut folks, with Debian Sid/unstable, using plain device names like `/dev/sda1` in `/etc/fstab` and `/etc/crypttab` the LUKS passphrase has to be entered twice. Once it asked by dracut and once by systemd. I did not yet try with UUIDs and ask first if that is an error? Thanks, Paul signature.asc Description: This is a digitally signed message part ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
