Do one thing and do it well
Systemd adds filesystem mount tool
The developers behind Systemd, the alternative to sysvinit, have added a mount tool to their user space bootstrapper. The mount tool landed during the weekend in this merge. It gives Systemd users a systemd-mount command, letting the mount command pull in dependencies and use auto-mounting logic. Developer Lennart Poettering …
COMMENTS
-
-
-
-
Monday 22nd August 2016 07:25 GMT richardcox13
Re: re: 1970 thinking.
>The fact that you think computers can do more than one thing at a time, rather
> than spend a tiny amount of time doing one thing then swtiching to another one,
> shows a staggering lack of understanding
And when was the last time you used a computer without multiple CPUs/cores?
Current systems really do multi-task.
-
Monday 22nd August 2016 07:36 GMT bombastic bob
Re: re: 1970 thinking.
"The fact that you think computers can do more than one thing at a time, rather than spend a tiny amount of time doing one thing then swtiching to another one, shows a staggering lack of understanding."
er, you forgot about 'multi-core' dude. Sorry, but I mostly agree with your rant against the "1970 thinking" statement, except that one little detail...
so my quad core CPU can do 4 things at once [and when I write a multi-threaded algorithm, it really does!]. But yeah time-slice thread scheduling on a single core DOES give "the illusion" of doing multiple things at once, while really doing 'what you said'.
-
Monday 22nd August 2016 09:23 GMT analyzer
Re: re: 1970 thinking.
Er - no 'dude' muti-core is just multi cpus.
You can call it a core since that is common practice but each core is a cpu in its own right and can only do one thing at a time then switch to another. These multi core things used to be called CPU Modules, just you kiddies forget the modules bit.
-
-
Monday 22nd August 2016 12:37 GMT Anonymous Coward
Re: re: 1970 thinking.
All the people taking about parallelism don't seem to understand it as an engineering principle. This is more an argument against, for example, the "god object" anti-pattern in OO programming. One thing doing too much which makes maintenance impossible.
As for SIMD, that's Single Instruction! I write GPU shaders. It's extremely important to write them efficiently; branch-less, and using the least number of the least complex instructions possible.
The program does one thing (calculate a single pixel), but has to do it over 2 million times per frame.
-
-
Tuesday 23rd August 2016 09:37 GMT bombastic bob
Re: re: 1970 thinking.
"These multi core things used to be called CPU Modules, just you kiddies forget the modules bit."
eh? I don't think you're talking about the same thing I'm talking about... [but whatever]
if you want to split hairs, then yes, a single CPU CORE will do 'one thing at a time' based on a single thread of execution being 'one thing'. [must I _really_ go this far to avoid ambiguity?]
I consider a multi-core CPU to, in and of itself, be "one CPU" (being as all the other hardware and memory bus is pretty much shared). So from _THAT_ perspective, the CPU can do mutliple 'things' at one time, i.e. multiple threads of execution simultaneously executing on the multiple cores.
semantics - what a pain
-
-
-
This post has been deleted by its author
-
Monday 22nd August 2016 09:29 GMT Andrew Richards
Re: re: 1970 thinking.
Original post wasn't explicitly suggesting that "computers can do more than one thing at a time" is their understanding of how it all works. Do lots of things by rapidly switching between them so you usual can't tell is close enough. Calm down, pedant.
But... my hard disk is retrieving data and will cause an interrupt to awaken a suspended thread and interrupt the current one (not that I'll notice) so it is doing more than one thing at a time. I think the network card is busy doing its stuff too. And that's before we talk "cores". Misunderstanding is yours, I think...
-
Monday 22nd August 2016 16:08 GMT John Hughes
Re: re: 1970 thinking.
The fact that you think computers can do more than one thing at a time, rather than spend a tiny amount of time doing one thing then swtiching to another one, shows a staggering lack of understanding.
Uh...
$ cat /proc/cpuinfo | grep processor
processor : 0
processor : 1
processor : 2
processor : 3
-
-
-
Monday 22nd August 2016 07:32 GMT bombastic bob
"1970 thinking." (by an anon, naturally)
I was 10 years old in 1970. I learned programming on punch cards and these pencil mark 'mark sense' cards that used the same hollerith code. I don't know exactly what you're implying by all of that "1970 thinking" comment, but whenever I hear "remain stuck in the past" I think of an arrogant millenial calling us "gramps" or "old fart" and assuming we're stone-age neanderthals for recognizing 'what works' vs 'new, shiny'.
Show some RESPECT, you young whipper-snapper! And read Arthur C. Clarke's "Superiority".
"Do one thing and do it well". It's an excellent philosophy when it comes to making small utilities that have many many uses. Like a knife. Not a "super-doohickey-2D-flugly-GUI-the-metro" knife, but a general purpose 'works for many things' knife, which can often be repurposed in ways its inventor never DREAMED of, because "do one thing and do it well".
-
-
-
Thursday 25th August 2016 23:51 GMT ElReg!comments!Pierre
I don't care about "new"
One of my sysV servers (6-month uptime with zero downtime, so a rookie server) was inadvertently rebooted (unplugged, as it happens). Uptime is now in the single-digit hours. I investigated and found that systemd (which I NEVER installed manually) is now the init, I can't desinstall it without physical acces (it was happy enough to intall itself without that, though) and it randomly unplugs peripherals (storage, network, etc). I am not entirely happy about that. In 2 days I will be in the server's physical location, systemd's gonna fly through the window, and this time I'm going to pin it out forever.
-
Monday 22nd August 2016 03:37 GMT Christian Berger
Solving problems that do not exist anymore
The people who are targeted by this have mostly moved on to Tablets and Smartphones using Android or IOS. The remaining people understand that you must mount and unmount drives or use cloud or network services. And even if they don't, just mounting it sync will get rid of file corruption for the rest.
Now this wouldn't be a problem if he'd simply write his own version of mount which would just replace any mount you'd want. The problem is that there are dependencies. You will probably no longer be able to use systemd without that new mount, and you will probably not be able to use that new mount without systemd. I mean that whole systemd thing wouldn't be a problem if Poetterling would have just started his own operating system and leave the rest of the Linux community.
-
-
-
Monday 22nd August 2016 15:46 GMT asdf
Re: Solving problems that do not exist anymore
>I'm seriously contemplating *BSD.
I love the BSDs but sadly for many it won't be a suitable replacement yet because its support on laptops is not great (has real problems with suspend and resume on a lot of hardware) and it doesn't have a native Steam client. For a simple office type desktop at home it is great. Although will have to see if Gnome 3 (dumpster fire DE aside gtk is really important) and other FOSS becoming basically Linux only how much that hurts BSD long term.
-
Tuesday 23rd August 2016 08:55 GMT bombastic bob
Re: Solving problems that do not exist anymore
"I love the BSDs but sadly for many it won't be a suitable replacement yet "
I've used FreeBSD for a long time. There are often "linuxy" things written into applications by people who believe that ALL open source operating systems are linux, and have things like systemd running (etc.). So the 'ports' maintainers have to write patches and workarounds for things to compensate. Dbus was one of those patched things, and has had issues with file mounting because of it. gnome wants to mount that file system because you plugged it in, dammit, regardless of what YOU want, and oh you configured it NOT to, so it's not on the desktop... yet you still have to use 'umount -f' to unmount because, DBus.
so yeah, linuxy things being assume/done in the design, ports maintainers have to patch it, does not always work perfectly afterwards.
and this goes back to adding a mount utiltiy to systemd...
WHAT is going to happen on SYSTEMS THAT DO NOT USE SYSTEMD??? Are the desktop people just going to ASSUME that systemd is tehre, and invoke it's version of the mount utility on your behalf?
I hope not.
(smiling daemon logo 'cause I'm on FreeBSD at the moment)
-
Sunday 3rd March 2019 01:28 GMT ds6
Re: Solving problems that do not exist anymore
GTK is pretty well updated on BSD, so I don't think there's much to worry about. While Gnome is questionable on how much uproar would be generated if it were to drop everything but mainstream Linux distros, I very much doubt there would be no one rioting if it were to happen to GTK. It drives too much of desktop *nix to not be available on every platform.
Even if it were to go Linux-only, you already know there would be a fork for it, or at least a replacement.
-
-
-
Monday 22nd August 2016 16:21 GMT eswan
Re: Solving problems that do not exist anymore
"I moved to Slackware to avoid systemd."
I recently moved back to slackware. Ran slackware from ver. 3 (Now with ELF binaries!) to
around ver. 7, then jumped to Debian for aptitude. Returning to slackware feels like putting
on a pair of comfortably worn shoes.
-
-
Monday 22nd August 2016 03:51 GMT Anonymous Coward
I am stupid
I was clearly mistaken when I thought that udisks (alright, udisks2) already pretty much did this, and that udisks was implemented for systemd through polkit/D-Bus.
But the properly set up udisks already automounts drives, and automatically cleans everything up if you yank the drive. It does it by default in most distros. The Ubuntu I'm using now does it without having to write any rules. But Windows isn't a model for a solution: it will still potentially corrupt either file or filesystem if you yank the drive at the wrong point.
So the idea is that now systemd will run fsck on a drive if it's detected to be corrupted when you connect it. Okay, great. But we can do that anyway, if we want. And from what I'm reading this doesn't actually make that any easier than using udisks and fsck. And udisks, despite what Lennart says there, does not explicitly expect the drive to be unmounted before it's pulled:
https://udisks.freedesktop.org/docs/latest/gdbus-org.freedesktop.UDisks2.Filesystem.html
"If the device is removed without being unmounted (e.g. the user yanking the device or pulling the media out) or unmounted in a way that bypasses the Unmount() method (e.g. unmounted by the super-user by using the umount(8) command directly), the device will be unmounted (if needed) and/or the mount point will be cleaned up."
No, it *should* be unmounted, just like you *should* always use "Safely remove drive" in Windows. But there is a specific case in udisks for dealing with what happens when it's not. Systemd-mount does not offer any feature on mount that udisks can't do. And it does not offer protection against yanking the drive. It offers a remedial solution involving calling fsck on mount (which udisks can do). That's not protection. That's called shutting the stable door after the horse has bolted. There is *no* solution to the physical removal problem except not doing it, and it's wrong to paint this as such.
I like systemd. I much prefer it to the alternatives. It has actually made my life a whole bunch easier. But you know, this isn't necessary. There aren't any problems with udisks2 that are fixed with this. All this really means for me - given that the majority of systemd distributions use an all-in approach to features - is that I'm going to have to either disable systemd-mount, or I'm going to spend a whole bunch of time fighting with it to stop it trying to automount or auto-fix removable drives. It's a potential disaster area when you're trying to deal with drives that need recovery or repair and systemd-mount comes along and fires up fsck as soon as you plug it in.
Not necessary. Lennart needs to stop fixing things that aren't broken, and really stop implying that everyone in the community he serves is a relic. He's starting to prove people right about calling him arrogant and single minded. In that Reddit thread, he sounds like he's always sounded toward Linux: every developer is stuck in the past. Which he then uses as an excuse to push for changes that really just let systemd take over that little bit more. "I can't believe we're doing this when no-one uses USB drives any more!" says Lennart, implying that he's the saviour of all the dinosaurs that still do, and that once again he's the progressive developer that really pays attention to the world around him.
Here's hoping the distro devs kick back on this one and just never implement it.
-
Monday 22nd August 2016 05:58 GMT bazza
Re: I am stupid
"Not necessary. Lennart needs to stop fixing things that aren't broken, and really stop implying that everyone in the community he serves is a relic. He's starting to prove people right about calling him arrogant and single minded. In that Reddit thread, he sounds like he's always sounded toward Linux: every developer is stuck in the past. Which he then uses as an excuse to push for changes that really just let systemd take over that little bit more. "
Ah well, that's the problem in these days when so much has already been done. Pottering has a salary to earn, and he can earn it so long as he's fixing "problems". If he were to say something like "nope, nothing needed", then RedHat would be wondering what else to do with him.
Other software houses are similar. Look at MS - they have a team of people whose job it is to scientifically measure "Usability", and design things that are more "Usable". They did pretty well with Windows 7, but should have been sacked immediately afterwards. They weren't sacked, and we ended up with Windows 8, 8.1 and 10 as a result. The Office ribbon came out of the same bunch of people.
The hardest thing ever for a software developer is to admit that, in some respects, software can be "finished", or at least gets to a point where maintenance is needed, not revolution. Fortunately there are bunches out there who are much more cautious with their approach - FreeBSD, Solaris, etc. Even the Linux kernel devs are somewhat cautious - "don't break user land".
The same is true with senior management. Getting a new director in the company is a guarantee that there's going to be a lot of mucking about, regardless as to whether their predecessor had set things up properly or not. Arrrggghhhh! Weirdly this kind of behaviour has generated a whole sub-profession for those who go around cleaning up the mess caused by others who cannot resist making changes for change's sake.
-
-
-
-
Monday 22nd August 2016 15:54 GMT asdf
Re: Amok
Just to spell it out for perhaps newer users to *nix if PID 1 (ie now basically systemd in Linux land) goes down the kernel is required to panic (BSOD in Windows terminology). Therefore systemd is so much more than an init replacement its proponents (basically Red Hat) claim. Its stability now on the majority of Linux distros is as important as the stability of the Linux kernel itself. Therefore, Red Hat shoving shit into PID 1 has a lot more to do with Red Hat business and political reasons than technical ones. Sadly the one thing Red Hat has shown at least me is they basically drive a whole lot of the development in Linux land these days so they can get away with this.
Good read - http://ewontfix.com/14/
-
-
Monday 22nd August 2016 04:24 GMT Anonymous Coward
A Redditor writes :)
@dosida: "Hey Lennart. Out of curiosity (and I mean no disrespect with this) but since you want to improve the functionality and efficiency of mount why not work with whoever's maintaining the mount/umount utility and patch that instead of rewriting it and bundling it with systemd?"
"Why is mount's place in systemd instead of its own individual package? Why should systemd, which is (unless I'm mistaken) an init system and its role stops right after the kernel loads... deal with mounts? Why not rewrite or push patches to udevs which is more appropriate to deal with pluggable devices?"
-
-
-
Monday 22nd August 2016 12:33 GMT Christian Berger
Dynamic hardware?
"Definitely not SysV which falls flat with dynamic hardware which is the norm these days on most systems."
I'm sorry, but systems with "dynamic hardware" are getting less and less common. Laptops rarely have PCMCIA or PCCard slots any more, and even if they have them, they are rarely used. Network cards used to be something you could unplug, today they are a standard part of your chipset, and even if you install additional ones, those are typical PCI-Express based by now.
I mean there used to be a time when your computer might have had 2 PCI network cards a non-PnP ISA one and one that was PnP and it actually dependent on the order in which the modules were loaded how those cards were named, however today you just have one network card, and if you have more that's all on the same bus, which will always be scanned the same way.
The same goes for "multi user" features, particularly "multi seated" features. Yes, that used to be a cool feature back in the early 2000s, but today you can literally buy a Raspberry Pi acting as an X-Server for less than a special multiseat graphics card would set you back.
-
Tuesday 23rd August 2016 09:04 GMT bombastic bob
what do you mean 'dynamic hardware' ? Plugging USB stuff in?
on FBSD I can configure the system to take specific actions when a USB device of a particular type is plugged in. I think you can do the same on a basic Linux system as well, particularly one without systemd on it. I haven't looked at this capability in a while, though.
There's no advantage to running systemd. It's merely "this generation" doing things THEIR way, because it's THEIR TURN. It makes them *feel* important.
[this is also how we ended up with 3 phone OSs, written and force-fed onto customers' desktop computers, being recently excreted out of Redmond - this generation saying "it's OUR turn to do it OUR way now!"]
-
Tuesday 23rd August 2016 09:32 GMT Vic
on FBSD I can configure the system to take specific actions when a USB device of a particular type is plugged in. I think you can do the same on a basic Linux system as well, particularly one without systemd on it.
Yes. Such things were a problem when I first started using Linux (about 17 years ago), but were fixed a very long time back. It's ancient history...
Vic.
-
-
Monday 22nd August 2016 16:12 GMT asdf
systemd the cancer
>Time to get rid of systemd.
Even if you do use another init the way the systemd had wormed itself as being a dependency for an ever widening amount of FOSS if you don't currently require at least having it on your system now (or at least an ever more complicated shim) you will in two years tops.
-
Sunday 3rd March 2019 01:24 GMT ds6
Re: systemd the cancer
Then I'll make my own damn software, init-agnostic. I'm sure there's no shortage and will never be a shortage of creators that don't want to use systemd[icking] and are curmudgeonly enough to develop their own software in defiance, or just want to write clean, portable software with inplementation details up to distro maintainers, package creators, and independent end-users.
-
-
Monday 22nd August 2016 04:46 GMT asdf
good ole PID 1
Well since Red Hat doesn't own the kernel code outright the next best thing for them is to shove as much as shit into PID 1 as possible (are they trying to get rid of processes by you only needing one?). Red Hat has one goal, makes as much money as possible on support by making as much FOSS Linux only as possible. When you look at it from that point of view you have to admire their success even what it has come at the expense of. They did it by churning out more code with tangled dependencies than people could fork around in a short time period (see systemd, Gnome, udev, etc).
-
-
-
Tuesday 23rd August 2016 08:01 GMT Christian Berger
Actually the point of the UNIX philosophy
"Proprietary Unix is on its last legs and the BSDs are woefully lacking development resources."
Well one of the beautiful things about the UNIX philosophy is that it allows you to get lots of bang for the buck. While the BSD people might only have very little resources, they can simply spend it on their operating system.
I mean systemd is mostly about wasting programmers lives. Things like "binary log files" not only need code to generate those files, but also code to read and fix those files. On contrast, text based files can be simply written with basic programming language features, features you need anyhow. They can be read with any software that reads text. Having everything as text saves you from having to have lots and lots of specialized code. I know that, because in a previous job I have written a small unixoid operating system. It's amazing how far you can get with just a simple text editor, a file system and a simple shell.
-
-
-
-
Monday 22nd August 2016 05:53 GMT Skymonrie
I am spartacus
Definition of systemd: systemd is a system and service manager
Definition of food: sustenance to keep animals alive
Both of the above have become so much more, not always for the better. Systemd has made life better in some respects but just as people can binge eat and become obese, it is getting out of hand.
Very soon there is going to come a point where this is systemd Linux, not gnu linux. I'm not against having the choice but, we need to start calling it what it really is. Like an earlier commentor said, this is like windows10. Something a lot of people hate but the same people can get along with windows7.
Call it what it is and end the evermore bitter divide forming in the linux ecosphere because of this one talented maniac. One person can change everything and right now people just don't understand
-
Monday 22nd August 2016 07:04 GMT werdsmith
Re: I am spartacus
There are people that would wish to take leadership on linux and become the de facto linux in much the same way that Faecebook wants to become the de facto www.
It's lucrative.
In order to do that they must runaway with development and come up enhancements that they can lead on.
-
-
Monday 22nd August 2016 07:41 GMT bombastic bob
it's already bad enough with dbus...
it's already bad enough with dbus, trying to auto-mount things when I don't want it to, or causing me to have to use "umount -f" because it partially locks something somewhere internally without telling me about it...
Making systemd have even WORSE behavior, trying to automount things you don't EVER want mounted, like an SD card you're about to do a "dd if=image.img of=/dev/sdcard" or similar to, is JUST another thing that would get in the way and potentially cause system cluster-blank screwups down the road...
and I don't care WHAT file system was on that SD card 10 seconds ago... and the LAST thing I want is some "smart" systemd doohickey AUTO-MOUNTING it, or [worse] FORCING ME TO USE THEIR UTILITY TO UN-AUTO-MOUNT before I can do what I *REALLY* want...
[and if I had to *KILL* an 'fsck' process on that drive, because systemd "FELT" it needed it, when I wanted to _OVERWRITE_ _THE_ _FILE_ _SYSTEM_ I think I'd throw the CPU box through a window and scream until my ears bled)
-
Monday 22nd August 2016 08:11 GMT Anonymous Coward
Re: it's already bad enough with dbus...
Well then, you're not the typical user. The typical user expects to be able to access the card from the moment they stick it in. Perhaps the image writer should be smart enough to realize this ahead of time and request a dismount of the card before writing to it.
You gotta remember that "doing one thing" and "doing it well" are two separate things, things depends on each other, and cascades happens when things start "doing it wrong". If you expect people to leave Windows, you need to make things easy for them because the "one thing" they want to do, over and above all else, is "get their work done...toot sweet".
-
Monday 22nd August 2016 11:09 GMT MSLiermann
Re: it's already bad enough with dbus...
@AC:
"Well then, you're not the typical user. The typical user expects to be able to access the card from the moment they stick it in."
The typical Linux user runs servers, and most of what systemd does is of benefit to desktop users, hence irrelevant for most actual real-world requirements.
-
Monday 22nd August 2016 11:37 GMT phuzz
Re: it's already bad enough with dbus...
But the typical linux user would rather mount file systems themselves (by hand, via a command line).
Users who want modern fripperies like an OS that will assume that because you plugged that USB stick in, maybe you'd like to access it, already use Windows or OSX (or more likely, don't own a traditional computer at all).
-
Monday 22nd August 2016 11:46 GMT Charles 9
Re: it's already bad enough with dbus...
"Users who want modern fripperies like an OS that will assume that because you plugged that USB stick in, maybe you'd like to access it, already use Windows or OSX (or more likely, don't own a traditional computer at all)."
And that attitude is why people will never be temtped away from Windows, no matter how much you want them to for security reasons or whatnow. Make up your minds.
-
Monday 22nd August 2016 21:20 GMT Adrian 4
Re: it's already bad enough with dbus...
"And that attitude is why people will never be temtped away from Windows, no matter how much you want them to for security reasons or whatnow. Make up your minds."
We don't WANT them too. We're just nice, and hate to see them suffering, so we suggest they use what we're using. We'd quite like manufacturers to stop only serving WIndows customers, but apart from that we really don't care. If they like Windows, they're welcome to it.
-
Tuesday 23rd August 2016 02:57 GMT Anonymous Coward
Re: it's already bad enough with dbus...
"We don't WANT them too. We're just nice, and hate to see them suffering, so we suggest they use what we're using. We'd quite like manufacturers to stop only serving WIndows customers, but apart from that we really don't care. If they like Windows, they're welcome to it."
No, you DEMAND it because people don't live in isolation. Vulnerable users get pwned, and their computers in turn end up in botnets and other stuff that clogs the Internet and ends up attacking YOU. So you demand one of two things: (1) a license to use a computer, which is impractical because computers are kept on private property, or (2) that people move to OS's where security doesn't play second fiddle to profit.
-
-
-
-
Monday 22nd August 2016 16:26 GMT Down not across
Re: it's already bad enough with dbus...
Well then, you're not the typical user. The typical user expects to be able to access the card from the moment they stick it in. Perhaps the image writer should be smart enough to realize this ahead of time and request a dismount of the card before writing to it.
Without asking?
Even Microsoft's excuse for an OS will pop up a dialog box telling you it can't read the disk (ok well IIRC it tells asks you if you would like to format it or something silly) or doesn't understand its filesystem. I have had that happen when accidentally inserting wrong flash drive and the popup saved overwriting a portable BSD boot drive that I had not remembered to label as such.
I really really do not want systems trying to be clever and doing stuff behind my back thinking they know better.
-
Monday 22nd August 2016 18:36 GMT Doctor Syntax
Re: it's already bad enough with dbus...
"I really really do not want systems trying to be clever and doing stuff behind my back thinking they know better."
This. As soon as you try to double-guess what the user wants to do you're apt to close off a lot of alternatives that the user might actually have wanted. Less is more.
-
-
Tuesday 23rd August 2016 09:12 GMT bombastic bob
Re: it's already bad enough with dbus...
"Well then, you're not the typical user. The typical user expects to be able to access the card from the moment they stick it in. "
WHY! SHOULD! POWER! USERS! BE! TREATED! LIKE! IDIOTS! BECAUSE! SOME! LUSERS! ARE! IDIOTS!???
ok done shouting now.
you do *NOT* fix things by LAMING the operating system. Micro-shaft did this with Win-10-nic. let's *NOT* do this with Linux.
-
-
Monday 22nd August 2016 15:49 GMT asdf
Re: it's already bad enough with dbus...
>it's already bad enough with dbus...
Wait until Red Hat has the power to get kdbus on most distros like it did systemd and can then effectively ignore the GPL on the Linux kernel code, Red Hat proprietary OS coming soon to a computer near you). Then you are going to miss the days of just dbus.
-
-
-
-
-
Tuesday 23rd August 2016 06:13 GMT DainB
Re: I've forgotten...
They already did. You now have choice of three naming conventions for network interfaces on RHEL7 none of which working correctly until you explicitly specify MAC address for interface in old school way. And don't even get me started about changing output of ifconfig for absolutely no reason other than change itself, broke quite a few scripts around here.
-
-
-
Monday 22nd August 2016 09:27 GMT R3sistance
Re: I've forgotten...
sysvinit is a relic that lacks way too many modern features.
SystemD actually manages your processes, sysvinit just invokes scripts and forgets if the process is even running, it doesn't even care about the quality of your script. It's down to the developers/administrators to even ensure that what is there, is readable and functional. Systemd actually allows you to configure things properly, have dependency chains and the ability to respawn processes on failure. Systemd is far more friendly with modern hardware compared to sysv. Perhaps SystemD is not the best replacement but it's still a superior one to sysvinit. Fact is hardware changes and as hardware changes, software needs to keep up to pace, the problem is sysvinit is not up to pace, there is the problem.
-
Monday 22nd August 2016 10:02 GMT Doctor Syntax
Re: I've forgotten...
"the ability to respawn processes on failure."
Let's start from the assumption that a process should not fail.
If it has failed what should an admin do about it? It might have failed, for instance, because the process had lost one of its disks.
Investigating would be a good idea. In fact it's such a good idea that the correct sequence is investigate, fix, restart. In that circumstance is it a good idea to have some automated process restart it before the admin has chance to look at the problem? Apart from the impediment to investigating the cause of failure there's a chance that the automated restart might corrupt data. If the process fails on restart we have the prospect of systemd running round like an ADHD child repeatedly crashing the system.
Oh, yes, I could set up systemd to not restart that process. So why would I want to have it in the first place?
-
Monday 22nd August 2016 11:44 GMT Anonymous Coward
Re: I've forgotten...
"Investigating would be a good idea. In fact it's such a good idea that the correct sequence is investigate, fix, restart. In that circumstance is it a good idea to have some automated process restart it before the admin has chance to look at the problem? Apart from the impediment to investigating the cause of failure there's a chance that the automated restart might corrupt data. If the process fails on restart we have the prospect of systemd running round like an ADHD child repeatedly crashing the system."
Or it could've just hiccuped, which tends to happen more often than you think. Or perhaps it was just accidentally killed in some way. Put it this way. A single failure can be a fluke. But if the restart fails, then perhaps you should look into it. If you're worried about the restart corrupting things, you should be more worried about the running process corrupting things, too, which no checking system will detect.
-
Monday 22nd August 2016 14:18 GMT R3sistance
Re: I've forgotten...
"Investigating would be a good idea. In fact it's such a good idea that the correct sequence is investigate, fix, restart."
In the meantime, let's just leave the corporate website offline since me not being a machine myself, I am asleep and in bed. If you have sysadmins on hand 24/7 then great, do that. But in reality you rarely have the right people around all the time and often the failures tend to be simple things. Also I have not seen the type of corruption occur that you are talking about, but this maybe because I try to set-up things to not break in the first place. If your application is something that MIGHT corrupt data then sure, you might not want it to auto-restart. If like the type of things I deal with, you have methods of recovery such as Galera SSTs or it's apache services that have no permissions to write to file to begin with, it's usually not that much of an issue.
But more so, systemd has other lovely things it can do on failure, it's not pretty but it is possible to make systemd send an e-mail or run another service, sysvinit has nothing.
-
Monday 22nd August 2016 16:38 GMT Down not across
Re: I've forgotten...
But more so, systemd has other lovely things it can do on failure, it's not pretty but it is possible to make systemd send an e-mail or run another service, sysvinit has nothing.
Why is that a problem? sysvinit is what it is supposed to be. init.
If you have some processes that may die or need to be restarted should they die, that can be done outside PID 1.
I had an issue (this was probably nearly 30 years ago or something) where I did need some process(es) to stay up no matter what and it wasn't exactly hard to write up a quick watchdog script to check for the processes and restart (and send notification) if they were found not to be running.
You don't need to reinvent init for that.
-
Monday 22nd August 2016 20:13 GMT Anonymous Coward
Re: I've forgotten...
"If you have some processes that may die or need to be restarted should they die, that can be done outside PID 1."
No, because PID 1 started it! Any other process doing what PID 1 started means another process is usurping init. I would call that dangerous because it breaks the hierarchy.
-
-
-
Thursday 1st September 2016 07:45 GMT John Robson
Re: I've forgotten...
So what happens if your precious (and now massively complex) systemD crashes, or gets stuck in a loop?
A watchdog can be coded in a handful of lines of your favoured shell script - it is therefore massively unlikely to crash an burn, since there is very little to go wrong.
Paranoia is good though, so I often use cron to run the watchdog every minute (or every 15 depending on the complexity of the process being watched) -it's fractionally slower than a tight looping check, but gives an acceptable level of response for everything except safety/life critical systems - and at far lower performance cost.
Now you ask what happens if cron fails? Not something I've ever seen actually - it's as reliable as init...
It also makes for nice easy reading, and the watchdog can call on mailx if it needs to notify you that something has died and been restarted.
Indeed it can also pop a flag file in a tmp directory and *not* restart the process more than once an hour, or until reset...
Does systemD have the option to 'try this three times, then give up and email, on success reset the counter after an hour'
-
-
-
-
-
Monday 22nd August 2016 18:41 GMT Doctor Syntax
Re: I've forgotten...
"because I try to set-up things to not break in the first place"
And if you do and they break then something serious is wrong. If it's running in a state you didn't intend it's not doing what you intended nor running in a way you anticipated and may well be corrupting stuff. Maybe the safest thing for the corporate website would actually be to be offline until morning. The alternative might be to be offline for a good while longer whilst you sort out the mess and restore from backup. I've always believed that a strong sense of paranoia is the first requirement for a good DBA.
-
Monday 22nd August 2016 20:12 GMT Anonymous Coward
Re: I've forgotten...
In which case it's the running process that's corrupting things. Meaning Murphy has struck and slipped through the cracks because no amount of safeguarding will detect the corruption occurring during a running process because it'll keep reporting back everything is hunky-dory. Meaning by the time it's crashes, you're already Up Crap Creek. It'll probably also mean the automatic restart fails, too, meaning you're no worse off than you were originally. OTOH, if it just hiccupped, an auto-restarting system will pick itself up instead of lie drunk on the floor while you're losing business and revenues by the minute while everyone's asleep.
-
-
-
-
Monday 22nd August 2016 11:33 GMT Jason Bloomberg
Re: I've forgotten...
Systemd is far more friendly with modern hardware compared to sysv. Perhaps SystemD is not the best replacement but it's still a superior one to sysvinit.
Systemd seems to have noble aims, is fine on paper, and, when it works well and one never needs to alter anything, it does seem to be better.
When things don't work or one wants to change how things work it often turns out to be a whole different story.
There seems to be parallels with the move from IPv4 to IPV6; rather than just fix what was lacking, get everyone on-board with 'that makes sense', there was a jump to something quite different.
-
Monday 22nd August 2016 11:49 GMT Anonymous Coward
Re: I've forgotten...
"rather than just fix what was lacking, get everyone on-board with 'that makes sense', there was a jump to something quite different."
Because with IPv4, to fix what was lacking took more than just a band-aid (because part of the problem wasn't JUST running out of addresses but ALSO untangling complicated routing tables that were causing the Internet to lag).
Similarly, trying to set up a system that can handle dynamic hardware (especially essential systems on dynamic hardware) means creating a system that, unlike SysV, doesn't make assumptions. Plus there's the matter of containers and virtual machines with inconsistent configurations.
-
-
Tuesday 23rd August 2016 09:23 GMT bombastic bob
Re: I've forgotten...
I've never had a problem using the old System V method which was decades-stable. Debian had a really nice way of ensuring that startup and shutdown scripts execute in the right order. I've also never seen network adaptors 'reverse' (and I run multi-home machines, so there). And FreeBSD still uses good ol' System V stuff [only simpler and with /etc/rc.conf to help you].
No, systemd was done because THEY COULD. Someone must've got a wild hair stuck up his anus and *felt* that the whole sysinit process needed to be re-designed from scratch. It became "his baby" with all of the "feel good about yourself" that goes with it.
Arthur C. Clarke's "Superiority" talks about this kind of thinking, too.
(WHY was it again that they LOST the war? heh)
-
Tuesday 23rd August 2016 10:05 GMT Vic
Re: I've forgotten...
I've never had a problem using the old System V method which was decades-stable
SysV scripts can be a little intimidating at first; you'll notice that the systemd-proponents seem to like to make a fuss about how many lines they are. But that length is a strength, IMO, not a weakness; you have the operation of the script laid out explicitly for your examination, rather than hidden within an executable. SysV scripts are very debuggable, and trivially modified if you want *your* box to do something different to what the package maintainer wanted.
Now I daresay that much or all of what I want to do is possible within systemd - but that involves learning another control system. I already know Bourne-shell scripting - I think it's pretty much certain that any successful *nix admin will - so all we're really doing here is taking an easily-readable, debuggable script written in a language I understand well and replacing it with a configuration file for an executable I don't know and can't readily inspect. That's obfuscation.
I've also never seen network adaptors 'reverse' (and I run multi-home machines, so there)
I have when you change the physical hardware. I'm not sure I really know how to identify a particular card except by its PCI position (fragile) or its MAC address (somewhat more resilient).
The former could probably be done with udev or similar (I've never done it, and never expect to, since it's a horrible way of doing things). The latter is trivial. I can't actually think of a third way...
Vic.
-
Friday 26th August 2016 03:40 GMT Charles 9
Re: I've forgotten...
"SysV scripts can be a little intimidating at first; you'll notice that the systemd-proponents seem to like to make a fuss about how many lines they are. But that length is a strength, IMO, not a weakness; you have the operation of the script laid out explicitly for your examination, rather than hidden within an executable. SysV scripts are very debuggable, and trivially modified if you want *your* box to do something different to what the package maintainer wanted."
That's also its weakness because it makes them delicate, allowing them to fail in obscure ways that results in a cascade where the reported point of failure isn't really the point where it started to go wrong.
Plus SysV doesn't use dependency triggering but delays. Not good if you need a quick turnaround like for a container.
-
Friday 26th August 2016 13:09 GMT Vic
Re: I've forgotten...
That's also its weakness because it makes them delicate, allowing them to fail in obscure ways that results in a cascade where the reported point of failure isn't really the point where it started to go wrong
That's just nonsense. Explicit scripting is inspectable; the point of failure is trivially found.
Plus SysV doesn't use dependency triggering but delays.
Again, not true; the only time a script will delay is if there is good reason to do so - which a systemd initialisation will also need to do. The only difference in terms of how te two ytems are supposed to work is that systemd is asynchronous whereas SysV is synchronous. That makes SysV more robust and more easily debugged, and it makes systemd faster.
And if that had been the extent of what systemd had done, there wouldn't be this recurring argument. But it isn't; most of us couldn't really care whether the start system is sync or async, what we care about is that far too much code is getting subsumed into systemd. That smacks of very poor design.
Vic.
-
-
-
-
-
Monday 22nd August 2016 16:24 GMT John Hughes
Re: I've forgotten...
Was it just that init scripts were human readable?
Init scripts are readable? What planet are you writing from?
Have you ever seen a systemd unit file? This is unreadable?
[Unit]
Description=OpenBSD Secure Shell server
After=network.target auditd.service
ConditionPathExists=!/etc/ssh/sshd_not_to_be_run
[Service]
EnvironmentFile=-/etc/default/ssh
ExecStart=/usr/sbin/sshd -D $SSHD_OPTS
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
Restart=on-failure
RestartPreventExitStatus=255
Type=notify
[Install]
WantedBy=multi-user.target
Alias=sshd.service
I'm not going to include the 174 line shell script this replaces (that sources various other shell scripts).
-
-
Monday 22nd August 2016 08:42 GMT -tim
The auto mount/ idle soft unmount solution issue is a good way to deal with removable media and has been for decades in other operating systems. I expect OS X 10.10 is doing the same thing. It appears that there is some sort of loop back file system pointing to the real device. The problems in Mac land is that $ cd /Volumes/UNTITLED; ls -l will often return ". not found" at random times. Oddly enough I've never seen things disappear from the gui systems.
-
Monday 22nd August 2016 11:40 GMT P. Lee
Can I just add
I hate binary log files.
I don't need /var/log/messages to be in a database format. There isn't enough random access of these things to warrant database usage. Now I need some journal doohicky instead of cat, less and grep.
Its just another level of complexity I don't need. I don't need to do db queries, chained greps are fine.
I'm happy for parse-able formats, just don't hide the data away somewhere I can't get to it.
-
Monday 22nd August 2016 11:56 GMT Anonymous Coward
Re: Can I just add
There are a number of reasons for it. A key one is security. What's to stop a log message being faked, for example, unless you add structure to the system to allow gatekeeping? Gatekeeping can also be critical if the log system encounters a Thundering Herd problem. Also, what do you do when the data you want to log is necessarily binary, such as a firmware dump caused by a fault?
-
-
-
-
Monday 22nd August 2016 12:10 GMT CrazyOldCatMan
Re: And thus..
> What would you do to correct this problem?
Not give a personality-challenged ego-maniac access to mess up things? Switch to a distribution that doesn't use systemd? Use *BSD? Not give one company the power to take desktop linux in the same (failed) direction that Windows has gone with more and more obfustication and disdain for anything that doesn't fit the lead programmers world view?
Systemd is a sledgehammer to crack a nut and explicitly violates one of the prime tenets of unix/linux ("do one thing well") and reduces the ability to have human-readable inputs and outputs. Sure - yes - you *can* have text logs, but it isn't the default. And to respond to the earlier point about security - if someone already owns the box to the extent that they can fake text log entries, they can surely fake binary log entries..
-
Monday 22nd August 2016 12:16 GMT Charles 9
Re: And thus..
"if someone already owns the box to the extent that they can fake text log entries, they can surely fake binary log entries.."
Not if they only control ONE process (which they're using to post fake log messages using text formatting tricks). The thing with gatekeeping is that it's a lot harder to fake it since the gatekeeper knows which process is emitting which message. And the ONLY way to enforce this is to use a more-complicated logging format that allows for discrimination. You simply CANNOT do this correctly with a text-based log; it's too simple for that. To put it in perspective. If all you have to work with is a single bit (1 or 0), how do you correctly inform when a coin flip lands edge?
-
-
Monday 22nd August 2016 19:31 GMT Charles 9
Re: And thus..
"Bollocks. I really hope you do not work with computers."
Bollocks on the bollocks. If you say a log can be reliably kept with nothing but ASCII, explain how you can say a coin landed edge when all you have to work with is a single bit: 1 or 0? Language can hit limits. Just as some things simply cannot be expressed in a yes or no, so some things cannot be reliably said in just ASCII. That's why there's such a thing as necessary complexity.
-
Tuesday 23rd August 2016 03:07 GMT Munchausen's proxy
Re: And thus..
" If you say a log can be reliably kept with nothing but ASCII, explain how you can say a coin landed edge when all you have to work with is a single bit: 1 or 0?"
Uh, that's exactly -- I mean EXACTLY -- the point of ASCII logging; you are not limited to a circumscribed description:
Aug 22 22:30:12 localhost flipd: INFO: Coin landed on edge
I think it's you who will have a problem expressing an incommensurate event in a number system that doesn't include a representation of the event's state.
-
Tuesday 23rd August 2016 03:11 GMT Charles 9
Re: And thus..
No, because if I can control a process's logging, I can do this, too (note, in this example ONE process wrote this):
[ rogue ] Something innocuous happened
[ fake process ] Something fake happened
How do you keep a rogue process from making a fake tag when the process can match any tagging the logging system uses?
-
Tuesday 23rd August 2016 09:27 GMT Vic
Re: And thus..
How do you keep a rogue process from making a fake tag when the process can match any tagging the logging system uses?
Even if you can - and your newline argument is bogus - all you're doing is cluttering the logfile; you're not removing any genuine logging, just adding a bit of noise.
And if the log you're trying to dibble with has a separate file (e.g. maillog), you don't get to write to that file anyway. Putting sendmail messages into /var/log/messages will ring every alarm bell there is...
Vic.
-
-
-
Tuesday 23rd August 2016 09:28 GMT bombastic bob
Re: And thus..
" If you say a log can be reliably kept with nothing but ASCII, explain how you can say a coin landed edge when all you have to work with is a single bit: 1 or 0?"
uh, WHAT? [what does that have to do with a daemon logging a message into a system log]
it's like a 'straw man' argument. you invented some weird exception and then expect that to disprove the opposing position. I don't think your logic is working very well here.
ASCII text is about as free form as you can possibly want. you can be verbose or terse, use numbers or words or an entire freaking paragraph. whatever you want. I think I'll stick with that, as it's easy to use 'less /var/log/whatever'
-
-
-
-
Monday 22nd August 2016 16:07 GMT Charles 9
Re: And thus..
How do you know which process REALLY said what if all you have to work with is ASCII, which the pwned process is fully capable of using as well, meaning there's no way to distinguish a well-disguised fake log output pretending to be another process from the actual process. The range of your output is too limited to properly distinguish between them. Anything you can try to use within the ASCII range to safeguard them, the rogue process can mimic. It's a rogue edge case, just like you have no way to say a coin flip landed edge (the LITERAL edge case) if all you have to work with is 0 (heads) and 1 (tails). See where I'm going with this? Properly safeguarding the log from rogue output requires something beyond ASCII. It's a necessary complexity.
-
Monday 22nd August 2016 22:27 GMT Vic
Re: And thus..
How do you know which process REALLY said what if all you have to work with is ASCII
syslog tells you - both process name and PID. So your mythical pwned process could put whatever it likes on the line after that - but only the truly clueless would not notice that the very beginning of each line tells you exactly where the message came form.
Vic.
-
Tuesday 23rd August 2016 03:09 GMT Charles 9
Re: And thus..
"syslog tells you - both process name and PID. So your mythical pwned process could put whatever it likes on the line after that - but only the truly clueless would not notice that the very beginning of each line tells you exactly where the message came form."
The fake process newlines its log and creates a fake tag that ticks all the marks. And the log has to be able to newline in case of structured text output like a hex dump.
-
-
-
-
-
Tuesday 23rd August 2016 04:18 GMT Anonymous Coward
Re: And thus..
"Systemd is a sledgehammer to crack a nut and explicitly violates one of the prime tenets of unix/linux ("do one thing well")"
It does one thing: manages a dynamic, ever-changing system. Thing is, managing a dynamic system properly requires a lot of data and control. It's sort of like Machiavelli's The Prince. Once you rely on lots of little things, you end up with process chains, and you know what they say about chains (IOW, in the real world, you can't rely on every process to "do it well" and instead have to assume one or more will "do it wrong"). It creates multiple points where the chain can break, and these breaks can cascade in unpredictable ways.
-
-
Tuesday 23rd August 2016 09:51 GMT Charles 9
Re: And thus..
PCI and PCI Express are not fixed buses. You have to POLL them to learn what they house. Universal Serial Bus has to be polled. So does 1394 IINM. Unlike with most ARM configurations (fixed memory map), the system doesn't know what's in the system at the initial bootup, and the configuration change at runtime (like with USB and 1394 which can hotplug).
-
Tuesday 23rd August 2016 10:12 GMT Vic
Re: And thus..
PCI and PCI Express are not fixed buses. You have to POLL them to learn what they house. Universal Serial Bus has to be polled.
So what? We've been doing that for *years*.
systemd does not add new functionality in this area - it just does the same old stuff in a different way. This is why some of us are pushing back - what was there wasn't fundamentally broken. It didn't need reinventing, and it didn't need replacing with an opaque blob that will be much harder to troubleshoot when something goes wrong.
Vic.
-
Wednesday 24th August 2016 05:32 GMT Charles 9
Re: And thus..
"systemd does not add new functionality in this area - it just does the same old stuff in a different way. This is why some of us are pushing back - what was there wasn't fundamentally broken."
If that were true, why are there constant complaints about things breaking? What I see is a bunch of bodges on top of bodges, and the thing about bodges is that they don't usually hold that well.
If I had to put it in a nutshell, I say the whole UNIX model is broken because it relies on a level of trust you can't guarantee anymore. You simply can't rely on everything in the chain to "do it well"; odds are at least one thing will "do it wrong" instead, which is why things keep breaking.
-
Wednesday 24th August 2016 09:25 GMT Vic
Re: And thus..
If that were true, why are there constant complaints about things breaking?
There aren't. There are claims of such from people who would replace SysV. I've a zero breakage on any machine I own or control. And I don't know anyone who has.
The one complaint you *can* throw against SysV is that it is quite slow. Yes, it is. It's a synchronous start. That really doesn't bother me in the slightest.
What I see is a bunch of bodges on top of bodges
Well, everyone is entitled to an opinion. What I see is a tried-and-tested system that works effectively and doesn't need to subsume every other system in the OS.
which is why things keep breaking.
Says you. Those of us who have done this for a living for many years don't see things breaking unless someone has been dibbling with them - as is the case for NetworkManager, PulseAudio, and systemd. I'll find the common cause there one day...
Vic.
-
Friday 26th August 2016 02:50 GMT Charles 9
Re: And thus..
"Says you. Those of us who have done this for a living for many years don't see things breaking unless someone has been dibbling with them - as is the case for NetworkManager, PulseAudio, and systemd. I'll find the common cause there one day..."
That's because you're not working in the consumer sphere, where configurations aren't so hard and fast. At least with servers the setup's predictable and easy to tune. Not so easy when your monitor may be hooked up to a USB adapter and manufacturers aren't so forthcoming. Why do you think Valve has such a hard time getting game developers to code for Linux despite having such a strong distribution system in Steam?
-
Friday 26th August 2016 13:02 GMT Vic
Re: And thus..
That's because you're not working in the consumer sphere, where configurations aren't so hard and fast
Yes I am. I was supporting GNU/Linux desktops before RH decided that there was no business there. Whilst I do fewer now than at my peak, I'll wager I still support far more end-users than you do.
Configurations might not be "hard and fast" - there is significant variation between each site I attend - but that has not been simplified by systemd in the slightest; the contrary is actually true, since SysV is far more discoverable, since it supports tab-completion properly.
Not so easy when your monitor may be hooked up to a USB adapter and manufacturers aren't so forthcoming.
If you've got a reasonable river, that just works. If you haven't got a driver, it doesn't. Replacing SysV with systemd is entirely orthogonal to that situation; if it work with the latter, it will work with the former,.
Why do you think Valve has such a hard time getting game developers to code for Linux despite having such a strong distribution system in Steam?
I don't know. I don't follow Valve's affairs. But I can guarantee you that a lack of systemd has nothing to do with it, although I could believe that systemd's pervasion throughout the assorted subsytems of the OS might put some off.
Vic.
-
-
-
-
-
-
-
-
-
-
-
-
-
Wednesday 24th August 2016 05:45 GMT Charles 9
At least if it's systemd you know where to look: systemd.
Whereras with a gestalt exploit, the actual point of attack may be so obscure no one knows where to look because the exploit takes advantage of systems that are greater than the sum of their parts. EVERY SINGLE COMPONENT works exactly to spec, yet when you put them together, then things go wrong. And since the component makers don't talk to or understand each other...
-
Wednesday 24th August 2016 09:30 GMT Vic
At least if it's systemd you know where to look: systemd.
And, as systemd grows ever more bloated, that becomes less and less useful. Pointing at a box and saying "the problem is somewhere in that computer" tells you nothing; only by dissecting the problem can you eliminate it. If you can't divide the monolith wherein lies the issue, there's a limit to what you can do about it.
EVERY SINGLE COMPONENT works exactly to spec, yet when you put them together, then things go wrong.
Even if that situation were to arise - and it's hypothetical, not real - systemd doesn't help you one little bit. You've still got a complex set of components, you've merely obfuscated the startup mechanism.
Vic.
-
Friday 26th August 2016 02:42 GMT Anonymous Coward
"And, as systemd grows ever more bloated, that becomes less and less useful. Pointing at a box and saying "the problem is somewhere in that computer" tells you nothing; only by dissecting the problem can you eliminate it. If you can't divide the monolith wherein lies the issue, there's a limit to what you can do about it."
You get the same problem the other way. If you divide every little thing, you end up with a chain with a bunch of weak links that aren't very obvious maintained by people who may not be there anymore and you may not be in a position to go it alone.
"Even if that situation were to arise - and it's hypothetical, not real - systemd doesn't help you one little bit. You've still got a complex set of components, you've merely obfuscated the startup mechanism."
But at least you know who to complain to when things go wrong.
-
Friday 26th August 2016 12:50 GMT Vic
You get the same problem the other way. If you divide every little thing, you end up with a chain with a bunch of weak links that aren't very obvious maintained by people who may not be there anymore and you may not be in a position to go it alone.
No you don't - because you can inspect each and every link in the chain with ease. It takes very little skill to add instrumentation[1] to a SysV script that will tell you *exactly* what it's trying to do. The same cannot be said for systemd; you can only turn on debugging and hope that it tells you what you want.
But at least you know who to complain to when things go wrong.
Many of us have tried complaining to Poettering over the years when things go wrong. He's not renowned for taking any notice.
Vic.
[1] Changing
#! /bin/bash
to#! /bin/bash -x
in line 1 is often a good start, an really not that difficult to do...
-
-
-
-